|
|
Re: Working the Program
|
Posted: Jan 6, 2004 5:29 AM
|
|
> "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.
|
|
Previous Topic
