Technical Debt vs. Architecture Debt: Don't Confuse Them(thenewstack.io)
thenewstack.io
Technical Debt vs. Architecture Debt: Don't Confuse Them
https://thenewstack.io/technical-debt-vs-architecture-debt-dont-confuse-them/
4 comments
Ward Cunningham:
“If we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan.”
I am not sure what distinction that the article was trying to make, but this IS architecture problems coined as Technical Debt, not shoddy code.
I am not sure what distinction that the article was trying to make, but this IS architecture problems coined as Technical Debt, not shoddy code.
Are they right with the terminology? Do people consider mere bugs technical debt?
I haven't seen simple, visible problems being considered as technical debt so far. But rather only what the article calls architecture debt.
To me, it seems like the article indirectly proposes to use another term because the original one was used wrong too much. Do others see that, too?
I haven't seen simple, visible problems being considered as technical debt so far. But rather only what the article calls architecture debt.
To me, it seems like the article indirectly proposes to use another term because the original one was used wrong too much. Do others see that, too?
This was exactly my thoughts.
The article proposes a new word 'architecture debt' for most of what people consider 'tech debt', and then tries to say that architecture debt is a more serious concern than tech debt.
The article proposes a new word 'architecture debt' for most of what people consider 'tech debt', and then tries to say that architecture debt is a more serious concern than tech debt.
Yeah. Whatever.
How is AI even related to architecture debt in software? By vibe coders forgetting to specify "decent architecture" in their prompt?
Same for data driven. For most companies data driven just means focusing on one more or less relevant metric, but ignoring all rational arguments on topics cannot be measured in an easy way. Leading to short term thinking and optimizing for a metric instead of for business success. Not great, but still not a lot to do with software architecture.
And as much as I'd love software architecture to be a strategic differentiator: It really is not. Companies need software that is good enough. Good and consistent architecture just lessens the developers pain in dealing with it (and technical/architecture improvements are much more fun to do, since there is no customer with strange requirements). There are many companies out there with horrible software quality that still succeed.