Martin Fowler describes four kinds of "technical debt" | Hacker News Reader

Martin Fowler describes four kinds of "technical debt"

martinfowler.com

38 pointsobie16 comments

Typical way that competent developers end up with technical debt:

1. Customer/user/consumer has a vague idea of what they need but doesn't know how to express it.

2. Developer works with customer to learn their business and understand their requirements.

3. Developer throws together a prototype to confirm that he understands the problem.

4. Customer sees that developer is on the right track. If these 9 enhancements are done, then we'll really have something.

5. Developer quickly adds 9 enhancements to prototype.

6. Customer loves it! Move it to production so we can play with it for a while.

7. While customer plays with it, developer maps out a plan to architect, refactor, and scale the prototype to be "production worthy".

8. Developer is pulled away to 5 other urgent projects.

9. Customer continues to use prototype as production software.

10. Two years later: "Who wrote this shit?"

Which quadrant does that fit into?

LOL, you just described the way that Rails first makes it into a lot of large organizations. Luckily, if you follow Rails conventions you should be pretty close to "production worthy" at step 6.

As for step 10, it's the rare system that doesn't suffer that two years into production.

A prototype is prudent deliberate.

Shipping the prototype as production code and not maintaining, fixing, rewriting or deleting it would be reckless debt.

"Diving debt into reckless/prudent and deliberate/inadvertent implies a quadrant, and I've only discussed three cells. So is there such a thing as prudent-inadvertent debt? Although such a thing sounds odd, I believe that it is - and it's not just common but inevitable for teams that are excellent designers."

The concept of prudent-inadvertent debt was new to me but immediately made sense.

I believe Steve McConnell calls this long-term technical debt because it kind of tends to creep up on you.

I often find I have an urge to write something a certain way, sometimes one that is different from best practice. I take the time to evaluate the results of what I do. Sometimes I look back at something and go, "I should have stuck to best practice," but increasingly I go, "I realize now the reason why it made sense not to follow best practice."

I like Rands's definitition of best practice:

"A phrase used to convince you to do something different that assumes you don’t actually want to know why it’s a better approach."

http://www.randsinrepose.com/archives/2009/07/13/the_words_y...

With the assumption that 'debt payed' means 'product shipped to happy customers', I think that fourth quadrant is a bit of a red herring in that it's not so much a kind of technical debt that must be repayed; but more of a 'technical buyer's remorse' that is a function of good engineers who continuously reflect on the design decisions they've made.

I think that Fowler would say that a design should be constantly evolving. That's the agile philosophy at work. Now, you can agree or disagree if you want to, but requirements change so quickly that it's difficult to not agree with him at least partially.

Therefore, it becomes technical debt when these good engineers reflect on their design decisions and don't do anything about it.

Am I the only one bored with Martin Fowler and the whole 1990s object oriented schtick? It was so refreshing last to see articles on fork() and waitpid()...

So you prefer 1970s unix schtick to 1990s object oriented schtick?

So you prefer 1970s unix schtick to 1990s object oriented schtick?

I do. The GP was rude, but has a point.

I spent several years in the OO-agile ecosystem. I'm glad to be out of it. In retrospect, it feels shallow to me; I'm not sure exactly why. Maybe it has something to do with emphasizing half-baked methodological ideas over concrete system-building.

One of the guys who signed the agile manifesto told me that he decided it had taken the "human" side of software development too far. He was joking, but I think he was on to something.

The word object wasn't even mentioned in this piece.

While his point is actually a good one, as I was beginning to read the article, the cynical little voice said "huh - arguing about kinds of technical debt - I guess he has too much time on his hands". But it's not like I don't blow plenty of my own time on less worthwhile pursuits, so to each his own.

You found articles on 30+ year old dead-obvious technology solutions to long-solved problems to be more interesting?

To respond in-kind -- maybe this indicates that you just haven't reached the level of expertise necessary to appreciate the nuances of the topic addressed here (regardless of whether you agree or disagree with his opinion) -- and moreover, perhaps you lack the perspective necessary to differentiate between architectural astronauts and people presenting real issues.

Reply on news.ycombinator.com