I often run an interesting experiment in some of my lab classes where I give students an assignment to build a piece of software but I only give them some of the requirements up front. The requirements I give them seem to lead them down one certain approach to design but later I give them another set of requirements that really requires them to change the design they initially adopted in order to accommodate the new features.
What I find is that few developers will quickly embrace changing their existing code because there’s a culture around not changing code. When we change code it becomes dangerous, that’s when bugs get introduced and we may not totally understand the code even if we wrote it ourselves. Changing code always represent some level of risk.
This fear of changing code is absolutely antithetical to where our industry needs to go. We need to build up the confidence to be able to write software that we can then later change or else our software will slowly cease to provide value.
To build the confidence to change code we must adopt practices that support us in writing code that is changeable. Most importantly, having unit tests in place gives us a safety net so that if we make a mistake or introduce a bug we find out about it immediately through a failing test. With a suite of unit tests in place the resistance to changing code begins to fade and we become more confident in changing the code, which in turn lets the software continue to deliver value for customers in the future.