3 ms·
In a sense, technical debt is only a big problem for large monolithic codebases. Software that is primarily composed of small manageable components means that
by fouc 7y ago
In a sense, technical debt is only a big problem for large monolithic codebases. Software that is primarily composed of small manageable components means that technical debt doesn't matter as much.
When each component is roughly one week's worth of code, it becomes easy to delete a component with a model that no longer fits the problem domain, and rewrite a new component with a new more appropriate solution.
"If you can rewrite a piece of code in a week, you can understand it in a week." - Greg Young
https://maximilianhoffmann.com/talks/programming/the-art-of-destroying-software https://maximilianhoffmann.com/talks/programming/the-art-of-...
- mikekchar 7y agoExcept when you large monolithic codebase is composed of a whole bunch of screwy distributed components that have been thrown together haphazardly. And, yes, I know you can't have a "monolithic codebase" with "distributed components". It's just that it's actually all the same dish with a different sauce. Distribution of processing doesn't create better code bases -- it's decoupling of the computation that does it. You can decouple code and a very large number of ways. It's also just as easy to write a rat's nest of confusing spaghetti with components that hold each other's state as it is to do it without "components" (I speak from experience on this front, as much as I hate to admit it).
- fouc 7y agoWell if components are holding each others states then that's failing the decoupling test. But I agree, it's definitely not easy to keep things properly decoupled. Requires some level of discipline or some savvy choices up front in the overall architecture of the whole app..
- TheCoelacanth 7y agoNon-decoupled components = tech-debt