3 ms·

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

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.

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.