Martin Fowler describes four kinds of "technical debt"
martinfowler.com
Martin Fowler describes four kinds of "technical debt"
1–10 of 18 posts
Re: Martin Fowler describes four kinds of "technical debt"
#2"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.
Re: Martin Fowler describes four kinds of "technical debt"
#3Typical 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?
Re: Martin Fowler describes four kinds of "technical debt"
#4Typical 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 a…
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.
Re: Martin Fowler describes four kinds of "technical debt"
#5Am 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()...
Re: Martin Fowler describes four kinds of "technical debt"
#6Am 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?
Re: Martin Fowler describes four kinds of "technical debt"
#7"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.
Re: Martin Fowler describes four kinds of "technical debt"
#8[deleted]
Re: Martin Fowler describes four kinds of "technical debt"
#9With 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.
Re: Martin Fowler describes four kinds of "technical debt"
#10With 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.