Section 5.1 Embracing Change
Perhaps the crucial observation about software projects is this:
The requirements for your software will change over its lifetime. Your software must be able to adjust to those changing requirements.
This is it. This is the essence of the difficulty in writing and maintaining software. When we first write a program, we cannot possibly anticipate what our program might be asked to do in 5 years from now. We might have some current use case in mind; some pressing problem that we are trying to solve and that is the reason for writing the software in the first place.
But invariably we discover some nearby problem, that we could solve with some minor adjustments to the software. Or we discover some key behavior that we overlooked the first time around. Or, all too often, clients don’t really know what they want from a software when they first commission it.
Your software will need to change over time to adjust to these changing requirements. And if it cannot do that, then it has lost some of its value.
So given that our software will need to change to meet new or changing requirements, what is the fundamental problem with that? Quite simply:
Changing any existing code base risks breaking the existing functionality.
So these are the two fundamental problems that we need to address:
- How can we make changes to an existing code to make it do new things? What principles and techniques can we use to make this safe?
- How can we know that we have not broken any existing functionality?
