I think this web page is very relevant to where we are right now as a dev team: http://www.agile-process.org/change.html (copied below with my emphasis)
(agile-process.org has many pages well worth the read - it's the sort of site you want to come back and read every 6 months)
I think the key here is that if we're going to be agile, our codebase needs to be agile... i.e. easy to change
This means:
- code is always refactored - the next person doesn't have to tidy it up before they can begin
- code is fully tested (unit and acceptance) - so the next person doesn't have doubts about whether it works or not, they can re-design with confidence knowing the tests have got their back... And so we don't have bugs lurking around in dark areas of the code - bring it into the light! Prove that it works!
- code follows conventions agreed on by the team - so the next person doesn't have to figure out why this code is different to the rest of the codebase
- there is no code duplication - we reuse code - rather than duplicating bugs / bad logic / unnecessary boilerplate code - we put it in one place so it can be easily changed
- code is simple - testable, understandable, browsable, explainable
Lots of good decisions in the small result in big payoffs in the large... lazy decisions in the small result in unmaintainable code... read on :)
Surprise! Software Rots!
Is software designed to be simple and elegant more valuable than software that is complex and hard to maintain? An Agile process accepts this as an important fact.  It may surprise you to learn software rots. Intellectually we know it really doesn't, but it might as well. Software rot is caused by improper design and limited project resources. Complexity creeps in as easy code changes are made instead of difficult design changes. Code duplication accumulates rapidly during maintenance tasks.After a while we notice that fixing one bug causes several even more subtle (and expensive) bugs to occur and the cost of maintenance goes up significantly. Eventually the cost of maintenance exceeds resources. It seems as if our code has decayed on its own in spite of our best efforts.Berry Boehm found that as software proceeded through its life cycle the cost of making a change became larger. Ratios of 100:1 for making a change after delivery versus project start are common. But ratios as low as 5:1 can be found. How flat this curve stays depends on many individual project factors.This cost curve is commonly interpreted to mean that you must create infallible requirements documents followed by complete, detailed, and |  error-free designs or pay a huge price later. That isn't what it means. Boehm's findings are not a condemnation of change but rather a caution tobe prepared when changes occur. A well run project keeps the cost of changes lower longer. There are three life cycle events that seem to accelerate software rot. When we proclaim the design is done and accept no more changes. When we move the system into maintenance and change the team's process. Last when the cost of making vital changes exceeds our resources we reach the wall of unmaintainability.To stay Agile you must fight software rot. Refactoring is the art of making design changes over time to keep the software fit for its purpose and ready for more changes. Unitand acceptance tests can almost eliminate the fear that drives inappropriate easy changes on a delivered | system. Early delivery of partial systems helps detect big changes before they become expensive. An Agile process accepts that requirements, analysis, and design are never truly done. An Agile process runs equally well in maintenance or development easing the transition. We know that some changes will cost much more than others. Boehm's findings were that 20% of the changes make up 80% of the effort. We accept that. We counter it with honest estimates and use a planning process that requires the customer to guide our spending decisions and cost compromises. We fight software rot from start to finish so it can never dominate our decisions.Agile processes are a re-evaluation of the way software is created. The quality of the source code is much more important than you may think. Just because customers don't see code doesn't mean we are excused from the effort needed to be ready for changes by keeping quality up, complexity down, and full test coverage. |
