Separating Maintenance and New Development Teams
Recently however, there has been a movement towards the same team doing both product development as well as maintenance. This is more prevalent in agile teams where, due to early releases, there are maintenance tasks right from the first sprint itself. Thus, new feature development and maintenance proceed in parallel for a major duration of the project.
After all, this is a problem every company addresses daily, so they must have figured it out right? Nope. Jim Bird talks about a list of highest impact project mistakes from the book Rapid Development:
Most of the mistakes listed have not changed since 1996 (and were probably well known long before that). Either they're fundamental, or as an industry we just aren't learning, or we don't care. Or we can't find the time or secure a mandate to do things right, because of the relentless focus on short-term results
Thinking about it though, the dilemma of organizing teams based on new development and maintenance is certainly an exercise in trying to understand the factors and consequences. It's no short list.
As an example, it's fairly common practice to have new hires do maintenance work. This certainly has its advantages like isolated changes to reduce risk and at the same time ramp up on a code base. However, does this imply separating better programmers from worse programmers is the same separation as new and maintenance development? If you hire all better programmers is there a need to have two teams? And ultimately, is this separation effective?
Well, not really.If you want the work done right, or need it to be done right the first time, it should be done by someone who has worked on the code before, who knows it and who has proven that they can get the job done. Not somebody who has only a superficial familiarity with the code. Research work by Microsoft and others have shown that as more people touch the same piece of code, there is more chance of misunderstandings and mistakes - and that the people who have done the most work on a piece of code are the ones who make the fewest mistakes.
This is something that at some level, of course, is usually addressed more by business reasons than actual effectiveness. This makes it hard to talk about it in absolutes. For example, priorities are chosen and resources are assigned based on those priorities. This may mean entire teams are dedicated to one type of development if they are available or developers are constantly moved around to wherever the current highest priority is. In any event, I think the problem is exaggerated in a smaller company.
The case in which an entire team is dedicated to either maintenance or new development means that code bases flow through different teams and people. Maybe flow is the wrong word- it's probably more like thrown over the wall. "Leave us a voice-mail if you have problems so we can make sure the phones still work." This means that writing code that is maintainable and correct tends to be less important. After all, the new development team is not responsible for fixing issues or adding features once it is complete. On the flip side, the maintenance team has to pick up an unfamiliar code base and deal with issues that should have been addressed from the beginning. They have to find and fix bugs and pile on glue code when a new feature is needed. The real issue here is the problems are not realized until way after they are created. Maybe years or decades later. It's a vicious cycle that will not fix itself. Learning over an entire code base is now separated into teams. Accountability is removed and professionalism is lost.
The case in which you have one team that addresses all development, new and old, is just as interesting. In this case, there's an implied accountability for the problems a developer or team creates. If that team writes crappy code, they'll have to deal with it. However, a bug becomes less important when it's dynamically and constantly prioritized against things that are not bugs. Additionally, this case gets rid of the time lost trying to pick up and learn new code bases and exchanges it for constant, what I like to call, developer context switching. Working on designing and implementing a new product? Put that on hold, in mid thought, and come find and fix this bug over here in a different code base and a different environment. Everything becomes a bug fix- even new code bases. Despite the business priority of these things, the developer drive flattens. The only things that starts to matter is how fast the hamster wheel spins. Morale is removed and professionalism is lost.
In a perfect world all programmers are great and this becomes an almost non-issue. When I snap back to reality this is a real dilemma that, at best, has no real consensus in the industry. Heck, I've referenced articles and books that completely contradict each other. And those articles contradict their references.