my dog learned polymorphism*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Technical Debt Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Technical Debt" Watch "Technical Debt" New topic
Forums: Blog around the Campfire OO, Patterns, UML and Refactoring
Author

Technical Debt

T. Sharma
Author
Ranch Hand

Joined: Jul 30, 2013
Posts: 46
    
    5
We posted an article on Technical Debt on our blog. We hope that the readers will find it useful.


Tushar Sharma (Twitter: @Sharma__Tushar)
http://sharmatushar.blogspot.in/
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2274
    
  28

That's a nice blog post.

Blog posts go into the Blogs forum. I have added this thread there.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4446
    
    5

I'm going to be on a panel to discuss Technical Debt at SPLASH 2013 and have been collecting information on TD in preparation for it. It's interesting to note that Ward Cunningham never actually uses the term "Technical Debt" in the 1992 OOPSLA experience report. He only ever mentions the term "debt analogy Metaphor" and "going into debt". As far as I can tell, the term "Technical Debt" was first attributed to Dave Smith by Johanna Rothman in an article she published in 2000.

There are some folks, notably "Uncle Bob" Martin, who say that what many people consider as technical debt these days is not actually technical debt; it's just a mess. https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt

After analyzing what Ward Cunningham says in his 2009 video posted on YouTube, I tend to think that Ward and Uncle Bob think the same way about "debt" in software. If you're going to choose to go into "debt", then your software better be well-factored and understood so that you don't have to pay a lot of interest in making it reflect newly found understanding of what the system should be doing. My interpretation is that "debt" in the sense that Ward uses it refers to an incomplete understanding of what the software does or should do. Ward considers it a GOOD strategy to go into debt so that you can get a better understanding of the software. You can then go back and apply whatever you learned from running the immature program and make it reflect your new understanding. This would be a good strategy in the context of doing test-driven development (or test-first programming as it was known back then) and the practice of merciless refactoring. Going into debt without ever going back and making the software reflect any learnings basically amounts to not paying back what you owe, and this is what kills us as developers.


Junilu - [How to Ask Questions] [How to Answer Questions]
T. Sharma
Author
Ranch Hand

Joined: Jul 30, 2013
Posts: 46
    
    5
Nice to realize that Ward never used the term "Technical Debt".

Temporarily, it could be beneficial (in terms of time to market) to introduce technical debt; however, realizing this that we are achieving the goals (time to market) at the cost of technical debt is not common. This non-realization makes the topic interesting.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4446
    
    5

T. Sharma wrote:Temporarily, it could be beneficial (in terms of time to market) to introduce technical debt; however, realizing this that we are achieving the goals (time to market) at the cost of technical debt is not common. This non-realization makes the topic interesting.


I really would not use the term "introduce technical debt" because it should be about choices and trade-offs.

In the example that Uncle Bob gives in his article, the choice was between a design that used frames vs one that used AJAX. The constraint was time, or more precisely, the lack thereof to write an AJAX framework. If you go back to the common Construction metaphor, you can choose to have vinyl tiles instead of ceramic tiles for your floors because of budget constraints. You can then decide later on to upgrade to ceramic tiles or a different material when you are in a better financial position to do so. Until then, the vinyl tiles may work for you just fine.

Author Esther Derby has a talk entitled "The Language of Change" in which she points out that we should carefully choose the kind of language we use to discuss changes that come with a move to Agile development. The need to carefully choose language is related to the kind of mental images that certain words and phrases create in our minds. Some images can give us the wrong impression or lead us down unproductive paths of thought. I think the same applies to any discussion that deals with abstract topics such as the Debt Metaphor.

When we talk about the Debt Metaphor, I think we should be very careful about the kind of terms we use so as not to contribute to the semantic diffusion of the term. I doubt that the term "Technical Debt" will ever go away at this point but I think that the way it is commonly used nowadays tends to muddle the intent Ward originally had in using it, which was to explain the refactoring that they were doing on the WyCash project. In Ward's mind, going into debt was a GOOD strategy because it allowed them to gain more understanding of the program and consolidate the code and design through refactoring.

To stick with the original intent of the Debt Metaphor, you could say that you "make a choice" or "decide" to go into debt because of certain constraints: time, skill, technology, etc. When you say "introduce technical debt," the term conjures images of programmers purposely writing messy code or just going with a poor design. For some reason, this tends to justify the kind of unproductive behavior that gets everyone in trouble. You could argue that the same goes for "make a choice" and "decide" but I think these terms give you a better sense of the kind of thought process that you should have when considering what to do about your code/design.

Another interesting thing to note is that Esther's talk is based on the work of George Lakoff, the same UC Berkeley professor whose work inspired Ward Cunningham to come up with the Debt Metaphor.
Muhammad Khojaye
Ranch Hand

Joined: Apr 12, 2009
Posts: 449

Nice Blog.


http://muhammadkhojaye.blogspot.com/
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Technical Debt
 
Similar Threads
SonarQube: Talking to managers/execs about code quality
WA #1.....word association
Technical Debt: Is it really what you think it is?
Jeff and Tim...a question about Agile and good design
SonarQube in Action: Technical Debt