DevOps Zone is brought to you in partnership with:

Geoff Papilion has made a living running infrastructure for the past 15 years. He is currently employeed at Wikia.com, scaling the infrastructure to 1.5 billion request per day. Geoffrey is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

Sometimes It’s Okay to Incur Technical Debt

02.19.2012
| 7576 views |
  • submit to reddit

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/

Published at DZone with permission of Geoffrey Papilion, author and DZone MVB.

(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

Sure. Sometimes now and imperfect is > later and less imperfect (there is no perfect). Just make sure that the future costs/risks are clearly communicated up the chain.

Lieven Doclo replied on Sun, 2012/02/19 - 11:01am

I strongly disagree. The time you'll spend cleaning up the mess added to the time creating the lesser solution is a lot bigger than getting it done right in the first place. The fact that one comes to the point that he or she is willing to settle for a lesser quality solution is merely the consequence of that person's inability to say no and to compromise on quality. 
 
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.

Just make sure you can document it, and come back later when you have more time.

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

I am not sure if it is OK to incure technical debt, I will speak about it with my brother and he will explain it to me in a simple way so I could understand it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.