Change Requests

by Krishna on October 4, 2006

In many client dealings, there is a conflict between what the development team terms as a “change request” and what the client treats as a “bug”. If new tasks or change requests are treated as bugs, it gives the impression that the team has delivered a poor product.

Change requests need a lot of effort and cannot be fixed easily, especially when the system is very large. As the system becomes larger, the change requests exponentially increase the time to change the design and regression failures become common. When the original architecture was not designed to accommodate the present requests, it makes it all the more harder.

In Agile methodology, there is the concept of “YAGNI” (You Aren’t Going to Need It). This means that one should design architectures without worrying about future requirements. It is useful in some cases to do this so that one does not fall into the trap of “analysis paralysis” — otherwise it is very difficult to move forward with the project. The intent is to expect change.

But the problem is that change is very expensive. Even without extensive documentation needs, here is the time required for a developer

  1. Time to understand the requirements
  2. Time to understand the code changes required in the specific module
  3. Time to understand the implications for code changes and functionalities in other modules
  4. Time to understand the validations and error handling

The “time to think” is very important, otherwise the developer will be making more important design decisions as they code (instead of before they code). This wastes time. Also it may hide design decisions from the project analyst, architect or designer.

Comments on this entry are closed.

Previous post:

Next post: