How to Do Many Projects (Part 3): Maintenance

In two earlier blog posts I described how we have organized the software development efforts in our company. I wrote about cross-functional teams and matrix management.

This time, I'd like to talk about software maintenance.

I have recognized two lines of thought regarding maintenance:

1. Software maintenance should be separated from new software development. This means that, when a software development team considers a project finished, it is handed over to a maintenance team.
2. There's no clear difference between software maintenance and software development. A team should perform both new development and maintenance.

Personally, I lean towards option 2. And these are my reasons:

• With agile software development, the difference between development and maintenance has blurred. In each sprint there's a bunch of stuff to do (add new features, handle some bug reports), and then release a new version that may or may not be used by the customer. Do we consider these sprints software development or software maintenance? Or maybe both?
• No software developer likes maintenance. (OK, maybe some of them do, but I don't know many.) They all want to build new applications with brand new architectures and technologies. Adding features to a legacy system is no fun at all.
• When another team takes over the maintenance part of an application, you run the risk that the software development team leaves some thorny maintainability issues to be solved by the maintenance team. After all, if you won't be responsible for maintenance yourself, why should you invest in making that part easier?
• Finally, in his book Facts and Fallacies of Software Engineering, Robert L. Glass pointed out that software maintenance is harder than new software development. (I blogged about that in "The Craft of Maintenance".) Some employees have suggested to me that we should assign our best developers to new projects, while making some juniors and interns responsible for maintenance, so that they could "learn how our applications are built". (It's no surprise that this suggestion usually comes from experienced developers with an obvious dislike for maintenance.)

So you see… these are the reasons why I am not in favor of separating software development from software maintenance. Except for the size of the work, I don't see much difference between them. And I believe it's a good thing that software developers share responsibilities in doing maintenance on their own applications (and making sure that they are maintainable at all). And given the complexity of maintenance work, it is good always to have the senior developers involved.

Of course, if you have people responsible for both development of new projects and maintenance of old projects, you run into some interesting resource planning issues…

to be continued…

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)
How to Handle Many Simultaneous Projects