Software engineering is the discipline of building tools that never ever break. You can build hammers that are infinitely copyable and in effect, infinitely durable. Wow, amazing, that seems like only a good thing! While, in many ways this is great news, it does have some extremely pernicious problems. For sake of illustration, let’s take our hammer analogy to a totally bizarre place.
Let’s imagine that you are in charge of maintaining this special software hammer. Every change you make to your master hammer is duplicated out to every other hammer in existence. Let’s make this analogy even weirder. The earth suddenly gets way colder. Now the business of hammering nails frequently requires that you scrape ice away from the board you’re hammering into.
The genius hammer maintainer that you are thinks “huzzah, we can put a spike on the end of the hammer for scraping away ice! Every carpenter already has a hammer! This is a convenient way to help keep everyone working”. All the carpenters update their infinitely copyable hammer and are suddenly way more productive. They don’t need to switch tools as they work, they don’t need to carry anything else. Ice-pick+hammer: it just works. People give you accolades and are generally pretty thankful for what you, oh great hammer maintainer, just did for them. Wow, treat yourself to some hot chocolate, you’ve earned it.
After some time, the earth returns to its regular temperature and ice-scraping is no longer a part of nail-hammering. The spike we affixed to the hammer is no longer needed.
In the world of physical hammers, this is less of a problem. Over time with use, the old hammers with spikes will break and new hammers without spikes will be sold and replace them.
Here, the world of software tools contains a cruelty that the world of physical tools does not. Our software hammers with spikes will never break. There is no natural point to replace them and get rid of their needless features. New carpenters will start hammering nails and be baffled and annoyed by this prodigious protrusion. Soon enough, frustrated carpenters will start contacting you about removing it posthaste. Many of them are very upset and some are actually getting injured by the spike. Why did you even add the spike? Maybe you shouldn’t have done that. Idiot.
The analogy is definitely absurd but the phenomenon it illustrates occurs frequently in software. Because there is no natural and obvious way to remove old functionality, the functionality can far outlast the problem it existed to solve. And, as time passes, the initial problem will be forgotten and the superfluous functionality can become frustrating.
Some carpenters may still rely on the spike. Removing the spike will make them upset that you’ve broken their tool. But other carpenters are getting injured and are rightfully annoyed. No matter what, someone is going to be unhappy about what you decide to do.
This hammers-with-spikes phenomenon can be demoralizing if you work on software projects for long enough. Old decisions that looked lovely by the light of yesterday’s requirements will appear hideous in the bright glow of today’s needs.
There are many strategies employed in the wild for dealing with this hammers-with-spikes problem: among them are semantic versioning, deprecating features, and judicious adherence to the unix philosophy. I would add that dealing with this phenomenon requires patience and curiosity on the part of the users of software tools. Every piece of software is a work in progress, bogged down to some degree by its history and it is useful to understand why some hammers have spikes.