Bloat accumulates over time
Initiatives increase over time. Software keeps getting new features. Processes keep getting new steps.
Successful features and processes are further developed and become the basis of your business. Then they gain even more steps and features.
The rest either stall or are abandoned. They build up a crust of things that need to be done just to keep them going that don’t contribute as much as other things. This results in a net loss.
And that bloat has a real cost
The sunk cost fallacy applies here. Keeping things alive that aren’t useful but might become useful one day is terribly inefficient. If they do pick up once again, and the chances of that are often next to nil, it would have been better to build them anew.
The cumulative effort that it takes to maintain something over time is often a lot less than the effort to build it. Besides, over time the requirements deviate and you would need to upgrade them anyways.
Secondly, using up your resources to maintain and run them means they’re directly taking them away from other potentially more useful things.
Keeping them alive also distracts you from focusing on improving the things that do work.
Over time they build up as a form of operational and technical debt that you will have to deal with.
Within the monolith
For tech specifically, I prefer The Majestic Monolith pattern so I’m not a big fan of having code that just exists but isn’t ever used.
- Tech: Repos are bigger, tests take longer, there’s more documentation, more dependencies, and more complexity. It also might prevent you from doing things because you need to continue supporting something that’s not used. Removing things can also improve speed and efficiency.
- Training, documentation and support: Training might cover a feature that’s rarely if ever used which takes away focus from the important stuff. Documentation will have useless pages that might show up in search. Support might occasionally get questions for really obscure features that no one knows about anymore.
- User experience: it might be as benign as having a link that’s never clicked but as harmful as having a page that’s being used occasionally but no longer has the required processes behind it.
So, you should prune things that aren’t useful anymore
To help with keeping the monolith humming along, I have a semi-formal system that I refer to as the The Prune Date.
The Prune Date is a periodic review session of usage numbers for specific features. It’s approximately once per quarter and doesn’t include recently built features.
Original requirements and assumptions
Firstly, a lot can be learnt just by looking at why a thing was built in the first place.
Often many requirements and assumptions are no longer true.
For a feature that’s failing, you can look at where it started to drop off and why.
You can look at how it was introduced and what mistakes might have been made. For successful features, you can look at what was done right.
Usage numbers
Next, I take a look at the usage numbers of the feature over the past six months.
Scale
Then I consider whether the feature is still appropriate at the current scale. For instance, a messaging system might have been built when we were getting ten orders per day, but now we’re processing a thousand.
Stakeholders
Finally, I consult the stakeholders who’d be affected by its removal.
There might be some features that are used rarely but are very impactful. For instance, user data export for GDPR compliance might not be used frequently but is required.
Based on the above the feature is either considered a prune, maintain or improve.
Prune
If the usage is low, implementation poor, or not considered needed by the stakeholders it’s a prune. It would be removed.
Maintain
If it is being used, but there is no need to scale it yet, or improving it doesn’t align with current objectives, or the stakeholders still need it’s just a maintain. It would continue to be supported.
Improve
If the usage is growing and/or there is feedback that can significantly increase impact, or if the feature needs to be scaled, and it aligns with the business objectives then it’d be improve. I’d bring it up for discussion at the next product meeting where we would discuss the next iteration.
This would then be incorporated as part of the following development cycle either as debt (prune and maintain) or as new features (improve).
And there is no need to replace them
In the beginning, we tended to think of steps in the process or space and features on the website as fixed. If something is removed, another thing should take its place.
If a field in the checkout was not needed anymore, what field could we replace it with? If a toggle in the filtering was removed, what other filter could we add? If the buyer no longer needs to do an action, what other action can we make them do?
But when something is removed, it can just be removed. It’s better if nothing takes its place. It means that you are running the most efficient process possible.
Example from Supplybunny
Supplybunny did end up with quite a few features that were obscure that I had to keep maintaining for entirely too long. After realizing that some things aren’t needed at all, removing them made further progress significantly easier.
For instance, we could send a quote to a customer that’s not tied to an order. It would generate an email with a link that the buyer could click to add all the items to the cart. It was trialed for a while but didn’t work out at the time. Down the line, we added the ability to generate an order on the customers’ behalf which was vastly superior to this. Instead of scrapping the original feature entirely, I kept maintaining it entirely too long till I realized that it was not being used and the effort to maintain it and keep it compatible with other changes was entirely wasted.