Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re^3: RFC: Exploring Technical Debt

by gwadej (Chaplain)
on Sep 28, 2009 at 04:21 UTC ( #797820=note: print w/replies, xml ) Need Help??

in reply to Re^2: RFC: Exploring Technical Debt
in thread RFC: Exploring Technical Debt

I had a thought on this early this morning when I was somewhat less than awake.

Although there's no concept of separate lenders in technical debt, we can get something almost as good. When faced with the need to take on technical debt it might be possible to select among several solutions that have different interest rates.

Imagine a problem that we don't have time to solve correctly, but a small amount of brainstorming produces two potential hacks. One is the nightmare you normally get in this situation. The other leaves some wiggle room for a few unit tests or some minor validation code that helps recognize edge cases.

Even though this second solution still increases the technical debt in the system, it has a lower interest rate because it helps to point out the places where it makes maintenance harder.

I have known good programmers who added some kind of trap code in a half-way solution to point out when boundaries were reached. This allowed writing simpler, mostly right code that could be ready now, without incurring all of the problems of the complete hack. When we approached the areas where this solution began to break down, we got an indication that there was a problem and could fix it when needed.

This might even be a good tactic to help mitigate the risks in a quick-and-dirty solution.

Imagine the following scenario.

  • The right solution will take a week
  • The quick hack will take a day, but will cost a day's effort every month to work around/clean up
  • With an extra hour or two of effort, we can think we can reduce the monthly cost to somewhere between 2-4 hours.

It is likely the business side and technical side would see this as a worthwhile investment of extra time.

G. Wade

Replies are listed 'Best First'.
Re^4: RFC: Exploring Technical Debt
by gwadej (Chaplain) on Sep 28, 2009 at 04:40 UTC

    As I was writing the other comment, another strategy came to mind. Anyone with a mortgage or car loan is probably familiar with a useful piece of advice for servicing a long-term debt. Making an extra payment now and again can make a significant difference in the time to pay off a loan

    In the context of technical debt, we could imagine a commitment to spend some time now and again to adding tests or doing some refactoring to pay of some of the principal of the technical debt when we get a little time. Imagine you have a little time at the end of an iteration, adding a few unit tests or validation for edge cases to our worst offenders could reduce the cost of working with this code. As the debt is reduced, so is the interest we end up paying.

    In the case of a financial debt, this kind of extra payment strategy requires a fair amount of discipline, but it can reduce the time to pay off a debt significantly.

    It might even be possible to schedule this kind of work in a bug tracking system or as part of the task list for a project. We could consider this lower priority work that is only scheduled when we begin to catch up.

    G. Wade

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://797820]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (2)
As of 2018-05-27 22:03 GMT
Find Nodes?
    Voting Booth?