Bill Venners: In Extreme Programming Explained, Kent Beck wrote, "One of the universal assumptions of software engineering is that the cost of changing a program rises exponentially over time," and suggests that, "With a combination of technology and programming practices, it is possible to experience a curve that is really quite the opposite." How can the cost of change curve be flattened?
Ward Cunningham: Traditionally, the cost of change curve said that if we detect the need for a change early, it costs less to make the change than if we detect the need late. I tackled that curve by saying, let's almost intentionally make mistakes so we can practice correcting them. That practice will help reduce the cost of making changes late.
Our feeling was that the limiting factor on any change was not when it was done, but how much thinking was required. If we made a change during week one, and it took us two days to understand what was really required, it took two days to make the change. If we made a change during week 21, and it took us two days to understand what was really required, it took us two days to make the change.
In week one, we might have had to write 20 statements. In week 21, we might have had to write 20 statements and change four. But if you practice making changes, the time it takes to change four statements is not that great. You go find the statements and you change them. It might take a minute.
So understanding the need for the change was the limiting factor. Programming it was inconsequential. Once we understood a change, we could program it—early or late. The cost of actually changing the code did not dominate the programming. The dominant cost was time it took to understand what was required, and that gave us a flattening of the cost of change curve.
Many people are afraid of changes because although they understood the code when they wrote it, that understanding has disappeared. They'll tell you, "We worked so hard on these statements. Whatever you do, don't change these statements!" They don't want to go back to that code, because regaining the understanding would be too costly. So another way to help flatten that cost of change curve, to make change cost no more later than it does now, is to decide that people must be able to look at what they're going to change and understand it. Therefore, when you write code, you're writing more to the person who's going to be reading the code than to the machine that's going to run it.
And again you don't want to write a big comment that tells others how to make a change they might want to make, because you don't know what change they're going to want to make. Better to have the attitude that you can't help future programmers make their changes . All you can do is make it easy for them to understand what you were trying to do. And it will be easiest for them to understand what you were trying to do if you were very careful to not try to do too much. The more you try to do, the more work future programmers will have understanding what you've done.
For example, if you just blatantly ignore a situation that a future programmer needs to deal with, they will come in to the code and discover that you blatantly ignored the situation. That means they have the freedom to do whatever is required. But if you tried to account for the situation, they will come in and realize it isn't working. They'll see you tried to account for it, so they'll first attempt to understand what you were trying to do. Once they understand what you were trying to do, they can figure out how to change it to do what they know they need to do. They would much rather come in and discover you didn't even think about it. Maybe you did think about it, but you did not program one bit of it.