How to respond to software requirement changes?
It seems common that a team of software developers has to rewrite or redo some parts of the software they have built. They need to do it due to requirement changes in the middle or towards the end of a project, and it happens not only once. There can be reasons for that, such as the client doesn't like the prototype, the CEO or client changed their mind, or that the current design has a poor performance issue. What is the best way to overcome those changes?
First of all, we need to realize that the goal of software development and technology in general is to make processes more efficient, in term of resources and time. The world has been running faster since humans use more and more technology. Faster travelling, faster building, faster manufacturing, faster communication, and faster decisions. Therefore, it is inevitable that change also happens in a faster rate.
Software development, as one of the agent of change, should be prepared for faster change itself. It needs to be ready to face changes in requirements, schedule, and organization restructuring. That's why there are things called agile, scrum, and sprint.
The following are 3 types of response from software developers when dealing with software requirement changes:
1. Unenlightened. They will do the changes and not bothered by them, but they may spend almost the same amount of time again as making the initial one. Usually, it happens with developers with no or few experiences. If the changes happen frequently, the schedule might need to be extended a lot, probably by few months.
2. Protective. Learning from the previous lessons, the paradigm will be shifted to be protective about their code (their hard work). They will start carefully organizing and modularizing their code so that any possible changes can be localized into only replacing some parts of the module. Some of them put an automated testing and automated build mechanisms in place since they know they will need to re-test and rebuild the code many times down the road. This strategy will help them survive most of specification changes with response time in days or weeks rather than months. As for dealing with other bigger or unexpected changes, some of developers may hesitate, asking for the reasons, argues with them, and want to make sure that these changes are really final before they start implementing them.
3. Embracing. They try to accept the changes as inevitable natural occurrences. They will try to incorporate any possible future changes as much as they can into their initial design without compromising the performance too much. The more experienced and time-tested developers may do these as they already have enough solutions and coding patterns for various problems. Their code will be flexible and highly configurable to adopt future changes. In addition to automated testing and build, quick live-prototyping and live-code generators will also be part of their implementation. The live-code generators (as compared to scaffolding generators) will make them possible to apply the changes by adjusting few parameters instead of replacing modules. Code readability and documentation will be prepared since they know if the project ever needs tighter schedule, some new developers may be needed to jump in quickly to help. When the new changes are outside the adaptation capability of their code, they will see it as a hole in their code that they need to fill in, instead of seeing it as a threat. With all those practices, the response time will improve to only hours or days.
It's about time that we choose the correct mindset as changes can happen more frequently. See it this way: software engineering is still lucky enough compared to civil engineering. Changing an almost finished UI is often still doable and easier compared to changing the shape of an almost finished building. The challenge is, since it is seen as doable, changes to a software are more often requested than to a building.