0% found this document useful (0 votes)
37 views2 pages

Software Maintenance

Maintenance is a normal state for XP projects, requiring teams to simultaneously develop new functionality, maintain existing systems, integrate new members, and replace departing members. During exploration phases, teams experiment with refactoring, new technologies, architectures, and customer stories. Developing in production differs from pre-production development, requiring more care in changes, preparedness to address issues, and data migration. Being in production may reduce development velocity, so measure its impact and be conservative in estimates. Teams may rotate helping the help desk to benefit from production experience while limiting interruptions. Newly developed software should be deployed to production incrementally to integrate learnings earlier.

Uploaded by

roi_marketing
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views2 pages

Software Maintenance

Maintenance is a normal state for XP projects, requiring teams to simultaneously develop new functionality, maintain existing systems, integrate new members, and replace departing members. During exploration phases, teams experiment with refactoring, new technologies, architectures, and customer stories. Developing in production differs from pre-production development, requiring more care in changes, preparedness to address issues, and data migration. Being in production may reduce development velocity, so measure its impact and be conservative in estimates. Teams may rotate helping the help desk to benefit from production experience while limiting interruptions. Newly developed software should be deployed to production incrementally to integrate learnings earlier.

Uploaded by

roi_marketing
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

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

farewell to members who move on.

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

of a big winner for the business.

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

from going into production forever.

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

three). Don't guess, though; measure.

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

other hand, it isn't as much fun as developing.

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

You might also like