I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code.
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.
I have to disagree with this comment. Technical debt is sometimes the result of just one lone cowboy coder, but even then there's some responsibility across the team because that means his or her code passed all reviews, i.e., nobody took ownership for the overall team's code quality and vetoed the bad code.
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).
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.
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.
> 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.
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.
I guess that what I'm trying to say - and that got clearer to me while replying to other comments in this thread- is that it feels we're using the term "technical debt" as a way to avoid talking about personal skills or lack thereof, and to avoid admitting our or other people's faults. If I say that we need one more week of work on something because of technical debt due to the exceptional circumstances is one thing; if I say that it is because one of my colleagues didn't do his or her job properly, it's different. Remember that the business might have no clue of how long or difficult some tasks are and judge them only by the amount of work required. So a series of bad design decisions and consequent technical debt can give the impression of a very hard task on which everybody is working skillfully, while in fact it's an easy task with somebody that doesn't know how to do his job.
As for your other points: maybe one of my team members produces consistently more technical debt than the others. Is it still technical debt?
Manager or designers can be the source of time pressure for those down in the chain, because bad planning or decisions, made in absence of time pressure, can force others to work under pressure. Again, "technical debt" masks the real problem.
I might not have worked in extremely high pressure environments - but I've surely worked in teams where we were leaving the office at ten or eleven pm every night for months on end just because demented design decisions had been made by the much respected solution architect.
>>I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code
>Creating lots of extra technical debt, in fact, is a defining feature of poorer developers.
I think we agree then. It's just that "technical debt" makes it sound- to me at least- inevitable and impersonal, while it is possible (at least for substantial amounts of it) to ascribe it to specific people and to avoid it by hiring better people.
>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.
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.
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.
>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.
What value comes of characterising it as "inadequacy"? I mean you may enjoy the self-flagellation but does it actually help plan or work effectively?
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.
>I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code.
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.
Of course. Some developers (or product owners, architects, managers) generate technical debt slower, some other generate it faster. Some generate a substantial amount of it for a task in which others would generate very little - in the same time frame. Then why don't we call it lack of skills? Sounds the same to me.
Because the same developer with the same skills can often ramp up technical debt to get a feature out in half an hour instead of a day, and there aren't any developers who haven't felt the pressure to do exactly that.
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.
True. The amount of technical debt produced is a function of the time constraints and the person skills. In turn, the time constraints can depend on the skills of other people in the organization at planning, designing, figuring out requirements, managing the team and the process, etc. Saying "ah sorry, we'll have to work one more week/ month on this because, you know, technical debt" is sweeping all these possible issues under one big carpet.
I don't see why. Technical debt is just a measure of how much crap there is in the code. It doesn't preclude having a discussion about how much that is to do with skills and how much that is to do with pressure/time constraints/existing technical debt.
The point of the dial is just to make the trade off between quality and speed that individual developers are making every day both explicit and management's responsibility.
It means if the dial is turned up to 100% management have no excuse for asking the question "why is our product a pile of crap?". It means also if the dial was at 60% for a year and a half the developers have no excuse for why the product is still riddled in technical debt, meaning that skills problems are distinguished from time constraints and managerial pressure comes with a cost attached.
I disagree. Even among those who routinely write good code (all of us in our own minds) the schedule tends to pressure you to solve the problem before you, the one in the story, without checking if anyone else has solved similar problems already. What tends to happen is you write your own solution instead of finding the similar solution and generalizing it. Then, after a year you have have a dozen related tasks performed in slightly different ways. If the underlying (e.g.) data structure change, now you need to alter each of the dozen different ways
This sounds like a bad organization of the team, bad process or bad design. Clearly team members don't communicate enough, or groups of similar features have not been foreseen during the design phase, and the same code has been rewritten again and again by different people. This is not contingent "technical debt", this is a serious problem that needs to be addressed with changes in the process.
organization of the team and process? You mean the scrum process? Indeed, my point. Of course one can argue that no true scrum process would have such problems...
Yes, totally agree with you. But then, why "technical debt"? No, there is something wrong here and this process needs to be changed. Somebody made the wrong decisions, at some level, and there is a very specific issue to be found, analyzed and solved.
And yes of course, as we all know scrum is by definition successful, and all the teams that fail are not following the true faith.
I see technical debt as being that code you haven't written yet. You just ignore the errors from misaligned data instead of writing the date sanitizer. You monitor and hand-reboot processes that leak instead of finding the leak/automating the reboot. and so on.
I think the "speed" part is that once you realize it is bad code cause you didn't know how to do it better, you don't have the time to scrap it and start over.
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.