Software Maintenance
Software Maintenance
Maintenance is really the normal state of an XP project. You have to simultaneously produce new
functionality, keep the existing system running, incorporate new people into the team, and bid
Every release begins with an exploration phase. You may try big refactorings that you were afraid
of late in the previous release. You may try new technology that you intend to add in the next
release, or migrate to newer versions of the technology you are already using. You may
experiment with new architectural ideas. The customer may try writing wacky new stories in search
Developing a system that is in production is not at all the same as developing a system that isn't
yet in production. You are more careful of the changes you make. You have to be prepared to
interrupt development to react to production problems. You have live data that you have to be
careful to migrate as you change the design. If preproduction weren't so dangerous, you'd keep
Being in production is likely to change your development velocity. Be conservative with your new
estimates. While you are exploring, measure the effect production support has on your
development activities. I have seen an increase in the ratio of ideal engineering time to calendar
time of 50% after having gone into production (from two calendar days per engineering day to
Be prepared to change the team structure to deal with production. You may want to take turns
manning the "help desk," so most of the programmers don't have to deal with production
interruptions most of the time. Be careful to rotate all the programmers through the position—there
are things you learn from supporting production that you just can't learn any other way. On the
Put newly developed software into production as you go along. You may know that parts of the
software won't be executed. Put it into the production system anyway. I have been on projects
where this cycle was daily or weekly, but in any case you shouldn't leave code lying around for
longer than an iteration. The timing depends on how much verification and migration cost. The last
thing you need when you are at the end of a release is to integrate a big gob of code, which
"couldn't possibly" break anything. If you keep the production code base and the development
code base nearly in sync, you will have much earlier warning of integration p