> "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."

This is a disappointingly disingenuous statement. It says that a change that takes two days at the beginning of a project takes the same time as a change that takes two days, late in a project. This is self-evident but is not the problem that the "exponential cost of change" scenario addresses. The problem is the cost of making a given change early in the development cycle, as compared with the cost of making the SAME CHANGE later in the project.

At the beginning of a project, the development team and the code-base are both relatively small. Bugs at this stage are easy to find and easy to fix. Similarly, design changes are easy to implement. Implications on other as yet unwritten parts of the system will be zero because the other parts do not yet exist. As they are developed, they will - by definition - work with changes that preceded them. Thus, we might have the two day fix that was mentioned.

However, later in the project, the number of developers and the code-base will likely both be larger. By this time THE SAME BUG may be very much more difficult to understand, particularly if the problem has been handed off to a developer who was not involved in the original code. Not only that, but the implications on other parts of the system are unpredictable because those other parts were developed in the absence of the code change and may not be able to work with it without further changes. This is what the well documented exponential cost of change problem is and, unfortunately, the given answer skirts the issue and does nothing to address it.

Vince.

Another aspect of this topic that I would like to see more discussion on:

In my experience programming in a dynamically-typed language makes it much easier to keep your architecture more flexible and amenable to a change in requirements (which always happens). It seems like statically typed languages like C++ or Java are marble in this analogy, while dynamically typed languages like Ruby, Lisp or SmallTalk are modelling clay. It's much easier to make changes to a sculpture made with modelling clay than it is with marble - often a mistake with marble will require that you throw out the sculpture and start over.

I'm currently converting a project which was originally done in C++ to Ruby. The project should probably have been done in a 'scripting' language initially since it involves a lot of string processing with regexen and the production of html from a template (and it has no requirements for high performance). Since I inherited the project about a month ago, there have been some changes in requirements which will essentially cause us to eventually throw out the C++ code since it is not able to be adapted easily (it would take longer than the Ruby re-write). Hence the impetus to rewrite in Ruby. Using Ruby we'll be able to make the system much more flexible with much less work (productivity will be greatly improved) since it won't be tied to certain types when changes are made.

Not all requirements changes are of the type where you "write 20 statements and change four". In my experience, there are many types of decisions that are going to be much cheaper to make earlier than later--regardless of your choice of process, methodology, programming language, or hairstyle.

Globalization/internationalization
Exception handling and logging policy
"Branded" versions of apps or webapps
Clustered deployment
Client type (i.e. adding a Swing client to a webapp)

IMO you'd be crazy not to plan for internationalization if there's even a 25% chance that a Japanese port is in your future--even if the only action you take is to pick a programming platform that supports Unicode. Yet the XP literature unequivocally states "Turn a blind eye towards future requirements and extra flexibility." http://www.extremeprogramming.org/rules/early.html

It seems to me that this particular XP rule makes a lot of sense where you're talking about programming at a micro level--individual implementations of classes or algorithms, or even of a module/package--but less so when you're talking about high-level architecure or application-wide concerns.

> Not only can a change made later in a project be the same
> price as one made early – if the product is well-designed,
> it can be cheaper.

A couple of people have challenged this notion, so let me see if I can do a better job of explaining myself – so the theory can either be confirmed or knocked out of consideration.

Building a highrise (to use the original paradigm for software projects) is a serial activity. You dig the basement, add the lobby and all the floors, and put a roof on the top. Deciding later that the basement should have been bigger is the kind of change that generated the original idea that the later in the project the changes are made, the more expensive they are.

Now consider a properly designed project -- where by proper, I simply mean that you know from day one whether you’re building a residential or office tower, for example. Construct the edifice with only those items that are expected to be unchangeable (basement, supports, elevator tower). Don’t, for example, build internal walls.

Then new tenants can be quickly and easily moved in and out, by adding or removing internal walls and so on according to their specifications. Leaving the internal design to last makes changes cheaper.

The important part, as Ward emphasized, is that you have to be clear early on what is fundamental (i.e. static) and what should be left sketchy or omitted (dynamic). The error BDUF projects used to make was in not differentiating these parts, but instead just creating a big pile of code.

I agree with Ward that a lot of what we consider great design is often a product of evolution, rather than someone sitting down and figuring everything out up-front. I used to start designing things by first defining the interface of some component, and then figuring out how the desired components interact via their interfaces. While I still think there is room for that sort of approach, I now tend to build things by creating small pieces of functionality, and then refactoring them according to some logical criteria that often emerges during the process. I suppose that that latter approach is similar to the molding of clay, or of marble, that Ward talks about.

While at first I didn't like that latter approach on intellectual grounds (I considered it "hacking" vs. architecting), the "molding the clay" approach proves more effective than the "top-down" architecting approach in many situations. Interestingly, and counter to my initial intuition, the upfront architecting approach seems to work well on smaller projects. As the size of the project grows, and with it the number of requirements and classes, having a clear-cut, initially well thought-out architecture often becomes a burden. At some point, the decision must be made to either completely revise the up-front design (which makes that design less up-front), or just simply go without a grand design.

In lieu of a grand design, what I often find useful, though, are idioms. These are not really patterns in the fancy sense of the word, but just small habitual ways of doing things. If an idiom works well, reusing that idiom over and over again helps give the program a sense of unity, since even a large program can often be reduced to a handful of idioms. The set of idioms give the program a sense of Gestalt. Also, developers reading code based on idioms have to understand only those handful of idioms to start contributing to the program.