What makes software hard to change?
As a developer, it’s easy to focus on the internal properties of the software system. The code needs refactored, the framework is old, we need more tests, or else fewer tests.
If your software is in production, these are not the biggest obstacle to change.
The important changes are the ones visible to the outside world, the ones that change the interface. And changing the interface means more than your software has to change: the systems that use your software need to change.
The more useful your software is, the more other systems depend on it, the scarier change is. You’re risking more than your piece of the world. You need progressive delivery, careful data migrations. Backwards compatibility: twice as many tests, and special cases in the code. You need to design the whole change.
And then, for your work to be useful, people have to use it. You must get the word out through social channels: talking to people, advocacy, (dare I say it) marketing.
This is all fine. It is right. No complaints.
Because our work is not to change software, it is to change a system. To add and broaden capabilities in systems larger than ours.
If our code is full of if/else statements for backwards compatibility, if our database integration is cluttered by a migration, if we spend more time crafting the deploy strategy than we did writing the code, cool.
The more people use the code, the harder it is to change, and the more valuable.
Caveat: yes, there are performance and scale improvements that are useful. A wider variety of functionality changes are useful, and these are more frequent, so that’s what I’m talking about here.
For more on this topic, see: From Puzzles to Products