#engineering #idea #architecture #delivery #release

idea

Version one of any successful product eventually always gets riddled with technical debt. Lack of data and experience to understand the actual usage and difficulties of a system results in making poor architectural decisions. Team is still coming together. Business goals are still unproven. Time is usually a factor.

Overall all the main causes of technical debt^[1] are collectively present:

In a version one, over-architecturing and over-engineering is somewhat pointless given that it will be replaced eventually.

Starting from that assumption that version one will be obsolete and in need of replacement, architecture choices should instead be made to:

1. Maximize learning and data collection to optimize chances of success on version 2.
2. Minimize complexity and cost, and maximize speed, to increase the amount of learning and keep investment capital for version 2.
3. Reduce the exit cost and optimize options to replace by and migrate to version 2. Modernization projects are complex, long and unattractive, optimizing for a migration from the get go is increasing the chances of success.

Architecture records need to reflect the non-perenity of the version one. The objective needs to be clear for everyone, to help initial architecture decisions by not overthinking them, and to facilitate the leadership decision when the time is right to write off version one and replace by version 2.

links

Entry and exit cost: minimize exit cost.

Premature optimization is one of the root causes for the failures of version one, and pure waste given lack of data.

Sunk cost fallacy bad past investments should not be considered when investing for the future

The real Single Point of Failure are unknown in version one.

references

[1]: Kruchten, Nord, Ozkaya / Managing Technical Debt