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

  • How Smart Managers Think
  • A Team of Leaders (and No Manager)
Related Posts
free book
“How to Change the World”
  • Farhan Thawar

    We have a hybrid of #1 and #2. We assign 0.5 of a resource during the sprint to handle maintenance tasks. This gives us a few good things:
    1. Allows a developer to get up to speed on other areas of the code
    2. Allows the rest of the team to stay in flow and not get interrupted by other folks in the company for routine tasks.
    win win

  • Pawel Brodzinski

    I agree with that one. Actually being aware you’ll have to deal for a longer time with all crap you’re developing works pretty well in terms of code quality.
    We usually leave maintenance for one or two persons from a bigger team (since there’s less work to do during maintenance), but people know if they really screw something up the issue will come back to them even if they’re in different project already.

  • ExecutiveBrief

    Some more useful tips on software maintenance can be found in the article “Bringing Agility to Your Software Maintenance Plan: 3 Fool-Proof Tactics”:

  • Sonja

    We’re actually just starting with a seperate maintenance team, leaning strongly in the direction of option 1.
    Eventhough we’re not working according to the agile methods (yet?) I feel the reasoning can apply also to agile methods.
    First of all, quite a substantial amount of maintenance is done on projects we did not build. Meaning that the make programmers responsible for their own code does not apply in those cases.
    Also, the planning, as stated in the last sentence presents significant problems. When working on a project fase (whether this is a sprint of a week, or a fase of a few weeks) that time is for that project. When maintenance occurs (and this normally isn’t planned) this may take a few days, days which were needed for the project.
    But the most important point you’ve mentioned yourself: Software developers don’t like maintenance. That is because a different skillset and perhaps even personality is needed for maintenance than for software development.
    There are people who like complicated things, who get a kick out of solving the puzzle, but don’t feel that much for building an application from the ground up. These are also the people who feel working on the same projects for weeks is tiresome. But they also need to be very communicative and need to know when to seek help.
    This is unlike the average software developer.
    Perhaps in only looking for software developers and focusing on agile methods you keep out these maintenance people from your company?
    ps. To solve the code ownership problem and developers not taking responsibility for maintainable code the maintenance team has to accept a project into maintenance. If it does not adhere to certain standards it is not taken into maintenance and stays the responsibility of the project team.

  • SteveJ

    “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””
    That’s the way I was brought into the development fold, and I’m pretty sure it’s a recipe for keeping junior developers inexperienced. Reasons:
    1) Jr devs won’t often question something that looks wrong. If one does, the concern is often brushed off (I just didn’t have time to do it correctly, or it doesn’t matter because…). Jr dev feels like his/her opinion is less important. As a nice side effect one can pick up bad habits through “learning” on lousy hurried code.
    2) Coding from scratch creates more learning opportunities. As a new developer, quantity of feedback is more important than quality. It’s like sports, an absolute newbie will learn more from getting a 30 second tutorial and shooting 100 free throws on his/her own than getting detailed instruction and feedback after each attempt. Likewise fixing 100 trivial bugs on code you understand (because you wrote it) is better than a detailed study into a single bug that you fix as a maintainer.
    3) Working on new code helps with indoctrinating new devs as “owners” of the product and as members of your company. What’s more empowering: Building an exciting feature or fixing a stupid bug that shouldn’t have made it in the first place?
    4) Working with new code accelerates the learning curve for a new dev because there is more accountability to produce something. It’s difficult to figure out when to take a problem away or call in extra help for someone who is just learning the ropes. It’s even harder with maintenance because your standards are lower. After all this issue made it past the initial dev team, QA team, etc. It could take weeks for even your best developer to figure out, or it could take weeks just because the new guy doesn’t know what to do first. Any programmer knows that the 2 line code fix can actually be the 2000th line of code you’ve written trying to fix the problem.

    If your goal is to get your junior developers out of junior status ASAP, you need to pair them (not too many at a time) with the elite team. Jr devs bring new ideas to a design process. The same team always charged with creating new products is likely to keep taking square solutions and hammering them into round holes.
    Unfortunately not every new programmer can be morphed into a critical thinking coding machine overnight. But I’d rather know what I’m working with as soon as possible rather than have my future all-star be deprived of learning experiences.
    I’m not saying new development is better than maintenance development in general. I just think senior devs are more appropriate for those roles because they can solve problems quickly, and a good deal of the maintenance issues (memory leaks, race conditions, etc) are more complicated than anything encountered in new code development.

  • Jurgen Appelo

    Sonja, Steve, you’re both raising interesting issues and bringing new perspectives. Thanks for that!
    As for the planning issue: that is easily solved. I’ll write about that soon.

How to Change the World - free Workout - free