"If we can save 32 labor-hours over the next 3 years, but it’ll only cost 8 labor-hours to do it, then maybe let’s do it. If it’ll cost 40 labor-hours, then you should just keep on wasting that...
"If we can save 32 labor-hours over the next 3 years, but it’ll only cost 8 labor-hours to do it, then maybe let’s do it. If it’ll cost 40 labor-hours, then you should just keep on wasting that effort."
These numbers are literally impossible to calculate, especially so in a startup.
It’s the principle though. I know I have at times been guilty of spending days to save hours or weeks to save days on some technical detail that bothers me but maybe wasn’t strictly worth doing....
It’s the principle though. I know I have at times been guilty of spending days to save hours or weeks to save days on some technical detail that bothers me but maybe wasn’t strictly worth doing.
OTOH, sometimes that kind of work unlocks hidden benefits with big payoffs.
That is true and every project will have some technical debt and that is okay. But if it gets too much out of hand, it also becomes increasingly difficult to estimate what the cost is or how much...
That is true and every project will have some technical debt and that is okay. But if it gets too much out of hand, it also becomes increasingly difficult to estimate what the cost is or how much extra development time is needed. Suddenly you end up wanting to implement a seemingly simple thing that hits a plethora of edge cases and side effects because the technical debt has been neglected for years.
We should also feel free to openly admit that if something is making the developers unhappy, fixing it and making them enjoy their job a little bit more is valuable on its own. If code is a pain...
We should also feel free to openly admit that if something is making the developers unhappy, fixing it and making them enjoy their job a little bit more is valuable on its own. If code is a pain in the ass to work with, even if the amount of time working with it isn't enough to justify a day or two to clean it up, the stress involved can make people behave irrationally. They'll procrastinate on things that need to get done soon. They might make sub-optimal changes to the repo just to lower the time spent on it, making things worse.
Having tech that people enjoy working with should be considered foundational.
Agree, and it’s not something that’s unique to tech. Employee morale is important, both for its own sake and because it affects performance. A huge number of managers behave as if they are...
Agree, and it’s not something that’s unique to tech. Employee morale is important, both for its own sake and because it affects performance. A huge number of managers behave as if they are entirely unaware of this basic fact of life.
Once I did a stupid "optimization" of ii%4==0 and lost a week trying to find out what was wrong (the ==0 wasn't there). I'm pretty sure the compiler would've optimized it anyway, so there was zero...
Once I did a stupid "optimization" of ii%4==0 and lost a week trying to find out what was wrong (the ==0 wasn't there). I'm pretty sure the compiler would've optimized it anyway, so there was zero benefit. Premature optimization etc etc.
You can also run into the situation where the time it takes to calculate a reasonable estimate and put together a presentation to convince people to work the technical debt takes more effort than...
You can also run into the situation where the time it takes to calculate a reasonable estimate and put together a presentation to convince people to work the technical debt takes more effort than it would to fix the technical debt.
It’s funny isn’t it? The place I work is basically all legacy code. Decades of debt that has to be paid down to make progress on a feature. Sometimes it makes re-architecting the program nigh but...
It’s funny isn’t it? The place I work is basically all legacy code. Decades of debt that has to be paid down to make progress on a feature. Sometimes it makes re-architecting the program nigh but impossible. And we have developers who have been working, learning for 5-6 years and are extremely conscientious. They’re more than willing to pay down that debt to fix bugs, implement improvements, or build a feature.
Yet - it all comes back to management. Poor management means we’re losing the folks we’ve been training for years. And over what? Small title changes? Small pay adjustments? This seemed obvious when I started, but management just doesn’t see it. I’m not sure how many people need to leave before they do.
Cheers to you hitting the exit door and moving on to greener pastures.
Mate you need to honestly just leave, you will feel so much better. It's obvious to me from your comments that you know deep down the situation is not going to improve any time soon, and the...
Mate you need to honestly just leave, you will feel so much better. It's obvious to me from your comments that you know deep down the situation is not going to improve any time soon, and the amount of stress is palpable through your words.
This feels like it is written by a manager or someone trying to appease to the manager crowd. There is barely any substance. Also, it takes a similar "scatter brain" take to the other end of the...
This feels like it is written by a manager or someone trying to appease to the manager crowd. There is barely any substance.
Also, it takes a similar "scatter brain" take to the other end of the spectrum. Unless the author doesn't do regular maintenance on their house, car, etc. Because if they don't then the argument makes perfect sense. Because tech dept is not only the result of taking shortcuts during initial development, tech debt also gets added in the lifespan of a software product.
Software isn't static, even if you don't add any features the platform it runs on will change over time. Security vulnerabilities will be found in dependencies and will need to be fixed, etc. If you don't do those things, you will simply accrue tech debt over time.
It is perfectly reasonable to budget a block of time for what is effectively maintenance but also tech dept prevention and reduction.
There is a lot more to explore here and to discuss in detail. But at this point my comment is already at a similar length as the blog post, which says more about the blog post than my comment as far as length goes.
I'm sorry, what? Engineers cost money. If tech debt causes them to take 2x the time to build a value-producing feature, then you are losing money because of it. Overall, I agree with the author...
Reducing wasted effort may feel like an obvious good, but reducing wasted effort isn’t the goal of a company. Making money is.
I'm sorry, what? Engineers cost money. If tech debt causes them to take 2x the time to build a value-producing feature, then you are losing money because of it.
Overall, I agree with the author though. Imho, the mark of a great engineer is being able to work with an imperfect code base without feeling that they need to change everything. (And the same can actually be said for business roles as well.)
My big problem with the whole thing is that financial debt has clearly marked terms and rates. Technical debt does not, and programmers are generally not good at giving realistic time estimates. If you take the predictability away it's harder to make concrete decisions. In general, as a guiding principle, I think it is still helpful.
I also recall a keynote (I'll try to find it and add a link here. I don't remember the conference... I think it was by Kevlin Henney) where the speaker talks about the idea of a healthy amount of technical debt. You can have too much, but you can also have too little.
This feels like a moot point to me. Most experienced developers will know the old "if it ain't broke, don't fix it", so they'll avoid refactoring things just for the sake of refactoring (since...
This feels like a moot point to me.
Most experienced developers will know the old "if it ain't broke, don't fix it", so they'll avoid refactoring things just for the sake of refactoring (since most intensive refactors will introduce a bug, 99% of the time)
However if a new feature ends up needing some adjustments in that part of the code, that's when you refactor and clean up code, and thoroughly test that part alongside the new feature. Of course, this will depend on your company/department's goals and isn't a one-size-fits-all thing.
I hate ugly, unmaintainable code as much as anyone else, so I'm guilty of rewriting code for no reason except "it's pretty now", but I try my best to balance the business' needs with my own needs.
This is definitely the way. Small iterative improvements can do a lot. Making changes in related parts of the code also improves the odds you'll catch any bugs during testing or at least have an...
This is definitely the way. Small iterative improvements can do a lot. Making changes in related parts of the code also improves the odds you'll catch any bugs during testing or at least have an idea of where to start if you find bugs later.
Sometimes though, it's really really satisfying to run a linter or IDE refactor over a codebase and fix all the easy stuff like unused imports and variables, syntax, etc. Also feels nice to fix the access level of variables for readability reasons (private and final should be used more often).
At my job we use Python a lot, and VS Code has such good integration with linters like pylint and flake8, issues are reported as I'm writing code. Somehow my coworkers' code is full of these small...
At my job we use Python a lot, and VS Code has such good integration with linters like pylint and flake8, issues are reported as I'm writing code.
Somehow my coworkers' code is full of these small issues and it upsets me a little. The code works and is generally fine, but you could have run a format with Black so flake8 shuts up, ya know?
I do resist the urge to just fix all the lints, because it makes the pull request a pain to review, and code review sucks enough already.
A lot of devops platforms have the ability to integrate a linter as an automatic step as part of the PR or review process. It can be subtle, but it's really nice to read through a code-base which...
A lot of devops platforms have the ability to integrate a linter as an automatic step as part of the PR or review process. It can be subtle, but it's really nice to read through a code-base which is universally consistent on styling. Having it as a part of the PR process works well too since devs can keep whatever setup they prefer when working with the code locally.
What makes this blogpost worth reading? It’s not by some noteworthy person (what do I care what Dan Simmons thinks?) and isn’t shedding any noteworthy insights on technical debt. It’s a very bland...
What makes this blogpost worth reading? It’s not by some noteworthy person (what do I care what Dan Simmons thinks?) and isn’t shedding any noteworthy insights on technical debt. It’s a very bland manager take on a complex topic.
“If you have a proposed improvement that’ll reduce wasted effort, then make a case for the soundness of that proposal as an investment.”
Yeah, good luck with that. If you want to save money, stop requiring me to hand-hold you in running a software company.
Not all bad code is technical debt for sure. Like if it's full of code that looks like "def is_true: x == x" then yes your eyes might bleed. But it's not technical debt to the business if it has...
Not all bad code is technical debt for sure. Like if it's full of code that looks like "def is_true: x == x" then yes your eyes might bleed. But it's not technical debt to the business if it has sufficient tests or is not important to day-to-day operations such that bad code or style could do you in.
I would say code is technical debt when:
People are afraid to make changes to the code base (because you don't know how it all "fits")
It represents meaningful risk to the stability / quality of the product from a user perspective (e.g. buggy) or desired growth perspective (e.g. architecture leads to expensive scaling)
Because of that past decision, we must now make recurring interest payments in the form of wasted effort.
I'm not sure what the author considers tech debt to be, just inefficiencies? IME, a lot of debt was way worse, more in the realm of unhandled cases that we hoped no one encountered or code no one could understand.
A realistic manager would say, “If you have a proposed improvement that’ll reduce wasted effort, then make a case for the soundness of that proposal as an investment.”
This effort in itself feels like a weird waste of time. Not against a requirements doc, but it's not the type of presentation most engineers would be used to, especially since I'd say many lack access to the data required to make such an argument. It's not bad to ask for high-level requirements, but if I had to make a very thorough document trying to explain things to non-technical people, there is definitely a point where it goes from "within the job description" to "they want me to give up and shut up." I worked at a place where engineers were discouraged from giving ideas on a technical product; one of the discouragements was, imo, being told we had to write these proposals in our spare time. We did not really have meaningful spare time at that startup.
"If we can save 32 labor-hours over the next 3 years, but it’ll only cost 8 labor-hours to do it, then maybe let’s do it. If it’ll cost 40 labor-hours, then you should just keep on wasting that effort."
These numbers are literally impossible to calculate, especially so in a startup.
It’s the principle though. I know I have at times been guilty of spending days to save hours or weeks to save days on some technical detail that bothers me but maybe wasn’t strictly worth doing.
OTOH, sometimes that kind of work unlocks hidden benefits with big payoffs.
That is true and every project will have some technical debt and that is okay. But if it gets too much out of hand, it also becomes increasingly difficult to estimate what the cost is or how much extra development time is needed. Suddenly you end up wanting to implement a seemingly simple thing that hits a plethora of edge cases and side effects because the technical debt has been neglected for years.
One of those hidden benefits is improving the developers' refactoring and problem-solving skills.
We should also feel free to openly admit that if something is making the developers unhappy, fixing it and making them enjoy their job a little bit more is valuable on its own. If code is a pain in the ass to work with, even if the amount of time working with it isn't enough to justify a day or two to clean it up, the stress involved can make people behave irrationally. They'll procrastinate on things that need to get done soon. They might make sub-optimal changes to the repo just to lower the time spent on it, making things worse.
Having tech that people enjoy working with should be considered foundational.
Agree, and it’s not something that’s unique to tech. Employee morale is important, both for its own sake and because it affects performance. A huge number of managers behave as if they are entirely unaware of this basic fact of life.
Once I did a stupid "optimization" of
ii%4==0and lost a week trying to find out what was wrong (the==0wasn't there). I'm pretty sure the compiler would've optimized it anyway, so there was zero benefit. Premature optimization etc etc.You can also run into the situation where the time it takes to calculate a reasonable estimate and put together a presentation to convince people to work the technical debt takes more effort than it would to fix the technical debt.
It’s funny isn’t it? The place I work is basically all legacy code. Decades of debt that has to be paid down to make progress on a feature. Sometimes it makes re-architecting the program nigh but impossible. And we have developers who have been working, learning for 5-6 years and are extremely conscientious. They’re more than willing to pay down that debt to fix bugs, implement improvements, or build a feature.
Yet - it all comes back to management. Poor management means we’re losing the folks we’ve been training for years. And over what? Small title changes? Small pay adjustments? This seemed obvious when I started, but management just doesn’t see it. I’m not sure how many people need to leave before they do.
Cheers to you hitting the exit door and moving on to greener pastures.
Mate you need to honestly just leave, you will feel so much better. It's obvious to me from your comments that you know deep down the situation is not going to improve any time soon, and the amount of stress is palpable through your words.
This feels like it is written by a manager or someone trying to appease to the manager crowd. There is barely any substance.
Also, it takes a similar "scatter brain" take to the other end of the spectrum. Unless the author doesn't do regular maintenance on their house, car, etc. Because if they don't then the argument makes perfect sense. Because tech dept is not only the result of taking shortcuts during initial development, tech debt also gets added in the lifespan of a software product.
Software isn't static, even if you don't add any features the platform it runs on will change over time. Security vulnerabilities will be found in dependencies and will need to be fixed, etc. If you don't do those things, you will simply accrue tech debt over time.
It is perfectly reasonable to budget a block of time for what is effectively maintenance but also tech dept prevention and reduction.
There is a lot more to explore here and to discuss in detail. But at this point my comment is already at a similar length as the blog post, which says more about the blog post than my comment as far as length goes.
I'm sorry, what? Engineers cost money. If tech debt causes them to take 2x the time to build a value-producing feature, then you are losing money because of it.
Overall, I agree with the author though. Imho, the mark of a great engineer is being able to work with an imperfect code base without feeling that they need to change everything. (And the same can actually be said for business roles as well.)
I'm reminded of this post from last year which is on the same track, but takes the metaphor a bit further and examines things in more detail.
https://tildes.net/~comp/17t4/tech_debt_metaphor_maximalism
My big problem with the whole thing is that financial debt has clearly marked terms and rates. Technical debt does not, and programmers are generally not good at giving realistic time estimates. If you take the predictability away it's harder to make concrete decisions. In general, as a guiding principle, I think it is still helpful.
I also recall a keynote
(I'll try to find it and add a link here. I don't remember the conference... I think it was by Kevlin Henney)where the speaker talks about the idea of a healthy amount of technical debt. You can have too much, but you can also have too little.Edit: Technical Neglect - Kevlin Henney - NDC London 2024
This feels like a moot point to me.
Most experienced developers will know the old "if it ain't broke, don't fix it", so they'll avoid refactoring things just for the sake of refactoring (since most intensive refactors will introduce a bug, 99% of the time)
However if a new feature ends up needing some adjustments in that part of the code, that's when you refactor and clean up code, and thoroughly test that part alongside the new feature. Of course, this will depend on your company/department's goals and isn't a one-size-fits-all thing.
I hate ugly, unmaintainable code as much as anyone else, so I'm guilty of rewriting code for no reason except "it's pretty now", but I try my best to balance the business' needs with my own needs.
This is definitely the way. Small iterative improvements can do a lot. Making changes in related parts of the code also improves the odds you'll catch any bugs during testing or at least have an idea of where to start if you find bugs later.
Sometimes though, it's really really satisfying to run a linter or IDE refactor over a codebase and fix all the easy stuff like unused imports and variables, syntax, etc. Also feels nice to fix the access level of variables for readability reasons (private and final should be used more often).
At my job we use Python a lot, and VS Code has such good integration with linters like pylint and flake8, issues are reported as I'm writing code.
Somehow my coworkers' code is full of these small issues and it upsets me a little. The code works and is generally fine, but you could have run a format with Black so flake8 shuts up, ya know?
I do resist the urge to just fix all the lints, because it makes the pull request a pain to review, and code review sucks enough already.
A lot of devops platforms have the ability to integrate a linter as an automatic step as part of the PR or review process. It can be subtle, but it's really nice to read through a code-base which is universally consistent on styling. Having it as a part of the PR process works well too since devs can keep whatever setup they prefer when working with the code locally.
What makes this blogpost worth reading? It’s not by some noteworthy person (what do I care what Dan Simmons thinks?) and isn’t shedding any noteworthy insights on technical debt. It’s a very bland manager take on a complex topic.
Yeah, good luck with that. If you want to save money, stop requiring me to hand-hold you in running a software company.
Not all bad code is technical debt for sure. Like if it's full of code that looks like "def is_true: x == x" then yes your eyes might bleed. But it's not technical debt to the business if it has sufficient tests or is not important to day-to-day operations such that bad code or style could do you in.
I would say code is technical debt when:
I'm not sure what the author considers tech debt to be, just inefficiencies? IME, a lot of debt was way worse, more in the realm of unhandled cases that we hoped no one encountered or code no one could understand.
This effort in itself feels like a weird waste of time. Not against a requirements doc, but it's not the type of presentation most engineers would be used to, especially since I'd say many lack access to the data required to make such an argument. It's not bad to ask for high-level requirements, but if I had to make a very thorough document trying to explain things to non-technical people, there is definitely a point where it goes from "within the job description" to "they want me to give up and shut up." I worked at a place where engineers were discouraged from giving ideas on a technical product; one of the discouragements was, imo, being told we had to write these proposals in our spare time. We did not really have meaningful spare time at that startup.