Hacker News Reader

Technical debt isn't the root or even the most common cause of software components not playing nice with each other.

In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones.

(And really much of what we call "technical debt" is just the scaffolding we put together over the years to make stuff be compatible.)

View on HN

> In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones.

Yup. In that context, it is usually called Second System Syndrome (when discussing the person that is laboring under it's influence while in the act of designing) or Second System Effect (when discussing the resulting system):

https://en.m.wikipedia.org/wiki/Second-system_effect

I think if you ask, most anecdotal evidence from people who have worked with architects shows that companies with "software architects" don't necessarily have less "technical debt" then companies without.

Theoretically, those "software architects" would put a stop to "over-engineered" solutions, but why do these companies still have technical debt?

Most likely because technical debt is not solely just "over engineered" solutions.

Reply on news.ycombinator.com