Kill Software Early, for Profit
Companies develop software that drive their business. Eventually, software ages away into obscurity. The tech becomes outdated. The code abstractions stray too far from the business processes. Changes to behavior become overwhelming to development teams.
All these are signs that the software is dying. It needs a rewrite.
Based on what I’ve seen so far, we’re all in denial that our software will ever become obsolete to the point of in maintainability. The lie we tell ourselves is that some version of the software will always be able to run.
But if a company hopes to stay competitive using cutting-edge software, teams need to be more willing to kill the software and start over much sooner.
Why don’t companies rewrite business critical software?
Money.
Rewrites cost money. Existing software, even old software, can continue to print money for the company. So what’s the business case for abandoning software? Why not do everything you can to keep that software alive?
I’m not business guy. I have a tenuous grasp on personal finance at best. I mean I use Robinhood for investing. I may never be able to convince my stakeholders that a rewrite is financially desirable compared to keeping the old software alive.
So, here’s my attempt at a business case for a rewrite.
Let’s take this problem to the logical extremes.
What happens if the company never rewrites or refactors its foundational piece of software?
At some point in the future, the software will become way too complex to make changes to. Assuming the business is competitive and on the cutting edge of its industry, its processes will change. Code that can’t evolve to reflect those processes in it’s abstractions become exponentially more complex.
The software will become stagnant, and so will the business.
What happens if the company rewrites all the software whenever a change is need?
Let’s start with a clean slate every single time. Understandably, this seems unsustainable, needing to reinvent the wheel each time. Common sense says that there must be a more efficient of dealing with change.
So naturally, the right way to deal maintaining software that is core to your business is in between these two extremes.
Neither options seem good. What should I do?
In my experience, companies tend to lead towards the first extreme. They wait too long to rewrite and refactor. I would attribute this to risk adversion, the natural tendency to keep the company afloat. Protect your asset. Avoid rewriting mission-critical software, just keep it working to maximize its value.
I want to instead lean towards the other extreme. Rewrite software more often and more frequently. Kill the software before it becomes too costly.
I propose the following principles to avoid the costly death of software.
First, have living documents that describe business processes. Write down expectations, review them often when working with stakeholders. Don’t have conversations and start writing code. Take notes, review, refine, and align before implementing.
Second, write rigid automated tests that align with the living document of requirements. As the living document evolves over time, align those changes with the test suite.
These tests are rigid because they cannot change unless alignment with stakeholders is made. The tests are not there just to exercise code. They describe stakeholder expectations. Additionally, refactors and rewrites shouldn’t require changing these tests. The APIs are rigid and only change with expectations.
Third, write squishy implementations. With the rigid scaffoldings of the tests in place and the APIs well defined called by these tests, the rest of the implementation inside the core of the software should be squishy. Developers should be free to throw things away at any point. Build implementation details that aren’t future proof. Instead of writing smart code, write code good enough to fulfill the APIs of today, knowing that the world around you will change.
Put yourself in a position to rewrite your code at any point. Get really good at rewrites.
In my opinion, a company that excels in rewrites will keep the competitive advantage.
That’s my business case for killing software before it ages too long.