3 ms·
Yesterday I pointed out to the founder of the company that I work for, in the context of tech debt: "Well, since we moved the goalposts on that project, now we
by gwbas1c 1y ago
Yesterday I pointed out to the founder of the company that I work for, in the context of tech debt:
"Well, since we moved the goalposts on that project, now we're out of 'credit card' tech debt and now in 'Adjustable Rate Mortgage' tech debt. Our goal should be to get to 'Fixed Rate Mortgage' debt."
The problem is that too much tech debt can hold back feature development, or even materially impact hosting costs. In our case, we're a 10-year-old startup, and many parts of our stack were built in a way that makes them very hard to maintain, or on end-of-life technologies that are impractical to hire for. To be quite blunt: The tech debt got to a point where we spent more time on the debt than feature development.
The problem with this article is that it glosses over the impact of tech debt, and how it needs to be handled. An umpteeth refactor for a 3% performance improvement is very different than a 3000x performance improvement that reigns in hosting costs. Backfilling unit tests needed to prevent regressions when building a new feature is also different than rewriting a major UI component because it depends on a UI toolkit that was end-of-life 7 years ago. All have a very different impact to the business and product.
- cubefox 1y agoYeah. I would phrase it like this: There is two things to avoid: "overengineering" and "underengineering". The first case has happened when it later turns out that the developer did put in too much work into a feature than was necessary in retrospect, in the second case that they did put in too little work. At the time of engineering it is usually not clear how much work would constitute over- or underengineering, as this depends on how much the feature gets to be used and evolved in the future. But usually it makes sense to "err on the side of overengineering". Because (limited) overengineering merely means some development effort was wasted, while underengineering can easily mean years of painful tech debt that is an order of magnitude or two more expensive than the wasted effort from overengineering. (It's similar to building a house. You usually want to make doubly sure you really do everything right or more than right, because if there are any flaws that turn up later, this often gets very expensive to rectify, sometimes so expensive that it isn't even worth fixing at all.)
- gwbas1c 1y ago> But usually it makes sense to "err on the side of overengineering". Because (limited) overengineering merely means some development effort was wasted, while underengineering can easily mean years of painful tech debt that is an order of magnitude or two more expensive than the wasted effort from overengineering. In our case there was a lot of overengineering by novices, so a lot of the tech debt involves unwinding overengineering to make a simple change. Some of the "credit card" debt was simply using too many 3rd party libraries. > (It's similar to building a house. You usually want to make doubly sure you really do everything right or more than right, because if there are any flaws that turn up later, this often gets very expensive to rectify, sometimes so expensive that it isn't even worth fixing at all.) My fish tank guy told me how he once went to install in a new home, and the general contractor put a structural beam every 3-4 inches under the fish tank. It make it impossible to put in the filters. (In contrast, I only have one structural beam in the middle of my 180 gallon, through-the-wall, tank.)
- cubefox 1y agoI would guess underengineering (quick and dirty solutions) leads to a lot more tech debt in expectation than overengineering.