Musings on Tech Debt (2020)
decompiled.dev
decompiled.dev
One area is when a developer can deliver something to the business quickly by amassing large amounts of debt. The developer gets patted on the back, maybe a raise or a promotion, then leaves. That debt is then paid off by future generations.
Tech debt doesn’t necessarily means the design doesn’t work. The design could be functional for the business needs at the time developer but hard to change when future requirements are needed. Poor variable names, spaghetti code, hard coded values, etc. are often “cosmetic”. Fixing that stuff doesn’t really change the overall design but the rewards pay dividends when a new developer needs to understand and update the system.
>> Refusing to pay financial debt has ethical implications that refusing to pay tech debt doesn’t have. Paying off tech debt generally involves redoing previous work, destroying previous investment.
You could say that "tech debt" always originates from a lack of understanding or a lack of time (deadlines or rushed work). So the term "debt" is indeed not that helpful to think about it. In the first case, the lack of understanding when trying to create complex systems is most often unavoidable, even for experienced devs. Trying to correct too often too soon will be a problem here too. It's a fine line: too many mistakes accumulate, and you will be unable to make any progress anymore, and the cost of cleaning up everything might be too high. On the other side, trying to clean up everything as the smallest issue is noticed will make it very hard to go through an "exploratory phase" fast enough to gain the required insight, and a lot of issues are only understood once systems are up and running, so you kinda have to try to get there anyway. The better devs you have here, the better they will be able to ride this whole process.
For deadlines and rushed work, I think "technical debt" is pretty fair already. Because while sometimes the result of rushed work is basically the same as the previous case where what you lack is understanding, the process and the context is very different. Many devs will know that what they are doing is not solid, stable progress, and won't be happy about leaving it there forever. It's not a side effect of trying to learn, but instead trying to deliver, and that makes people much more uncomfortable. Also, it's much less gratifying having to work hard when you know what you are doing is not even good progress, but just a crutch. In the side of context, there's also the fact that on a rush there's often poor planning and goals are prioritized without much consideration for the path to reach them. The lack of a clear path has consequences. So I think that although code can be "equally bad" on both situations, there are significative differences, and maybe we should treat each case separately. You really need to reserve some time after sprints and rushed work if you want to keep moving ahead confidently afterwards. So "debt" doesn't seem wrong there.
For example, as a business why would you make an application with perfect and ideal code before proving that there’s a market for it. It’s akin premature optimisation.
I also think it’s a poor choice of wording because debt has negative connotations and instead should really be thought of as a business decision, that once the product starts to mature, the mortgage will need to be paid off.
If it was truly a debt, then surely for it to be financially viable there would need to be an equal credit somewhere, however this is never mentioned.
It’s more like picking the right tool for the job at the right scale.
If you want to dig a hole in your garden a normal spade will do just fine, if you want to dig foundations for a building, you might need something a bit more. You can still use a spade or many spades or perhaps you can pay for a digger. It’s a trade off.
A lot of the technical debt discussions I've read are very development team focused. What is often missing is the value to the user. Assuming your software is meant to make some group of users more efficient, over certain time periods, the user is getting value regardless of the cleanness of the code (within certain reasonable limits).
For most of my career, I've done small team internal software projects. The value of those projects is the improved efficiency of the users minus the amount of developer hours put in. Time spent refactoring can absolutely be worthwhile, but code improvements that don't add to user efficiency have to be carefully chosen, otherwise you're cutting into the value the organization is accumulating.
That being said, things do change with time and team scale too. I am responsible for some code that is > 10 years old, and the way things are done have changed - some things down to fashion, some things down to the skills in the team and some things down to the size of the team. As such, we need to refactor and bring it up to the latest building regs.
A lot of ‘technical debt’ comes from people not thinking or understanding. The one case I’ve seen it apply is where i make a change without unit tests and really do come back and write them later. In that case the cost of the tests is figuring how to write tests in some area of the code that I don’t know how to write tests and I feel rushed.
The lack of understanding or thinking that might lead to people re-visit code should be viewed almost as a defect, along with not having test coverage.
Therefore the term debt, I think, is a good analogy, because there is a conscious decision to accrue it. It should be reported regularly and monitored with the original decision behind it.
Sometimes I’ve put off writing the unit test (in an area of the code that has been around for months or years w/ little or no testing.) and made a bug fix or small feature. I had a plan to revisit it when coming back to the same zone and did.
I’ll justify it like this. If a system is not well-modularized for testing and there isn’t a precedent for mocking or similar methods in that area, rushing to write tests can lead to test-induced design damage.
If I walk away from the code a bit somehow it gets reprocessed in my mind and in the meantime I read up on my tools and understand other parts of the system often I come back and find the tests are quick to write and not damaging.
That is, tests written hastily might not be a net positive.
It is much easier to clean up and order things if we do it continuously, because the implied "damage" is much weaker this way. If we think of programs as tools that need care, we might build things that have more longevity. It is also more fun to work with a clean and well ordered system of tools than with something that is messy and chaotic.
Exactly that, and it should be a decision to accrue it.
The implication is that something needs to be repaid (again, generally speaking) later because a short term solution is being implemented now.
I think the reason the term "technical debt" has become popular, is because it speaks in the lingo of decision makers. The implication of "debt" is better understood than the specific technical and design issues we want to resolve.
Similarly "BigData" is more tangible for non-technical people than any of the more specific distributed storage and intelligence solutions. They don't and shouldn't care about the details, but they should understand that the undertaking is "big", as in requiring and providing a lot of resources.
Maybe a better analogy could be found by looking at the lingo of logistics, or any other field where continuously keeping things in order and re-ordering them is paramount.
I disagree, the op doesn't consider security heavy industries. Tech debt can result in a lot of financial problems and many ethical ones. Patch your stuff!
Also, I don't usually comment on this sort of thing, but I must be getting old. that font + background was tough to read.