The real problem with scope creep

... is because code has numerous dependencies in it. If I change one arbitrary thing at the client's request, it is inherently difficult to know what other things it will affect. The only way to mitigate errors is to verify everything all over again after every change, and if the change requests come rapid-fire and have to be fulfilled, it actually takes more time than waiting until the next iteration and figuring it out all over again. Plus, if implementing the changes unpredictably affects other components, resolving those issues may lead to new issues. The project is bound to go into a tailspin. It takes time to predict all the dependencies in software, and even with a solid, up-front design, you have to allow enough time to structure the code in a way that avoids adverse cross-sensitivities. A good analogy is prescription medication: You should never introduce new medication to treat emerging conditions without analyzing the patient's current regimen and taking the time to predict how the medications will interact. In some cases, adding a medication will cause more harm than good, and overmedicated patients need to be rolled back to a simpler regimen just to retain nominal health. Likewise, when specifying several software design changes in the middle of the iteration, it is difficult to predict how those changes will interact in the system. Only the programmer can know for sure what will happen, and he's already busy just trying to get the project done.

REPLIES add