Dealing with Change
Written by Keith Johnson - Posted on August 27th, 2010 - Add Comment 
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
There is an ancient saying that “the only thing that does not change is change itself”. This is true! So, the real question, in software development, is how do we deal, effectively, with change? This is a tough question and over the past three decades of Rapid Application Development, there have been different approaches to dealing with change.
Looking back to my own personal experience in Information Technology (since around 1990, after finishing college), it is best to get all requirements up front for any project. Sound idealistic? Perhaps, but this is the best way to ensure the successful completion of a project (e.g. software development project). If you have changing requirements throughout a programming project then you will be creating scenarios that could seriously frustrate efforts to getting the program (e.g. final code) out the door.
We live in the real world with real change and real needs to update requirements. So, this is not to criticize Project Managers in any way. In fact, I have great respect for Project Managers. It is not easy to deal with changing requirements and get programmers to incorporate such updates into their code.
However, at some point, there needs to be an end to requirement changes and a beginning to lasting changes in the computer code that actually creates the program. Programmers are not gods, they are people (I am sure there are some programmer gods out there, but I’m talking about the general programming population here). Working hard to get all requirements up front is like designing a house with a solid design on paper and then working to create that design. It is also like planning a trip. If you plan, say, 90% of your itinerary, you will most likely fulfill that itinerary with minimal problems.

























