4 ms·
"This way, though you may be accruing technical debt, you are also accruing revenue immediately, and you can reconcile the debt over time." The last part of th
by tdumitrescu 13y ago
"This way, though you may be accruing technical debt, you are also accruing revenue immediately, and you can reconcile the debt over time."
The last part of that statement is troubling, because it happens so rarely. I think a lot of devs want to lean towards more engineering "up-front" because they've been smacked repeatedly with the business reality that the first version of that code is what you're going to be stuck working with, and building on top of, for a long time.
- antimagic 13y agoYes. "Reconciling technical debt" does not fit in well with the philosphy of the title. Why refactor when you can just write more code that "fucking works". Of course, those of us with a bit more experience know that a badly designed module can very easily get enmeshed in a system, with the whole system being designed with the bad module's deficiencies being taken into account. Now you don't just have to refactor the bad module, but all of the code around it too, which turns out to be a difficult ask, so nobody does it, and the bad code becomes locked in. As always, the higher up the software stack you work, the easier it is to justify bad code, but when you are providing infrastructure code, that will be used by applications, you had better be sure that your interfaces are clean, and your implementation stable. Try pushing some inelegant code to the Linux kernel, and you won't enjoy to the experience...