Sometimes It’s Okay to Incur Technical Debt
Its time to admit that sometimes it’s okay to incur technical debt, particularly when it comes to getting it done. So many times, I’ve run into to places that have constipated operations environments, or automation processes because something is hard to do automatically.
If you can’t automated it, don’t block all other tasks because of one
issue. It better to have a partially automated solution, than none at
all. Just make sure you can document it, and come back later when you
have more time. Don’t let your tools be your excuse for not doing it, it
only makes you look bad.
WDYT?
Source: http://blog.hypergeometric.com/2012/02/16/techincal-debt-better-than-not-doing-it/
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Andrew Thompson replied on Sun, 2012/02/19 - 3:34am
Lieven Doclo replied on Sun, 2012/02/19 - 11:01am
There is no excuse of technical debt, you're just moving the problem to a later date and assuming it'll be easy to change afterwards. Don't kid yourself, if it's easy you would've done it right in the first place.
The fact that we as developers are willing to accept some technical debt is the main reason why there's so much crappy code floating around. Being willing to add technical debt is the worst hard-drug in our line of business. There is never a happy end once you've started doing it. But that's my humble opinion.
Mladen Girazovski replied on Mon, 2012/02/20 - 7:23am
I compeltely agree with Lieven.
If you can't get it right in the beginning, when the system is still small and simple, you won't get it right afterwards, when it has grown complex and contains prod. data.
At least not without huge efforts.
That is the #1 excuse IME for ignoring quality, based on the presumtion that "later you'll have more time and less problems to solve"...
The attitude "better something than nothing" might be appropriate if you lower your standards, getting something somehow done is not exactly what most people consider as "professional".
Edwin Keeton replied on Mon, 2012/02/20 - 10:03am
Ditto, I completely agree with Lieven.
The "have to get it done at all costs" attitude is the cowboy mentality that our profession has been fighting against now for decades. Apparently it will never ever be completely eliminated.
Chuck Dillon replied on Mon, 2012/02/20 - 1:32pm
In an ideal world, sure, you should "never" accept unambiguous technical debt. If the world was run by the developers and there was no accountability to something bigger (i.e. the marketplace) and SEs didn't need to see something shipped and actually used to get satisfaction in their work, sure.
But I've never seen an environment where such idealism can win the day. It's an unavoidable reality that the net cost is a function of much more than the technical/engineering costs. It is the norm that organizations can optimize their success by making tradeoffs and accepting a less-than-perfect solution sooner rather than let the competition eat their lunch while they hold out for the almost-perfect solution.
Even in a world free of non-technical tradeoffs, if you consider the high degree of subjectivity and ambiguity in quantifying "technical debt", along with the highly valuable need to occasionally actually get closure and achieve something, you still end up with tradeoffs that will routinely leave you short of almost-perfect.
Roy Masrani replied on Thu, 2012/02/23 - 4:04pm
Great discussion, but I dont think this is the right question. I don't think it is ever "ok" to incur technical debt, but sometimes it is unavoidable. As a perhaps dumb analogy, you would never ask a brain surgeon if it is sometimes ok to make a mistake just to get it done faster.
I think that there are developers (a) who understand that their actions will have consequences further down the line, and (b) those that don't understand or don't care or care more about getting it done at all costs. (a) types will - IMHO - keep making decisions with technical debt in mind and try to minimize the TD. (b) types are the ones who should be told that TD is not acceptable under any circumstances or should not be in this profession.
Lily Marlene replied on Thu, 2012/06/14 - 3:46pm