• Archives

  • Categories

  • Advertisements

Technical debt

There is an interesting ongoing conversation I am having with Pier G around technical debt.

In one sense, “Technical debt” is a brilliant term that establishes the debtor’s(the system) obligation to repay at a future point.Until that point is reached, this debt will have to be serviced with interest payments ( harder maintenance, lesser flexibility etc).

In another sense, the word technical seems to imply that the decision is taken by technical stakeholders, which is simply not true.This is not just a technical decision. It is about features, it is about investment and it is about opportunity cost.

Pier G says ” And as a general rule I prefer to think that making a technical debt is wrong!”

It is all right to have a preference, but it certainly is not his sole decision (unless he is a 1 man army building software for himself).

To be fair, he also says “And … having someone in the team who’s able to decide when it’s time to make that mistake is a GREAT value.”

Hurrah !! We are in concurrence except that I wouldnt call it a mistake, though it might be one.

One has to judge every decision point with the business value yardstick to ensure that correct decisions are being made with available information at that point of time.

Comments ?


3 Responses

  1. My ‘general rule’ is something related with ‘values’.
    As you know better then me, we have values that help us in making decisions when we don’t have a practice, a rule, … (that is more or less every day in this fast changing context).
    Going back to values help us in having a common, shared and ‘good’ direction.
    That’s why I prefer to be a little bit ‘strict’ on that: If I have a doubt, I go to the general rules. If I think this is probably the case to change the rule/value, I go to the general rule. If I DO think it’s the case to change the rule/value … well .. let’s talk about it!

    Thank you for this open discussion: I appreciate your blog and what you are doing.


  2. Ken Schwaber has this to say on the subject of making the decision to reduce quality (ie acquire technical debt) in order to hit a deadline:

    We have to be courageous. The intention of this conversation is to make you aware that it’s not just a phrase, “be courageous”, but it’s a professional responsibility which, if you follow up on it, not only will you feel better when you come to work, but it is for the good of your company. And if you don’t do it… it’s going to kill your company. This is not just a trivial little thing, “let’s not refactor because…”, this is a sacred trust … to drop quality is a catastrophe for our company.

    Worse yet, our pattern is not to tell anyone, right? So a classic thing we do now is: if you are in a release and the customer absolutely has to have it earlier and the quality has to be dropped… that is not a Product Owner decision, that is not a Customer decision, that is a drop in the value of a core asset of the company, and it has to go in the books. That is a CFO, COO, CEO type of decision.

  3. Kerry,

    The association that most developers have with technical debt is that of reduced quality whereas my interpretation was a short term fix. I believe the former relates quite heavily to compromise in working practices such as no tests or no time to refactor etc. Mine was more around not overkilling a solution. I appreciate what Ken has to say and couldnt agree more. See my follow up post on Technical debt for the same.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: