3 ms·

The problem with the technical debt concept is that it implies there's this debt-free way of doing things. Like there's some sort of platonic form of "good" cod

The problem with the technical debt concept is that it implies there's this debt-free way of doing things. Like there's some sort of platonic form of "good" code that everything must aspire to, and good teams write code that doesn't have debt. What I've actually seen in practice is that "technical debt" mostly means "things I wouldn't have written that way." It has very little to do with the code and more to do with the philosophical leanings of the commenter.

morgante 12y ago
I disagree. I have willfully acquired technical debt on many occasions by writing code in a hacky way which, given more time, I wouldn't have chosen. Technical debt is a great metaphor for explaining this to non-tech stakeholders. They understand that choosing to rush a feature out now will lead to slower development (paying back the debt) later.
- briandear 12y ago
  But to be fair, there's also the potential benefit of not having to pay that debt back. If the feature fails from a market perspective, you've actually saved money by incurring the debt. That's the whole concept behind the Lean Startup.
ulisesrmzroche 12y ago
In startups, technical debt by your definition has more to do with not having enough time/resources to spend on the problem. Code philosophy is the first thing that goes out the door.
hw 12y ago
Yes, there is such a thing as 'good code' that people should aspire to, or at least good practices when it comes to writing code. There are good teams that write code that has no or very little debt. It's also not just bad code that leads to technical debt, but bad decisions when it comes to code-related things like architecture, tech stack, which version of libraries / languages to use, etc.
crdoconnor 12y ago
>Like there's some sort of platonic form of "good" code that everything must aspire to There is: 1) Code that is covered by tests 2) DRY code 3) Loosely coupled code 4) Code that fails fast 5) Code that doesn't reinvent the wheel Most technical debt I've seen violates one of the above principles. It is crystal fucking clear when you are paying it off and the benefits to paying it off are pretty obvious to those working on the code base. It is impossible to avoid violating them completely, but low technical debt means small and rare violations, whereas high technical debt means large and extremely common violations. >What I've actually seen in practice is that "technical debt" mostly means "things I wouldn't have written that way." It has very little to do with the code and more to do with the philosophical leanings of the commenter. In practice I find that most people know terrible code when they see it, but if given the chance to rewrite from scratch most will end up digging themselves into the same hole. Bad coders will not realize that they are doing it. Good coders can also end up doing it simply for expediency. I find that the best way of paying off the technical debt is simply to work my way through fixing things 1-5, roughly in that order. It is a slow and largely thankless process.

morgante 12y ago

I disagree. I have willfully acquired technical debt on many occasions by writing code in a hacky way which, given more time, I wouldn't have chosen. Technical debt is a great metaphor for explaining this to non-tech stakeholders. They understand that choosing to rush a feature out now will lead to slower development (paying back the debt) later.

briandear 12y ago
But to be fair, there's also the potential benefit of not having to pay that debt back. If the feature fails from a market perspective, you've actually saved money by incurring the debt. That's the whole concept behind the Lean Startup.

ulisesrmzroche 12y ago

In startups, technical debt by your definition has more to do with not having enough time/resources to spend on the problem. Code philosophy is the first thing that goes out the door.

hw 12y ago

Yes, there is such a thing as 'good code' that people should aspire to, or at least good practices when it comes to writing code. There are good teams that write code that has no or very little debt. It's also not just bad code that leads to technical debt, but bad decisions when it comes to code-related things like architecture, tech stack, which version of libraries / languages to use, etc.

crdoconnor 12y ago

>Like there's some sort of platonic form of "good" code that everything must aspire to There is: 1) Code that is covered by tests 2) DRY code 3) Loosely coupled code 4) Code that fails fast 5) Code that doesn't reinvent the wheel Most technical debt I've seen violates one of the above principles. It is crystal fucking clear when you are paying it off and the benefits to paying it off are pretty obvious to those working on the code base. It is impossible to avoid violating them completely, but low technical debt means small and rare violations, whereas high technical debt means large and extremely common violations. >What I've actually seen in practice is that "technical debt" mostly means "things I wouldn't have written that way." It has very little to do with the code and more to do with the philosophical leanings of the commenter. In practice I find that most people know terrible code when they see it, but if given the chance to rewrite from scratch most will end up digging themselves into the same hole. Bad coders will not realize that they are doing it. Good coders can also end up doing it simply for expediency. I find that the best way of paying off the technical debt is simply to work my way through fixing things 1-5, roughly in that order. It is a slow and largely thankless process.