Whether it is exactly the same concept as actual technical debt or not...
This makes a lot of sense to me, and explains why you always think "I can do better than that monster", and it does always feel better at first, then then inevitably grows to feel like a monster where it's hard to make any changes.
Especially when we are thinking about tools for developers, where developers are the users, libraries or web frameworks and such. Or even languages/ecosystems. A bunch of existing libraries/frameworks/platforms/ecosystems are a mess... surely we can do better! let's make a new thing!
This explains why we are always hopping to the new thing, and always convinced the new thing is better...
And the new thing is better and so much easier to work with, even though it doesn't have all the features the old thing did, but okay, we just need to keep building it out to encompass those features, using our much better sense of architecture and usability that we've proven we have because look how clean and simple and usable our first draft is!
Now, there is such a thing as better or worse designed, as the OP admits, poorly implemented or beautifully implemented. But... comparing the new thing that only has the most basic features and seems really elegant to the old thing that covers all the edge cases... isn't actually a good comparison to tel you which is better implemented. That new thing is going to get cruftier when you cover the edges, _always_.
And it shows that if you want to keep your thing feeling smooth and elegant and easy to work with.. you have to keep it as small as possible and resist all feature requests!
> For a feature to add value to your product, it needs to be useful to users. Features can have a negative value when the technical debt they add to your product outweighs the value they add to it.
Thinking of tools for developers where developers are the users... oh yeah it's true.
> A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones
I would describe that as limiting the number of "concepts" inside your code... and definitely applies to libraries/frameworks/tools for developers.
This makes a lot of sense to me, and explains why you always think "I can do better than that monster", and it does always feel better at first, then then inevitably grows to feel like a monster where it's hard to make any changes.
Especially when we are thinking about tools for developers, where developers are the users, libraries or web frameworks and such. Or even languages/ecosystems. A bunch of existing libraries/frameworks/platforms/ecosystems are a mess... surely we can do better! let's make a new thing!
This explains why we are always hopping to the new thing, and always convinced the new thing is better...
And the new thing is better and so much easier to work with, even though it doesn't have all the features the old thing did, but okay, we just need to keep building it out to encompass those features, using our much better sense of architecture and usability that we've proven we have because look how clean and simple and usable our first draft is!
Now, there is such a thing as better or worse designed, as the OP admits, poorly implemented or beautifully implemented. But... comparing the new thing that only has the most basic features and seems really elegant to the old thing that covers all the edge cases... isn't actually a good comparison to tel you which is better implemented. That new thing is going to get cruftier when you cover the edges, _always_.
And it shows that if you want to keep your thing feeling smooth and elegant and easy to work with.. you have to keep it as small as possible and resist all feature requests!
> For a feature to add value to your product, it needs to be useful to users. Features can have a negative value when the technical debt they add to your product outweighs the value they add to it.
Thinking of tools for developers where developers are the users... oh yeah it's true.
> A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones
I would describe that as limiting the number of "concepts" inside your code... and definitely applies to libraries/frameworks/tools for developers.