/1/ “The metaphor also explains why it may be sensible to do the quick and dirty approach.”
/2/ “you only make money on your loan by delivering”
http://www.martinfowler.com/bliki/TechnicalDebt.html
Also, on a different stream of thought, look at the comments about making the debt explicit:
]]>Thanks for your comment - an interesting observation as usual. Note that I’ve delayed replying because I wanted to mull this over a little before posting a response.
Yes, you’re right, I didn’t make this very clear. I have to admit this was because I didn’t think it was useful to take the metaphor as far as you suggest. That is to say, I wouldn’t have regarded it as useful to think of a solution as incurring a technical debt unless there was a need to “settle up” promptly – normally, on the phase of development for the next release.
However, now I’m not so sure. I think a more fundamental way of looking at your point is this: any incurred technical debt, regardless of its size or the form it takes, needs representation in the risk register for the business (and not just for the project); this is the starting point for determining the consequent action to be taken.
I think this topic is worth a follow-up post, but I’ll have to think about it some more first.
- Mark.
]]>you fail to make the main point of the “Technical Debt” metaphore clear.
This is that developers are wrong to assume that “time must be made factored into the development schedule … reworked with more enduring solutions”.
Consider a debt that many of us are familar with - a mortgage. When planning the next month’s finances very few of us factor in repaying the mortgage. What we do factor in is the cost of servicing the debt. Other debts are more expensive and we chose to pay them off immediately.
Applying the “Technical Debt” metaphore to software development makes it apparent that we have a range of options - if the cost is high (a credit card) we can pay the debt off rapidly, if it is lower (a tracker mortgage) then we can get better returns by investing our efforts elsewhere.
The choice between such options is a management issue - developers can help identify the debt and the costs of either servicing or repaying it. But it is a management decision which approach benefits the business most.
Alan
]]>[I assume you posted an off-topic comment because there was no logical place to post it, and no contact page for for sending me messages in general - I've now fixed this, you many notice a contact option has appeared on the main menue!]
Unfortunately my Java knowledge is very rusty, and my understanding of the throw spec issues in Java is pretty much nebulous 
C++ however - as you (Alan) know - is a very different matter! Thanks for the suggestion. It may be a few days before the article appears, but I’ll start work on it!
- Mark.
]]>Throw specifications in C++ and exception specifications in Java are very different beasts and treating them in the same article would only have value if the purpose were to explain the differences. That has been done.
In terms of utility I don’t know of anyone that would argue the C++ version is anything other than a failed experiement. In Java the case is less clear as there are some benefits. (Although it is telling that no comparable, subsequent language has adopted this approach.)
]]>Sorry about the delay in responding, and yes that is more than a little worrying!
I see your code base is C++. Are you suggesting an article about throw specs in C++ or are you suggesing one that includes Java?
- Mark.
]]>grep “throw[^[:graph:]]*([^)]” `find -name \*.cpp -or -name \*.h` | wc -l
222
How about writing “The Only Good throw spec is an Empty One”?
]]>Thanks for pointing out these things. I didn’t know about JUnit being inspired by SUnit. Actually I hadn’t heard of SUnit until your comment. I assumed Smalltalkers would have a unit test framework, so I probably should have looked it up and included it in the above article - I’ll append an update with a link to it.
Re your comment that JUnit “doesn’t fit well with Java idioms”. I don’t know much about Java, but that did surprise me! Could you elaborate a little if/when you get chance? In what way is/was JUnit counter-idiomatic in Java, and how could it work such that it does fit with Java idioms?
- Mark.
]]>