> <i>I'm an avid supporter of Kubernetes (see About me), but I would never suggest that a small team adopt it from the start. Even with expert knowledge of Kubernetes, taking it on as a dependency still creates loads of maintenance debt.</i><p>Somewhere along the way, it became fashionable to build out your devops on day one as though you’ll be Google tomorrow, but to write your code without any architectural foresight as though the only thing that matters is tomorrow’s deployment.<p>It’s always nice to see people advocating towards a thoughtful balance.
Good APIs between your code (that means programmatic interfaces, not necessarily over the network) help alot.<p>If you have a subsystem conform to a good API and is well behaved it can be rewritten. It is allowed to have some tech debt.<p>If the subsystem is sprawled through other subsystems that tech debt doesn't get paid down because now you need an expert in all those areas to fix it.<p>I swear I have worked places where there is code no one currently at the company can understand. At best you micro-fix for bugs and back the hell away!
Please stop using that term. The idea was to communicate "technical stuff that needs to be done" to product management and sometimes have a lever to rework the shortcuts taken due to business pressure - in that case it should be called product debt, and not tech debt. Product took out the money (earlier release), not technology. And needs to pay it back with scheduling development work.<p>What I see is that the term makes technology look bad, doesn't work as a lever and demotivates developers.<p>Be a craftman, don't do technical debt. For time to market create a zerocode/crappy MVP that you throw away. Schedule real technical debt like DB migrations and do them as needed.
this seems wrong, the examples given aren't examples of technical debt. Starting a monorepo isn't technical debt, changing to something else later isn't technical debt. Technical debt would happen when doing that change you delay a part of the migration, or leave out some testing because its too tricky, or anything you are delaying till some time later that ideally should be done now.
Here we go again! Trying to use a financial term to describe "bad" past decisions. I do not see this term used when we build bridges or houses -- we either say they were time or financial constraints or it was a bad job. And certainly intermediate (temporary or not) supporting constructions are not viewed as debt.<p>Nobody built the pyramids in a day.<p>Here is a different attempt on definition: An occurrence on debt is when a higher up decides that a product/construction must be ready when it clearly is not, and thus convinces/bullies the engineers and put their signature on it.<p>Analogies can be a great tool to communicate or for prose but don't take them literally.
Technical debt is if you purposely don't write unit tests because you don't have the time for it.<p>Or clean code because no one will ever touch it again.<p>Or a feature you only need once and just write it somehow.<p>And then all this shit stays in your product and starts dragging you down.<p>This is totally different than when you start with a monolith and know that you might want to rework it later but accept potential future work.<p>And you should start with a modular monolith anyway.<p>I don't think it's reasonable to try to redefine the term technical debt.