I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning. But to get a feature out quicker, no. If anything, it seems to me that writing bad code requires more time than writing clean and elegant code.
In the end, "technical debt" becomes a way to shift the blame from your own (the team's) inadequacy at planning, designing and developing, towards supposed time constraints that always lie outside of the team's responsibility.
Time constraints can certainly be relevant too. It's not always an artificial shift of blame. For instance, time constraints could be why the code passed review to begin with.
And some programmers certainly do write worse code when they have to do it quickly. Typically, the code itself doesn't look all that bad in a vacuum, but it presents problems months down the line when a new feature needs to be added or an existing one changed in a non-trivial way. There was little forethought in its design.
Or, let's just look at the ways you said you might write bad code:
> I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning
In other words, these things can cause you to write bad code:
1. You just didn't know better.
2. Unclear requirements at the start.
3. Bad design and planning.
In (1), you might realize after writing some code that you didn't quite know what you were doing and you should refactor it, but you're now under pressure from management to just get it out. Oops, no time to refactor. Now code that you know is bad is going into production, and it'll bite you in six months.
For (2), the reason the requirements weren't clear is because not enough time was spent by management/product owners/designers on clarifying said requirements.
For (3), it's the same thing -- bad planning is often the result of time constraints (notably, time constraints which may not be visible to you as a rank and file programmer).
I think I have yet to see any software to which this doesn't apply sooner or later. While the whole point of "technical debt" is that it is something you're supposed to knowingly acquire because of time constraints. You're basically saying "we knew it was wrong, but they forced us to do it that way". While to me, most of the times, the truth is that you really didn't know. Yes, you coded in a hurry, but there is always a time constraint of some kind so that's no excuse. Somebody else in the same time would have done a better job.
As for my points: if I realize I didn't know what I was doing, I always refactor the code. Committing code that you know to be conceptually wrong is just sloppy. 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.
If the managers/ product owners didn't produce clear requirements, it's not a technical debt, it's a sloppy job on their part.
If the planning was wrong, that's a sloppy job on the part of who had to do it. Responsibilities should be found and action should be taken. Saying "ah yes you know, we were under pressure so we (kind of naturally) accumulated this technical debt" is just a way to save everybody's face.
While this reasoning is probably not technically wrong, I'm not sure if it's relevant to the real world.
You can always make an argument of form "there exists a developer who could have got this feature right on the first try, with very little time spent." This simply does not matter when you do not happen to have that developer on your team right at the moment. The nature of the work is that you will work on a variety of things, and you won't necessarily be the best in the world at every individual thing. You're inevitably going to encounter work that's challenging enough for you where you don't get it perfectly right on your first try.
> If the managers/ product owners didn't produce clear requirements, it's not a technical debt, it's a sloppy job on their part.
It's a sloppy job on their part, induced by time pressure, which produces technical debt. I feel like you're just playing with definitions here to avoid admitting that technical debt can come from poorly managed time pressure.
> if I realize I didn't know what I was doing, I always refactor the code.
All that tells me is that you've never been under a lot of time pressure. That's not a bad thing. It most likely means the management at your companies have been competent. But it doesn't mean that technical debt does not exist or cannot be induced from time pressure in other companies.
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.
It's absolutely not that. Technical debt is a natural by-product of working even with the best coders. There's nobody out there who doesn't create it.
Better coders just produce it more slowly and clean it up more often.
>I'm not sure I ever found myself in the position of writing bad code just for the sake of speed
I could literally spend all of my time making code nicer and none at all developing features/fixing bugs. It's always a trade off between speed and quality.
Ramping up technical debt isn't always about speed, either. It's sometimes about risk - it's often less risky in the short term to copy and paste a block of code than it is to change a block of code and risk breaking something else.
To my mind the "debt" metaphor captures important intuitions: it accumulates interest, slowly at first but rapidly if you have too much of it, it can look like it isn't a problem until it is, taking on more is often an easy way out of your current situation in the short term.
