61–70 of 147 posts
Ok, so the article basically said to comment before reading. So technical debt is anything in your codebase or infrastructure that makes things harder in the development process or limits the set of features that you can offer. You live with it because this limitation is not completely blocking, otherwise you would actually fix it, but you also don't want to forget about it or pretend like it doesn't exist. So you tr…
Earlier quoted context omitted.
I don't disagree with the article, and I don't disagree with you - I'm more of expanding the ideas you discussed. I think the key here is indeed that technical debt should not be used as an excuse to write poor code. But I think it may be hard to systematically tell apart code that was written intentionally fast and poorly, and code that just was written to explore the market. It "is accepted" that the most of the co…
It's not poor code it's just code that prioritises shipping now over writing for some hypothetical future state.
You can ship good code fast.
Shipping slow is not a guarantee of good code.
I think the pathology here is defending "sloppy" or "negligent" code by the need to ship fast, when in fact you probably could ship as fast with cleaner code, but the coder just could not care enough.
My pet issue with technical debt, is what happens when engineers are allowed to pay it down. In the best case people embark on well-informed yet insane ”version 2.0” over-engineering binges. This can be nice, but is often a waste of time. Quite often the ones who cried “muh technical debt” in every meeting simply did not understand the problem being solved by the debty code, and end up making something novel but equa…
That's what you get from inexperience not from paying off the debt. It's called second system effect and it's relatively easy to avoid by methodically documenting original and mercilessly avoiding adding features. And this includes design features that are not immediately shown to save a lot of time and code. Every such feature needs an advocate and also a prosecutor, and alternatives have to be briefly explored usin…
Seniors point out specific issues with specific consequences and lay out specific actions to resolve/mitigate. The term “technical debt” isn’t usually needed in that case.
Technical debt terminology is a fig leaf for “I dont understand and I wont put in the effort to learn”.
Earlier quoted context omitted.
I disagree. Building complex solutions that you don't really need is also "bad engineering". Part of the complexity comes from the fact that the needs that software projects solve are not fixed, they change during the products life cycle. Even architects use technical debt, it just comes in different ways. Instead of trying to plan what every room is for, architects leave empty sections, to be determined later. A lot…
Seems like you feel that establishing data access patterns that have the possibility of scaling up to 100x more users requires an additional 3 weeks of initial developer time I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable. You don't have to actually _use_ spanner or cockroach or vitess in your initial prot…
Earlier quoted context omitted.
Seems like you feel that establishing data access patterns that have the possibility of scaling up to 100x more users requires an additional 3 weeks of initial developer time I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable. You don't have to actually _use_ spanner or cockroach or vitess in your initial prot…
Most teams I have encountered so far don't have an anyone that experienced with scalable database systems. So you have to choose the best you can do at that moment without loosing your momentum. When more users come more funding will come and you can hire someone who can repay the technical dept chosen before.
The problem is rather that the technical debt is often not repaid.
Technical debt implies that it is a technical decision, when mostly it’s a business one. Debt has a negative connotation, where as it’s more like a mortgage. I always wonder if there’s an equivalent term in manufacturing.
Debt in business is a well-known and appreciated way to get things moving now at some additional cost later.
This applies to both financial debt and technical debt. The difference between those, and hence the name, is how you incur and repay it, not how you make the decision. It's not "business debt" because you can't repay it with "business".
If I were to imagine "business debt", it'd be making decisions now that work well for the moment, but won't work well in the future and will actual retard the business for a while later. You could do it the "right way" now and have fewer customers up front, or you optimize for now and have more customers now, but make it harder to get customers later.
Likewise, financial debt gives you more money right now and costs you more money later. Technical debt gets technical stuff working right now, but takes more time from your tech team later when you need things to be different.
"Technical debt is the burden that implementation choices may place on future development."
Nothing in the article leads me to think that this is either incoherent or irrelevant.
With regard to its coherence, I say that it is empirically verified: it actually happens!
The claim that it is not technical because it has consequences beyond the technical is a non-sequitur. Just about everything we do that is 'technical' has implications and consequences that go beyond the technical: The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that. The root cause of a problem and its broad consequences are separable concerns.
This formulation avoids the objection that its only debt if it is paid back in the same form as it taken out, but that was a tendentious claim anyway - it is completely reasonable to consider the situation where, say, I give a farmer cash in return for some produce at harvest time to be a debt. If we are going to be pedantic, the author might as well say that technical debt is not debt because it is not an exchange of money. Arguing over dictionary definitions is not going to lead to anything useful in this matter.
What? The US consumer debt industry would beg to differ.
I was hoping that maybe they’d extend the concept to a liability or something. In general the idea is that you’re borrowing a resource from your future self to accelerate a business outcome now.
> Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense. This really is NOT how you start an article. You only come across as needlessly assertive and arrogant. > Nobody explained technical debt; we assumed it was a fundamental property of the work. Total BS. Literally every manager I ever addressed in a sentence wh…
My initial thought was that, as academics, they were going to be aloof and out of touch. However, as a boots on the ground dev who has worked from start up through multi-thousand employee public company, and who has held leadership roles, I agree with the article. Maybe if you read it, you would too.