Building a great solution and keeping it great

Last Sunday afternoon, I was reading Morgan Housel’s Psychology of Money, in particular the section that says [1]:

“…getting money and keeping money are two different skills. Getting money requires taking risks, being optimistic, and putting yourself out there.

But keeping money requires the opposite of taking risk. It requires humility, and fear that what you’ve made can be taken away from you just as fast. It requires frugality and an acceptance that at least some of what you’ve made is attributable to luck, so past success can’t be relied upon to repeat indefinitely.”

From personal experience, I can build some parallels between “getting wealthy and staying wealthy” and “building a great solution and keeping it great”.

Inevitably, a successful solution will evolve quickly since it is bringing business benefits and there will be incentives to extend it as long as it keeps producing expected return on investment. Otherwise, why to keep investing? Investing on a system, means taking risks, being optimistic and getting exposed. Same, same as Morgan is saying.

As a result, a happy business wants to build more and more features on top of a successful system. At some point, it starts taking technical debt to be paid off later. If you take too much, it could bring it down at some point. Either conceptually or literally.

However, to keep a great solution, great. It requires the opposite. It requires to be humble and prioritize reducing technical debt periodically. The amount of risk you can take shrinks.

Obviously, the analogy can’t go that far because there are software engineering practices and patterns that will allow us to keep growing without being locked to the previous development. However, I hope you get the idea I am trying to convey.

So, how do we control the technical debt of a great solution to keep it great? For starters, I believe a shared understanding needs to be built between IT and business so there is a clear distinction between new features, defects, patching, security issues, technical debt remediation and architectural changes for any particular reason.

Once there is an agreement on what is what. Then, we need to be on the same page on why it is important and what are the consequences if nothing is done.

At the same time, we need to follow 4 rules:

1. Every time we find a bug, we should write an automated test to be part of the Continuous Integration pipeline
2. In every sprint, we should prioritize a percentage of the team capacity for technical debt remediation, so we are continuously chipping it away
3. Have a definition of done that includes: code reviewed, code committed, tests automated, code shippable to Production and monitoring in place, Architectural fitness functions verified [2].
4. Architecture modularization will ensure that new components do not contain technical debt, plus you get fault isolation to minimize the scope of faults if ever to happen [3].

Conclusion

I believe we can all agree that it is a lot easier to make changes to a high quality system. And that the best way to be agile is by reducing technical debt due to the higher levels of certainty.

References

• [1] Getting Wealthy vs. Staying Wealthy by Morgan Housel
• [2] The evolution of Definition of Done (DoD) from zero to DevOps by Pablo Iorio
• [3] Does cloud guarantee fault tolerance? by Pablo Iorio

Disclaimers

This is a personal article. The opinions expressed here represent my own and not those of my employer.