So you’re working on a brown-field system. It was written before you arrived, by people long since gone, and it interacts with other systems that are even older. Congratulations, welcome to the part of the software world that makes money.
So you’ve got a big idea to improve your system. You’ll split the monolith into services, or merge the services into a monolith. You’ll have strong API boundaries, or tear down silos. You’ll be event-driven or data-driven or domain-driven or just driven mad. Congratulations, you’re on the road to leadership in the part of the software world that makes money.
What now? You find the hook.
The hook is a benefit unlocked by your improvement. It’s a benefit to the end customer, or the whole business - but it absolutely must benefit someone outside your team.
Here’s some good hooks:
- “You know that report that takes 20 hours to compile once per month? We’ll be able to show it in real time.”
- “Sales wants to offer payment plans, but we’ve deferred those requests as too complex. After this, we will offer six different payment plans (including the weirdness that Big Client requested).”
- “We had four outages of our vital data collector last year, and customers noticed the data loss. With this change, we won’t lose data from errors in other parts of the system.”
But these are not good hooks:
- “Our future velocity will increase, because the system will be easier to understand.”
- “Industry best practices say that this is the right way to do it.”
- “This will unlock features X, Y and Z, even though we’re not building them as part of this effort.”
So - don’t improve the system? Just wait for feature requests?
No. The hook is not the entire reason for a system improvement - it may be a tiny fraction of the value provided. Intangible engineering values - simplicity, separation of concerns, robustness - are important, even if they are not hooks.
The hook is part of the sales process for our improvement. A promise of “better delivery in the future” doesn’t mean much, but a complex feature made easier is a win.
More importantly, the hook keeps us honest. It grounds us in reality. The system exists for its users, and the business that owns it - not to fulfill our engineering aesthetics. If we can’t find a hook - or if the hook is easily met with a smaller change - then we need to rethink our proposal.