4 ms·

Interesting... but I note from the article: "In short, the business has decided that it can afford to delay release 2 in order to accelerate release 1. Is this

Interesting... but I note from the article: "In short, the business has decided that it can afford to delay release 2 in order to accelerate release 1. Is this wise?" This isn't actually what happens. Yes, release 1 gets pushed out the door asap, but then 'the business' expects release 2 to be done exactly as fast as release 1 was. So 'the business' never consciously makes that choice. All they hear is "do you want release 1 now or later?" and of course, they pick now (who wouldn't?). Even if you try to explain to them about the concept of technical debt and how this will delay release 2, all they will hear is "blah blah blah option (a) release 1 faster, option (b) release 1 slower". There is an element of delayed gratification to not accumulating technical debt, and large organizations tend to have amazingly short term view points. ---- But personally, I don't believe incurring technical debt makes you faster in the short term. I don't see technical debt as 'getting a loan' e.g. it gives you more resources now but you have to pay it back later on... I see technical debt as pouring a bucket of tar over yourself. Technical debt, and bad designs start slowing you down immediately. Moreover, it is almost never the programmers who decide to incur technical debt, my experience is that it is some team of architects or managers who decide to incur the debt (e.g. by picking Vendor X's product that is a pain in the butt to integrate with your existing systems), and they are never the people who have to pay the debt back. It is the programmers who have to pay the debt back, usually by way of unpaid overtime ... as the same managers who incurred the debt in the first place stand over them screaming about missed deadlines. An example of technical debt handed down by the architects might be a particular toolset that doesn't quite work together, or some bondage and discipline around the methodology, or some arbitrary restriction to increase the difficulty (e.g. slapping everything with patterns whether they need them or not, or desgnating a particular database for persistence, but then telling the develoeprs they're not allowed to use SQL (yes, it's a silly and arbitrary example)). Another example is that architects love complex abstractions, so if you give them half a chance they'll spend their time adding layers of indirection to your design. This makes it much harder for the developers. Hence my bucket of tar analogy. It's bad enough when you pour it over yourself, but if you're already in a tar pit and the people on the sidelines are throwing it onto you... it's infuriating.

demallien 16y ago
Good points, though I disagree with this: "Moreover, it is almost never the programmers who decide to incur technical debt" In my experience this is sadly not true. There are an awful lot of programmers out there that don't even understand that technical debt exists. I see it a lot amongst inexperienced programmers. The worst thing about technical debt type issues is that it is very difficult to explain to someone why there is a problem. You have a young programmer, fresh out of uni, and you ask them to build a small subsystem, which they do with much enthusiasm. Then in the code review you see a bunch of practices that are going to make life difficult down the track: naming conventions haven't been followed, huge 500 line functions, tests are brittle if they exist at all, the code is full of handlers for special cases, instead of finding a single algorithm that elegantly handles all nominal cases, things like that. The trouble is, the code works, kind of, so it is hard to explain to someone why code in that state is not acceptable. Furthermore, I can happily accept code that doesn't meet one of those criteria that I listed above, but when you start to have multiple infringements, code just becomes unmaintainable. It's not a clear cut case of something that you can point to and say "that's wrong", but more of a overall cumulative effect. I eventually had to let one guy go because I just could not get him to understand that this stuff was important when you're building a big system.
- Stormbringer 16y ago
  Sorry, I meant "if there are sufficiently stroppy senior developers who can knock some sense into the other developers, it is almost never the programmers who decide to incur technical debt". But, sadly, even that isn't true. It really comes down to the complexifers vs the simplifiers. The complexifers generate technical debt simply by existing. They can't not generate technical debt, because they love complexity and create it to the full extent that they are capable. Thus getting rapidly out of their depth† and hence the tar pit analogy. NB: architects are usually, but not always complexifers. †since there is that old saw about debugging being twice as hard as writing the code, therefore if you write code to your limits you by definition aren't smart enough to debug it.

demallien 16y ago

Good points, though I disagree with this: "Moreover, it is almost never the programmers who decide to incur technical debt" In my experience this is sadly not true. There are an awful lot of programmers out there that don't even understand that technical debt exists. I see it a lot amongst inexperienced programmers. The worst thing about technical debt type issues is that it is very difficult to explain to someone why there is a problem. You have a young programmer, fresh out of uni, and you ask them to build a small subsystem, which they do with much enthusiasm. Then in the code review you see a bunch of practices that are going to make life difficult down the track: naming conventions haven't been followed, huge 500 line functions, tests are brittle if they exist at all, the code is full of handlers for special cases, instead of finding a single algorithm that elegantly handles all nominal cases, things like that. The trouble is, the code works, kind of, so it is hard to explain to someone why code in that state is not acceptable. Furthermore, I can happily accept code that doesn't meet one of those criteria that I listed above, but when you start to have multiple infringements, code just becomes unmaintainable. It's not a clear cut case of something that you can point to and say "that's wrong", but more of a overall cumulative effect. I eventually had to let one guy go because I just could not get him to understand that this stuff was important when you're building a big system.

Stormbringer 16y ago
Sorry, I meant "if there are sufficiently stroppy senior developers who can knock some sense into the other developers, it is almost never the programmers who decide to incur technical debt". But, sadly, even that isn't true. It really comes down to the complexifers vs the simplifiers. The complexifers generate technical debt simply by existing. They can't not generate technical debt, because they love complexity and create it to the full extent that they are capable. Thus getting rapidly out of their depth† and hence the tar pit analogy. NB: architects are usually, but not always complexifers. †since there is that old saw about debugging being twice as hard as writing the code, therefore if you write code to your limits you by definition aren't smart enough to debug it.