Sins of software development
blog.ionelmc.ro
Sins of software development
1–10 of 42 posts
Re: Sins of software development
#2If you don't know what technical debt is... If you hate making changes in your code, then you have it. If changes are hard to make, then you have it.
I just spent the past 4 hours making a breadcrumb layout in CSS. I hate making changes to fancy layout CSS. Does that mean the CSS language itself is technical debt? :P
(Yes, I know about and heavily abuse less/sass and associated libraries.)
Re: Sins of software development
#3I've seen technical debt accrued without regard at a company once - just before leaving, they had to scrap their whole prior frontend web app and rewrite it from scratch, about a year after they started.
Avoid technical debt at all costs - spending the extra effort on good engineering is worth avoiding an awful situation. Managers of course bear the most responsibility, but developers can do their part too many times.
Re: Sins of software development
#4'Most people assume technical debt is there because of time constraints.'
As opposed to what? He describes three personality traits, only one of which (hubris; not entirely sure why that's the term used given how close it is to arrogance) actually leads to additional technical debt. Both fear, and arrogance (as he describes it) merely lead to technical debt remaining unaddressed; they don't create it in the first place.
I'd posit that technical debt gets created because of time pressure, and that it stays because of continued time pressure.
Almost the entirety of my experience with technical debt has been "Hey, this code kinda sucks" "Yep. We just haven't had time to make it better/it's never been enough of a priority to make it better". Not "Don't touch that, you might break it!" (caveat: I've run into this on long lived, gigantic defense contracts) or "No, it's good the way it's written" (never run into this). I can't even imagine a developer who is any good saying that latter one; you -always- realize ways you could have made it better after the fact.
It may instead be a manager calling the shot that refactoring isn't necessary/worth it (the arrogance he mentions), and we can debate whether it's fair for management, rather than developers, deciding when refactoring is necessary, but it's still based on time/money constraints; I've never met a manager who would say no to a refactoring attempt whose cost was nil (i.e., the dev, QA, and anyone else who'd need to be involved, offered to do it in their free time).
EDIT: And even technical debt incurred because of changing requirements comes about because we didn't take the time initially to fully understand the requirements. This isn't a bad thing, it's what agile is predicated on, that we don't need a full top to bottom understanding of the problem space to deliver something useful. But it still can be expressed as a time constraint, one on the time it would take to expand our understanding, rather than one on the time it would take to code.
Re: Sins of software development
#5I've seen technical debt accrued without regard at a company once - just before leaving, they had to scrap their whole prior frontend web app and rewrite it from scratch, about a year after they started. Avoid technical debt at all costs - spending the extra effort on good engineering is worth avoiding an awful situation. Managers of course bear the most responsibility, but developers can do their part too many times…
But think about what you just wrote! "Avoid technical debt at all costs" --- of course you don't mean that literally.
What you mean is "avoid technical debt at a price at which paying down the debt is good value", which is...totally banal.
Technical debt is half of a complicated trade-off. You can't say anything more useful than "make good trade-offs" in the abstract...Which is why I hated this article, and others like it.
Re: Sins of software development
#6>it can be shortly summed up as inadequate technical choices that incur maintenance costs
I'm not sure I like that summing up. Inadequate for what? If anything, "good" technical debt is making perfectly adequate choices (butno more) for your short term needs with the full knowledge that you are incurring acceptable long term cost.
Re: Sins of software development
#7I've seen technical debt accrued without regard at a company once - just before leaving, they had to scrap their whole prior frontend web app and rewrite it from scratch, about a year after they started. Avoid technical debt at all costs - spending the extra effort on good engineering is worth avoiding an awful situation. Managers of course bear the most responsibility, but developers can do their part too many times…
But think about what you just wrote! "Avoid technical debt at all costs " --- of course you don't mean that literally. What you mean is "avoid technical debt at a price at which paying down the debt is good value", which is...totally banal. Technical debt is half of a complicated trade-off. You can't say anything more useful than "make good trade-offs" in the abstract...Which is why I hated this article, and others l…
Well, "at all costs" is used as a colloquy to mean "as much as possible". Sometimes it isn't possible of course, but managers and developers owe it to themselves to make better decisions many times.
I think the worst offender I see is in developers when it comes to this - many tend to cut time and be afraid of exploring something new.
Re: Sins of software development
#8Technical debt for me is code without tests.
If I can't properly determine the intent of code, and there are no tests to ensure that refactoring is not breaking expected behavior, then it becomes difficult to work with that code in the future and I may end up creating workarounds and bypasses instead of simply updating the code.
Re: Sins of software development
#9If you don't know what technical debt is... If you hate making changes in your code, then you have it. If changes are hard to make, then you have it. I just spent the past 4 hours making a breadcrumb layout in CSS. I hate making changes to fancy layout CSS. Does that mean the CSS language itself is technical debt? :P (Yes, I know about and heavily abuse less/sass and associated libraries.)
I don't think many people would disagree that CSS/HTML have certain encapsulation deficiencies. But I think that less/sass just make you more efficient at writing unmaintainable stuff.
Shadow DOM and WebComponents solve this better by encapsulating styling and markup concerned with the same widget or object. Without those you still have styling concerned with different markup in the same place. You can use less/sass but it's not true encapsulation - you still have to pay attention that you don't break styling for unrelated stuff when changing styling. Thus the "unwanted pain".
Re: Sins of software development
#10I still think the whole metaphor of technical debt is borderline worthless. Taken to its extreme the simple act of using programming language is akin to taking a loan against the expertise of other workers.
That is, "technical debt" should be regarded as normal debt, if the metaphor is to be worth anything. As such, so long as you are making more progress due to the debt than you would in paying it back, it is probably wise to keep it.
Consider, nobody would say you should put every dime you own into paying off a mortgage. How would you eat? Now, they will say to be wise and pay attention to the amount of debt you take on.
But realize the main problem with this is looking at personal/consumer debt as at all analogous to business debt. They are not as comparable as basic intuition would lead you to believe.