Darryl.net

It is far more exciting to develop a new software product than to maintain an old one. A new product requires creative thinking, strong teamwork, and racing against a deadline. An old product requires bug fixing, late-night support calls, “scheduled downtime,” and saying goodbye to colleagues who are headed for the next cool thing. How should we accommodate the dull reality of maintenance mode? I discuss three options below.

1. Never enter a maintenance mode.
This is also affectionately known as “Always Be Shipping.” Essentially, your team ships early and maintains what is in production while simultaneously developing additional features. The team remains focused and motivated, fixes critical bugs when needed, and stays dedicated to the product. Unfortunately, this means no downtime for the developers or QA, little chance to step back and analyze performance and feedback, and a constant need to balance between product stability and feature development.

2. Hire a maintenance team.
Call a spade a spade. Maintenance is no fun, so hire someone else to do it. This gives a chance for lesser experience developers to come up to speed and potentially contribute to the product in the future (and keeps the “rock stars” focused on new bling). You could even go so far as to ship it half way around the world to Russia or India – though Bangalore (sorry, Bangaluru) doesn’t want your bugs anymore than you do. The main problem with this ‘outsource’ approach, however, is that the new engineers do not know the code and it is difficult to transition this knowledge. It will take much longer to stabilize the product and add management overhead.

3. Swap maintenance and development modes.
What if you could get around the problems of both #1 and #2 by taking a hybrid approach? If you are developing under “Agile” methodologies, why not split the team up into two groups – each with their own set of rock stars and newbies. Let’s call these two teams the “Red Team” and “Blue Team.”

In the lower row, the Blue Team has just finished a series of sprints developing new features. Now they move into maintenance mode on those new features for a few sprints. During that time, they also work with User Experience & Design (UED) to spec out new features that they will work on when they move back into development mode. In the upper row, the Blue Team moves back into development, and the Red Team moves into maintenance mode. UED now attaches to the Red Team.

There are many advantages to this approach:

• The team gets a breather during maintenance mode. Furthermore, they can concentrate on stabilizing what they just built, rather than writing new code.
• There is incentive to develop more robust code and to fix it quickly. The more solid the code, the more time the team can spend with UED during maintenance mode to think about the future.
• “Rock Stars” stick around because they are always either a) developing the new features, or b) thinking about new features.
• If there is a product manager for each team, this also gives time for the product manager to analyze performance of and feedback on the new features.
• The developers fixing the code know it intimately.
• You can bring new hires into the mix by having them join a maintenance team. Veterans can take time out to help the newbies fix and learn the codebase.
• You are still “always shipping.”

This might require a slightly larger team than initially planned. However, in the long run it could make up for the churn associated with major product launches.

Of course, this “Maintenance-Development Swapping” is just a theory of mine right now. I do intend to try it out in the future and will let you know how it goes. If you get a chance to try it out sooner, please comment on your experience.