[allyjweir]

From my recent experience in a new team, this article strikes a chord.

Joining a team that is scared of technical debt and runs circles round themselves in a bid to avoid it end up producing more debt than they would otherwise. For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily.

We must embrace the reality of technical debt. It is unavoidable and not something to be scared of. It can be managed by keeping things simple, clearly tested and keeping a cool head.

[wvenable]

> For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily.

That's just another form of technical debt. Over-engineering is also a well known cause of debt accumulation.

[spdionis]

> making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily

I would say that's just bad engineering due to lack of insight or experience. DRY is the most simple and most dangerous principle (or "best-practice") of them all, because when it goes wrong it's the one that hurts the most.

[allyjweir]

Yes I agree. Bad engineering led them to not accepting the reality that technical debt is unavoidable. In a misguided attempt to avoid it, they overengineered ironically leading to more debt than might otherwise have accrued.

[wes-k]

"premature optimization is the root of all evil" - Knuth

[bcbrown]

One mentor of mine taught me the "rule of three". The first time you have to do something, you write it in-place. The second time, same thing. The third time is when you refactor into a common module all three components can use.

When you're writing it the second time, you're accruing technical debt. You pay it off when you refactor for the third component.

[bpicolo]

I'd argue that "simple, clearly tested" code is the antithesis of technical debt anyway.