4 ms·

>And if I am under pressure by the management is because I spent time developing without understanding what I was doing; a better developer would have gotten it

>And if I am under pressure by the management is because I spent time developing without understanding what I was doing; a better developer would have gotten it right at the first try, and there would be no technical debt. This is possibly the most wrongheaded comment you've made. 1) There is no such thing as "no technical debt". It asymptotically trends to zero but never, ever gets there. If you think that you oe anybody else is the kind of developer who magically creates debt-free code all the time then you're deluded. 2) The "right first try" argument is wrong. You shouldn't even try to get it right first try - that's the whole point of red/green/refactor. You're supposed to get it working and then clean it up because prematurely 'cleaning up code' is an inefficient way to work. It's not called red/green/refactor-if-you're-too-shit-to-get-it-right-first-try.

Udik 10y ago
Ok for your first point - although I'd argue that technical debt is something that usually asks to be repayed within months. A two year old technical debt is just an improvable software - that is, it didn't yet show problems serious enough as to call for a refactor at unchanged requirements. As for your second point, what should I do? Try to get it wrong? To get it working how? We're not talking of premature optimization here, we're talking about understanding the requirements, understanding the tools, understanding the big picture, understanding your time constraints, and pulling out the best job you can.
- andrewingram 10y ago
  Simplest kind of technical debt: 1. I use a particular technique/abstraction/whatever to solve the problem, it solves the problem well. 2. Over time we solve other problems elsewhere. As we go, the bigger picture becomes clearer and we pick more suitable techniques/abstractions/whatevers as we go. 3. Eventually we have to solve a problem that interacts with the original problem, the newer techniques/abstractions/whatevers don't work cleanly with the new ones. So we have to make a choice: a) Hack something together that solves the current problem without us having to touch much of the older code. b) Rewrite the old code to match the newer technique/abstractions/whatevers. c) Put down tools and thoroughly evaluate whether there's an even better technique/abstraction/whatever that solves the old problems and the new ones. We all know that C would give us the best code, but it's also likely to mean we never get anything done because every new problem means reevaluating everything. B happens more often, but in reality we usually end up doing A due to various pressures. At no point has bad code been written, but there's technical debt nonetheless. Over time we become better at adopting patterns an architectures that allow for clearly defined boundaries and reduced cost of making mistakes, you still get technical debt (because just about anything you want to change can be considered technical debt), but it doesn't tend to cripple your ability to get things done.
- crdoconnor 10y ago
  >Ok for your first point - although I'd argue that technical debt is something that usually asks to be repayed within months. A two year old technical debt is just an improvable software - that is, it didn't yet show problems serious enough as to call for a refactor at unchanged requirements. I've worked on five year old technical debt. It meant that bugs were far more common and fixes/new features took 10-15x as much effort as they would have otherwise. It wasn't that it didn't 'call' for a refactor - it's that the team didn't respond to the problems by refactoring. They tried the following instead: heavy manual regression testing before release (once in two years), waterfalling, longer and longer feature/code freezes, keeping multiple branches around for different customers. Managerial response was to hire additional mediocre developers, making the problem worse, but it wasn't like hiring better developers made developing immediately quicker and less risky. Paying that debt down to a reasonable level was impossible with mediocre developers would take ~36 months with good developers (also working on bugs/features). >As for your second point, what should I do? Try to get it wrong? To get it working how? You should do red->green->refactor. After writing a failing test, your only priority should be to make the test pass. Not elegant. Just passing. Once it's passing, then make it elegant. The reasons for this are twofold: 1) You're solving fewer problems at the same time. Something you want to avoid as much as possible as a developer is to have to juggle 40 different competing problems at the same time. 2) Refactoring-driven architectural decisions are ~95% of the time better decisions than those made during up-front design. >We're not talking of premature optimization here It's a closely related problem but it's not identical.

Udik 10y ago

Ok for your first point - although I'd argue that technical debt is something that usually asks to be repayed within months. A two year old technical debt is just an improvable software - that is, it didn't yet show problems serious enough as to call for a refactor at unchanged requirements. As for your second point, what should I do? Try to get it wrong? To get it working how? We're not talking of premature optimization here, we're talking about understanding the requirements, understanding the tools, understanding the big picture, understanding your time constraints, and pulling out the best job you can.

andrewingram 10y ago
Simplest kind of technical debt: 1. I use a particular technique/abstraction/whatever to solve the problem, it solves the problem well. 2. Over time we solve other problems elsewhere. As we go, the bigger picture becomes clearer and we pick more suitable techniques/abstractions/whatevers as we go. 3. Eventually we have to solve a problem that interacts with the original problem, the newer techniques/abstractions/whatevers don't work cleanly with the new ones. So we have to make a choice: a) Hack something together that solves the current problem without us having to touch much of the older code. b) Rewrite the old code to match the newer technique/abstractions/whatevers. c) Put down tools and thoroughly evaluate whether there's an even better technique/abstraction/whatever that solves the old problems and the new ones. We all know that C would give us the best code, but it's also likely to mean we never get anything done because every new problem means reevaluating everything. B happens more often, but in reality we usually end up doing A due to various pressures. At no point has bad code been written, but there's technical debt nonetheless. Over time we become better at adopting patterns an architectures that allow for clearly defined boundaries and reduced cost of making mistakes, you still get technical debt (because just about anything you want to change can be considered technical debt), but it doesn't tend to cripple your ability to get things done.
crdoconnor 10y ago
>Ok for your first point - although I'd argue that technical debt is something that usually asks to be repayed within months. A two year old technical debt is just an improvable software - that is, it didn't yet show problems serious enough as to call for a refactor at unchanged requirements. I've worked on five year old technical debt. It meant that bugs were far more common and fixes/new features took 10-15x as much effort as they would have otherwise. It wasn't that it didn't 'call' for a refactor - it's that the team didn't respond to the problems by refactoring. They tried the following instead: heavy manual regression testing before release (once in two years), waterfalling, longer and longer feature/code freezes, keeping multiple branches around for different customers. Managerial response was to hire additional mediocre developers, making the problem worse, but it wasn't like hiring better developers made developing immediately quicker and less risky. Paying that debt down to a reasonable level was impossible with mediocre developers would take ~36 months with good developers (also working on bugs/features). >As for your second point, what should I do? Try to get it wrong? To get it working how? You should do red->green->refactor. After writing a failing test, your only priority should be to make the test pass. Not elegant. Just passing. Once it's passing, then make it elegant. The reasons for this are twofold: 1) You're solving fewer problems at the same time. Something you want to avoid as much as possible as a developer is to have to juggle 40 different competing problems at the same time. 2) Refactoring-driven architectural decisions are ~95% of the time better decisions than those made during up-front design. >We're not talking of premature optimization here It's a closely related problem but it's not identical.