I was recently asked to answer a question on Quora about the challenge of keeping up with change in a software project. The answers were a resounding cacophony of “yes” - change is a real problem in software development.

Inspired by discussions with Jess Kerr and others, I took a different stance. Here it is:

Technology changes fast. Everything changes fast these days. Regulations change, trends change, there are new innovations, new discoveries, and new threats. Most industries are undergoing changes all of the time. Software is no exception. If change is normal, then change is not a problem. The problem is thinking that things shouldn’t change or not accounting for the inevitability of change.

If your software doesn’t change, you are at risk - the risk of obsolescence and the risk of being hacked are two examples. Software and infrastructure need to change in order to keep our customers safe from newly discovered vulnerabilities in old software and infrastructure. Equifax was hacked because they didn’t prioritize change.

Software is soft. It should be easy to change.

But software is often not easy to change because of poor composition. High coupling, low cohesion, misplaced responsibility, and other issues contribute to making the software difficult to change. The primary measure of success in software tends to be the accomplishment of a user goal. This is good. People use software to accomplish things. But because teams tend to all but ignore the low-level internal design, even with well thought out architectures, a lot of software is a Rube Goldberg machine with a facade that hides the absurdity.

Another factor beyond the software’s composition is the level of automated specifications or tests. Change is more safe and therefor can be done more rapidly when there is a safety net that helps to ensure that only the things you intended to change did, in fact, change. But when there are not enough tests (which is common), that safety net is lacking and changes are riskier. And when tests are written afterwards or when there are too many tests, then the test suite becomes brittle and small changes can break multiple tests, making change harder.

Change is inevitable. Change is often in our favor. The problem is not change. The problem is the absurdity of creating solutions as if change were not going to continue to happen.

Only a fool knowingly builds a glass house in a hurricane zone and then complains about the problem of hurricanes.