Tech debt is a management problem, not a coding problem. A statement like this undermines my confidence in the story being told, because it indicates the lack of experience of the author.
I don't think that's totally accurate though. It can definitely be a coding problem - corners cut for expediency and such. Sometimes that's because management doesn't offer enough time to not do it that way, but it can also just be because the dev doesn't bother or does the bare minimum.
I'd argue the creation of tech debt is often coding problem. The longevity and persistence of tech debt is a management problem.
> it can also just be because the dev doesn't bother or does the bare minimum
sounds like a people problem — which is management problem.
> I'd argue the creation of tech debt is often coding problem. The longevity and persistence of tech debt is a management problem.
i’d argue the creation of tech debt is more often due to those doing the coding operating under the limitations placed on them. The longevity and persistence of tech debt is just an extension of that.
given an infinite amount of time and money, i can write an ideal solution to a solvable problem (or at least close to ideal, i’m not that good of a dev).
the limitations create tech debt, and they’re always there because infinite resources (time and money) don’t exist.
so tech debt always exists because there’s always limitations. most of the time those resource limitations are decided by management (time/money/people)
but there are language/framework/library limitations which create tech debt too though, which i think is what you might be referring to?
I'm mostly saying that not every dev is always just trying to do the perfect solution. I have plenty of times I've cut a corner just to get something done because I was tired of working on it, or just knew there was a better way but couldn't come up with it without taking way more time. Not every project demands a solution with no technical debt, or will even suffer from having some technical debt. Hell, I've had times I've had to explain to management why I wasn't doing something in the more elegant way because it simply wasn't going to be worth the extra time to do it that way given the scope of the project.
It's an easy out to just blame bad management for all the ills of a bad code base, and there's definitely plenty of times I've wanted to take longer to fix/prevent some tech debt and haven't been given the time, but it's self-serving to blame it all on outside forces.
It's also ignoring the times where management is making a justifiable decision to allow technical debt in order to meet some other goal, and the decision that a senior engineer often has to make is which technical debt to incur in order to work within the constraints.
Not taking enough time is a management problem. It doesn't matter whether It is the manager or the developer who takes shortcuts. The problem is planning, not coding.
Tech debt is a management problem, not a coding problem. A statement like this undermines my confidence in the story being told, because it indicates the lack of experience of the author.