3 ms·
The difference is that, he claims, "making messes is never justified". Which is somewhat divorced from the reality of real world development that sometimes, eve
by brazzy 17y ago
The difference is that, he claims, "making messes is never justified". Which is somewhat divorced from the reality of real world development that sometimes, even if you do everything right, comes down to firefighting, making the deadline at all costs, and doing what you're told even though you disagree with it.
I agree in that you should not justify messes by calling them "technical debt" that you'll pay back later when in fact there is no pressing reason not to do it right other than your own laziness. But then, that's also true for the design variety of technical debt.
- DanielBMarkham 17y agoPerhaps what he's saying is that folks use the term "technical debt" as a fancy way of getting away with writing crappy code. When in fact technical debt is the stuff you couldn't have avoided if you wanted to, because you didn't know then what you know now. Ok, I'll buy that. But to me, from an external point of view, my developers have all this extra work to do which doesn't have to do with their backlog. So who cares what the term they use is? I think he's just mad at sloppy coders co-opting a favorite term. I see so much muddled language it doesn't really bother me. As one other poster noted, it's not like when you coin a term you get to define what the term means for the lifetime of the universe.
- prodigal_erik 17y ago> technical debt is the stuff you couldn't have avoided if you wanted to, because you didn't know then what you know now. I've always understood it as just the opposite: the circumstances don't permit doing it right, so you do it badly knowing it'll cause problems, and the costs grow the longer you leave it unresolved. Debt is a metaphor for choosing to sacrifice your future self's resources, not just making mistaeks (even if they have the same result).
- DanielBMarkham 17y agoMe too. That's the way the term is commonly used. But if I understand this author correctly, that's not what the term originally meant.
- prodigal_erik 17y agoNow that I reread it, "[...] code that is clean enough to be able to refactor as you come to understand your problem" is a strange statement. Isn't refactoring just producing a cleaner version of the same solution?
- jerf 17y agoHis heading is "Messes are not Acceptable"; my question is, acceptable to whom? Based on the priorities I get from my customers (/bosses), messes damn well are acceptable, and if they don't give me the time to fix them, what am I supposed to do about it? Yes, I do endeavor not to make them in the first place but even after years of experience nobody can completely avoid them.
- DanielBMarkham 17y agoNot only that, but coding is an inherently messy business. Even if you are Uber-Coder. That's just the nature of the job. You can choose languages and platforms that match the problem domain to the point of minimizing this, but it never goes away. And the longer code sits, the more "cruft" builds up on it. Once again, you can minimize this, but it never goes away. I think once you learn good coding practices and start groking how easy that makes things, you start getting this bad attitude towards everybody else. Those other stupid programmers, you think, If they were only as smart as I am most of these problems would go away. Later on you figure out that some of these guys are actually smarter than you, read all the books, could do and teach this stuff in their sleep, and know that their code needs work. At that point you're just beginning to become a true professional.