- We Fail Too Much
- Definitions of Success
- The Standish Group
- Doing the Wrong Things
- Doing the Things Wrong
- Time Goes By, Things Improve
- One Reason: The Civil Engineering Analogy
- Giving Up Hope
- Ignoring Your Mother
- Bridges Are Hard, Software Is Soft
- We Swim in an Ocean of Change
- Accept Change
- Embrace Change
- Capitalize on Change
- A Better Analogy: Evolving Systems
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
A Better Analogy: Evolving Systems
What is the nature of software development? Once upon a time, someone said,
"All software systems decay over time to the point that, eventually, replacing them is less costly than maintaining them."
This was stated as an inevitability, and I think we have tended to accept it as the truth (see Figure 3.3). Well, I may be embracing change, but I am rejecting this "truth."
)
Figure 3.3 An inevitable truth?
If change is inevitable, I would agree that decay is inevitable only if change must always be decay. I think it has tended to be like this because we, as an industry, have not focused ourselves on making code inherently changeable. Our tradition, even if you take it back just a few years, is based on the idea that
- There is relatively little software in the world.
- Computers are very slow, so performance is the main issue.
- Memory and storage are expensive, and the technology is limited.
- Computers are more expensive than developers.
If you make it faster, you are on the right track, right? Once upon a time, perhaps, when performance constraints were often make-or-break. But today?
- Computers are now a lot faster than they were then (orders of magnitude).
- Memory and storage are cheap and getting cheaper, vast and getting vaster.
- We have a lot more software to deal with.
- Developer time is a major expense in software development, maybe the main expense.
Computers are only going to get faster and more pervasive in our lives. And software is a lot more important today than ever in the past. Go get an MRI: Your doctor will be using software to find out what is wrong with you. Call 911 on your cell phone: Software sends the police to your aid. And tomorrow, who knows what software will be doing for us?
Look again at Figure 3.3. Do you want to fly in an aircraft that is primarily controlled by software that has decayed to the point where it is really bad, but not quite bad enough to throw away yet? No? Neither do I. That is why "hack it in," which was how we used to make changes, will not hold water any more.
Ward Cunningham of the XP Group says that when you make this kind of change you are incurring code debt. It is like putting something on a credit card because you cannot afford to pay for it right now.
Will it cost more or less later on? If it is hard to fix the problem properly now, will it be easier in a few weeks when the code is no longer fresh in your mind, and when the hack you put in today has caused three other, interdependent problems to emerge?
What if I did the right thing now? The argument against this, of course, is that it will cost more to do things right. I am not sure I buy that, but even if I did, I would say that the cost spent now is an investment, as opposed to a debt. Both things cost, but investments pay off in the future.
So I favor the approach shown in Figure 3.4.
)
Figure 3.4 Rejecting decay: changing change
I say that decay is not inevitable if we refuse to accept it.
For this to be true, we must assert several things.
- We need something like the Hippocratic Oath: First, do no harm. I do not expect my software to be perfect (ever), but I think it is reasonable to hold myself to the basic standard that every time I touch it, I will take care not to make it any worse.
- We need to center ourselves on the notion that validating software (with those who will use it) is part of making the software.
- We need to code in a style that allows us to follow this do no harm oath.
So, what is that style? What is harm? What is the nature of maintainable code? How can we accommodate change if we are accepting that we don't know what/where it is when we start our project?
If we can answer these questions, we can be responsive. We can change our code in response to what we learn, when we learn it. We can keep the quality high, allow the customers to ask for new features when their business changes, and watch the system get more and more and more appropriate to the problem it is designed to solve.
My word for this is evolution. I think it is the essential nature of software development to be evolutionary, that this has always been so, and that the failure and pain in our industry comes from trying to make it all work some other way, like science or engineering or manufacturing or whatever.