Sponsored Link •
Bill Venners: When you say entropy reduction, are you talking about looking at the architecture as a whole and cleaning up problems with the big picture?
Luke Hohmann: Yes, you can make big picture changes during entropy reduction, but typically I don't want that to happen. I don't want either entropy reduction or refactoring to be architecture-level changes. Nevertheless, it does sometimes happen, and that's when the cost of change curve can jump high again.
One of the things I bring to the table in terms of real world experience is that in several cases I've been with the same architecture over multiple releases. In one example I was with the same product over four years and six releases. In the XP model, the cost of change curve rises for a couple of releases, and then levels off. [See Figure 1.] After that, XP says the cost of change will be constant, but in reality that's a very simplistic point of view. In the first release, you're proving out your architecture. In the second release, you'll have started getting feedback from your initial users about what is working and what isn't, and you might have some changes that are fairly important to make. But once you are in your third release, in the XP model, you have most everything figured out, right? What happens if in the fourth release of a heavy client/server application, marketing says, "I've got to crack open the mobile market, because mobile's huge." The curve will jump.
Figure 1. A Flat Cost of Change Curve
In the initial phase of the curve, you are getting the grooves in the road of your architecture and proving it out. Eventually you get it down, but sometime later you may hit some major problem, some major architectural flaw. At that point, you're going to see that curve start all over again. The cost of change curve is going to have another big jump, because you are engaging in architectural-level refactoring, which is touching lots of components and lots of systems, and possibly even replacing many of them from scratch [See Figure 2.] Over the lifetime of a product, the cost of change is several XP-like curves, each of which is relative to a particular architecture.
Figure 2. A Bumpy Cost of Change Curve
For example, when marketing says that in addition to the heavy desktop client you currently support, you also need to support Palm computers, guess what? Your cost of change curve just flew up high again. These cost of change jumps are usually correlated with significant architectural infrastructure change, because you don't have any infrastructure for your tests. You don't have any infrastructure for your database. You're probably learning something new in the development team. Your developers don't know how to program Palm. Are you going to throw out all the people or keep them? If you keep them, they've got to learn it. They don't know the idioms.
Think of all of the infrastructure that helps keep your cost of change curve low, which you can get to not only in XP but also in other methods. In your existing system, you have all your tests and your test database. Your build infrastructure is all set. Your documentation infrastructure works. You've figured out your naming conventions and tagging conventions. You've figured out how to link your help file to your online documentation. You have all that figured out, and the cost of change curve is low, because a big part of the high cost of change is creating this infrastructure, of figuring this stuff out. Now you don't have all the infrastructure for Palm support, or whatever the new requirement is, so your cost of change curve jumps again. I applaud the concept of the flattening cost of change curve, because it's right. You should be able to achieve that flattening after the first release or two. It's just not true for a mature product over its entire lifecycle.