Technical Debt: How do you get out of the bottleneck?

While the article delivers nice explanations for what kind of technical dept exist, it stays very generic and hand-wavy for the solutions. Bringing &quot;microservices&quot; into the room is definitely not helpful. Ownership and setting a quality bar..., sure but how does that look like? As I developer I maybe have an idea but I also need to sell that to management. As manager I have an idea too but I need to convince my developers to strive for quality and sustainability.<p>Sometimes I wish these articles would just state: Stop sprinting<p>Also: document your decisions! If you have to write down and justify your (prudent) technical dept, you maybe catch some stuff before it&#x27;s written in code. It also makes sure more people are aware of it. Additionally, it sometimes prevents CV driven development, which imho is a big problem in tech. Overall, documentation is a very underused tool.<p>Finally: teach everyone (especially marketing) that software development is expensive, so everybody thinks twice before wishing for nice to have features done quick.

It&#x27;s kind of ironic reading that from Martin Fowler that is for me the astronaut architecture goto person :). I have huge respect for this work but I guess a lot of technical debt is probably caused by implementing these complicated pattern - add some AbstractSingletonProxyFactoryBean joke here.

While there are laws in place to prevent usury, they do not apply to the compounding interest that will be accrued where there is technical debt.

Techical debt is primarily about managing complexity, the bane of software engineering. Do not underestimate the value of having a coherent _theory_ about the problem being solved. Something everyone on the team understands and that can be taught to new hires. If you give a programmer a keyboard and a paycheck they will press on keys all day long.

Over time, I&#x27;ve come to believe discussions around &quot;Technical Debt&quot; do not sufficiently examine the nature of the risk of the underlying challenge. The framing also skews and pigeonholes the responsibility part of addressing things.<p>I&#x27;ve tried to articulate this (a bit tongue-in-cheek) here: <a href="https:&#x2F;&#x2F;www.evalapply.org&#x2F;posts&#x2F;software-debt&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.evalapply.org&#x2F;posts&#x2F;software-debt&#x2F;</a><p>In short, I feel a re-scoping in terms of &quot;Software Debt&quot; is warranted. And a re-casting of the risk of this debt in terms of the rocket equation, and opaque financial derivatives of the kind made infamous in 2007&#x2F;08.

I&#x27;m not sure I&#x27;ve ever seen it happen except by declaring bankruptcy.

How we talk about tech debt, how we argue about its importance and how different functions in a team (tech and non-tech) can get to a common ground is usually the most important and many times the most overlooked part of this. Teams tend to fluctuate between &quot;everything is important&quot; and &quot;our PM never lets us do any tech debt relief work&quot;.<p>Shameless plug: <a href="https:&#x2F;&#x2F;leadership.garden&#x2F;tips-on-prioritizing-tech-debt&#x2F;" rel="nofollow">https:&#x2F;&#x2F;leadership.garden&#x2F;tips-on-prioritizing-tech-debt&#x2F;</a>

There’s no such a thing as technical debt.<p>There’s sometimes bad code that one resolves by redesigning some part of it with eventually some glue code with the old system, documenting it and making a presentation for everyone on how should the new stuff be written, and distribute work for a slow migration of the old systems by the different parties.<p>I’ve seen also some systems designed to solve problem X while the company or industry moved on to problem Y. Again, act like a virus, infect the system with your brand new solution, glue it or bind somehow with the old system and let it spread.<p>The only mistake that you can do is to engage all of your resources to undertake a full redesign and rewrite everything from scratch.<p>And for processes or algorithms that don’t scale, it’s not a debt because you never really made the investment.

I am starting to believe that software has a shelf life. Some of its fresh fruit and milk and some of it is canned beans that will survive for a long time. An answer to technical debt is throw out software