Removing things is good
Things that aren't working should be removed and not maintained further.
The number of initiatives, features and processes, increases over time.
Your platform keeps getting new features and you create new processes.
Successful features and processes are then further developed and become the basis of your business. Then they gain even more steps and features.
As for the rest, you either work on them slowly or abandon them entirely.
As a result, they build up a crust of work you must do to keep them going. At the same time, they stop contributing as much as other things.
It’s better to use that effort improving things that do work.
It’s a real-life demonstration of the sunk cost fallacy. You can get attached to the effort you already put in. You justify maintaining something that doesn’t work in the hopes that one day it will.
But the cumulative effort to maintain it till that day is a lot more than just building it again.
Besides, requirements change, so you would probably need to make adjustments as well.
- Tech: Repos are bigger, tests take longer, there’s more documentation, more dependencies, more complexity, more questions. It also might prevent you from doing something new because it’s incompatible.
- Training, documentation and support: Training might cover a feature that’s never used and takes away focus from the important stuff. Documentation will have useless pages that might show up in search. Support might 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.
Supplybunny did end up with few obscure features that I had to maintain 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 list of products to a customer directly. A link would add all the products to the cart. It was trialed for a while and didn’t work. Later, we added the ability to send an order to the customer directly. Instead of scrapping the original feature, I kept maintaining it for way too long. It wasn’t till I realized that it had no usage at all that I understood that the effort to maintain it was a waste.
To help keep the monolith humming along, I have an informal 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.
Firstly, you can learn a lot by looking at why something you built in the first place. You need to check whether the original requirements and assumptions still hold. For a failing feature, you can look at where it started to drop off and what other changes happened at the time. You can look at how you introduced it and if you might not have given it enough exposure. For successful features, you can look at the same things to see what you did right.
Next, I take a look at the usage numbers of the feature over the past six months.
Then I consider whether the feature is still appropriate at the current scale. For instance, a messaging system built when we had ten orders per day might not be appropriate if we’re now processing a thousand.
Finally, I consult the stakeholders who would be affected by its removal.
Based on the above, I consider the feature either considered a prune, maintain or improve.
If the usage is low, implementation poor, or the stakeholders no longer need it, it’s a prune. It would be removed.
If it is in use, but there is no need to scale it yet, or improving it doesn’t align with current objectives, or the stakeholders still need it, it’s just a maintain. It would continue to be supported.
If the usage is growing, or if its impact can be significantly increased, or if it needs to scale then it’d be improve. I would bring up for discussion when it aligns with the business direction.
The following development cycle would get todos that are either debt (prune and maintain) or new features (improve).
This review helps keep the feature set manageable, and it only removes things that aren’t useful.
In the beginning, we thought of steps in the process or spaces and features on the website as rigid. If we remove something, we must put something in its place.
If a field in the checkout was not needed anymore, what field could take its place?
But when you remove something, it can just be removed. It’s best if nothing takes its place. It means that you are running the most efficient process possible.
- The Majestic Monolith
You can have a single well performing application
- We don't tend to take things away
Research that says that we tend towards adding things
Suggest an improvement to this page (firstname.lastname@example.org)