6 ms·

Technical debt is often a result of competent engineers dealing with uncertainty, changing requirements or a bad engineering culture, but it is sometimes just a

Technical debt is often a result of competent engineers dealing with uncertainty, changing requirements or a bad engineering culture, but it is sometimes just a result of unskilled engineers, and I think as a field, we like to pretend that's not true.

nevinera 4y ago
I think "undisciplined" is more specifically accurate.
drewcoo 4y ago
Technical debt is a metaphor about intentionally making tradeoffs. If engineers are unskilled, it's unlikely that they can do that. All problem code is not technical debt. https://www.castsoftware.com/blog/ward-cunningham-capers-jones-a-discussion-on-technical-debt https://www.castsoftware.com/blog/ward-cunningham-capers-jon...
- rileymat2 4y ago
  If you are hiring unskilled engineers to push the product out faster, isn't that just management intentionally making a trade off for technical debt?
  - zwkrt 4y ago
    Right but that starts to sound like organizational debt, which I think is reasonable to treat differently.
llamataboot 4y ago
hmmm, this is true definitely on the face of it. Less skilled engineers don't see whether they are implementing functionality that couples a bunch of logic together that will be difficult to entangle, or duplicating logic, or adding a bunch of very specific logic that will be hard to abstract etc. Very good engineers are actually those that have come to understand how and why they have done that in the past and what options there are, or those that are shown through mentoring or code review or seeking out instruction on their own what different patterns and tradeoffs there are. -- But that means nothing on the face of it, since every amazing engineer did those things at one point, there are plenty of things for "less skilled engineers" to do that need to be done and they can do very well while also being helped to grow and learn, and for all of us, even 10/20/30 years in, we are still facing not only the limitations of what we didn't know we didn't know in the past, but even the limitations of the languages and frameworks we are using, and trying to make those better. -- I could also say that technical debt is the result of non-engineers prioritizing short-term features and bugs over long-term code quality and eventually everyone suffering for all the corners cut over the way - that's a popular one for the dev team, but what does that mean other than the people keeping the business going need this thing to happen and they don't care about where you put the logic, and if you want perfect code, please find someone to pay you to write it... -- This conversation happens so often in so many ways, and I'm actually in a situation right now as a technical lead where my very real ask and complaint is - we don't actually have enough deeply competent coders that have done this enough times that can make this work. We need a few more people with those deep architecture eyes, and we need to trust that what they see as priorities actually are, not for this feature, but for every feature we might create 2/3/4 years down the road as we scale. There is value in the simple truth that inexperienced or lazy or crappy coders write bad code. But if we take it out of the realm where that means those people are the problem, all that means is that to collaborate on a large codebase that is doing something in the world, we all need to figure out ways to put soft fences around people's weak spots, help them grow, and try to keep the balance of business requirements and technical debt and scaling and growing a team and hero coders and lazy coders and great product people and unreasonable product people etc etc etc in some sort of productive tension that never collapses under its own weight. -- The most beautiful code I've ever seen didn't last beyond the MVP. The worst and the best code I've ever written happened in the past, and I don't understand how I could write such things. -- Personally I think all teams could benefit from one day a week/sprint/month where every eng on the team just goes and makes something better than they know could be better. Cause everyone sees something ugly, but no one sees the same things, and we'll never agree on the priority. Regular time to go do things that are just "this is kindy sketchy and hacky or causes me pain every day, Ima go fix it"
lolinder 4y ago
I agree that much of the time that is accurate. I think that it is helpful, however, to avoid jumping to that conclusion about any given codebase. It's often a source of tension when someone joins a new team to have them racing in to fix all the "technical debt" whose origins the new engineer really doesn't understand. Little is gained by assuming that technical debt stemmed from bad engineers, and a lot can be lost if you misjudge.
- deleted 4y ago
  [deleted]
- P5fRxh5kUvp2th 4y ago
  If you can't tell the difference between decisions made by a poor engineer or decisions made by a good engineer, then it's very possible you're a poor engineer. I shit you not I once saw the following in an actual codebase. var len = Int32.Parse(myString.Length.ToString()); I can maybe understand that code evolving to that over time, no way in hell is it a good engineer who put the final adjustment in and thought that was fine. Don't even get me started on systems that are overly stringly typed. What the other poster said is absolutely true, a good design can turn bad if it doesn't adjust as the business changes. Too many developers think the point is that the initial design should survive first contact or it was bad code, but that thinking is too static. As Mike Tyson likes to say, everyone has a plan until they get punched in the mouth. There's nothing wrong with evolving a design over time, and doing so helps others to be able to recognize good code from bad code.
  - sebastialonso 4y ago
    I agree with the overall spirit of your reply. I'd just add that framing "technical debt" with "bad code" is, ironically, what bad engineers tend to do. Easy to solve debt tends to be about "bad code". Fun debt is usually about code design. Real fun, grown-up technical debt is mostly (but no always) about architectural characteristics. Code evolving has to go hand in hand with an evolving architecture, otherwise you're just cleaning the kitchen floor while everything's on fire.
agumonkey 4y ago
Also management / pacing. Never tried it but maybe allocating one day every two weeks for codebase cleanse. Or clear headed review. And accepting that coding requires messy exploration and therefore there's always a need for post-hoc post-rest work.
- fendy3002 4y ago
  For me the hardest part of codebase cleanse is not the refactoring. It's the thorough testing and ensuring that the modification didn't break any existing functionalities. One day every two weeks is not enough. Better a week every 2 months.
  - agumonkey 4y ago
    I never did it and was mostly speaking but I was afraid a N months would make the amount of changes to clean too large. It would be nice to ask people in various companies how they pace it.
- scaredginger 4y ago
  I'd call that a bad engineering culture

nevinera 4y ago

I think "undisciplined" is more specifically accurate.

drewcoo 4y ago

Technical debt is a metaphor about intentionally making tradeoffs. If engineers are unskilled, it's unlikely that they can do that. All problem code is not technical debt. https://www.castsoftware.com/blog/ward-cunningham-capers-jones-a-discussion-on-technical-debt https://www.castsoftware.com/blog/ward-cunningham-capers-jon...

rileymat2 4y ago
If you are hiring unskilled engineers to push the product out faster, isn't that just management intentionally making a trade off for technical debt?
- zwkrt 4y ago
  Right but that starts to sound like organizational debt, which I think is reasonable to treat differently.

llamataboot 4y ago

hmmm, this is true definitely on the face of it. Less skilled engineers don't see whether they are implementing functionality that couples a bunch of logic together that will be difficult to entangle, or duplicating logic, or adding a bunch of very specific logic that will be hard to abstract etc. Very good engineers are actually those that have come to understand how and why they have done that in the past and what options there are, or those that are shown through mentoring or code review or seeking out instruction on their own what different patterns and tradeoffs there are. -- But that means nothing on the face of it, since every amazing engineer did those things at one point, there are plenty of things for "less skilled engineers" to do that need to be done and they can do very well while also being helped to grow and learn, and for all of us, even 10/20/30 years in, we are still facing not only the limitations of what we didn't know we didn't know in the past, but even the limitations of the languages and frameworks we are using, and trying to make those better. -- I could also say that technical debt is the result of non-engineers prioritizing short-term features and bugs over long-term code quality and eventually everyone suffering for all the corners cut over the way - that's a popular one for the dev team, but what does that mean other than the people keeping the business going need this thing to happen and they don't care about where you put the logic, and if you want perfect code, please find someone to pay you to write it... -- This conversation happens so often in so many ways, and I'm actually in a situation right now as a technical lead where my very real ask and complaint is - we don't actually have enough deeply competent coders that have done this enough times that can make this work. We need a few more people with those deep architecture eyes, and we need to trust that what they see as priorities actually are, not for this feature, but for every feature we might create 2/3/4 years down the road as we scale. There is value in the simple truth that inexperienced or lazy or crappy coders write bad code. But if we take it out of the realm where that means those people are the problem, all that means is that to collaborate on a large codebase that is doing something in the world, we all need to figure out ways to put soft fences around people's weak spots, help them grow, and try to keep the balance of business requirements and technical debt and scaling and growing a team and hero coders and lazy coders and great product people and unreasonable product people etc etc etc in some sort of productive tension that never collapses under its own weight. -- The most beautiful code I've ever seen didn't last beyond the MVP. The worst and the best code I've ever written happened in the past, and I don't understand how I could write such things. -- Personally I think all teams could benefit from one day a week/sprint/month where every eng on the team just goes and makes something better than they know could be better. Cause everyone sees something ugly, but no one sees the same things, and we'll never agree on the priority. Regular time to go do things that are just "this is kindy sketchy and hacky or causes me pain every day, Ima go fix it"

lolinder 4y ago

I agree that much of the time that is accurate. I think that it is helpful, however, to avoid jumping to that conclusion about any given codebase. It's often a source of tension when someone joins a new team to have them racing in to fix all the "technical debt" whose origins the new engineer really doesn't understand. Little is gained by assuming that technical debt stemmed from bad engineers, and a lot can be lost if you misjudge.

deleted 4y ago
[deleted]
P5fRxh5kUvp2th 4y ago
If you can't tell the difference between decisions made by a poor engineer or decisions made by a good engineer, then it's very possible you're a poor engineer. I shit you not I once saw the following in an actual codebase. var len = Int32.Parse(myString.Length.ToString()); I can maybe understand that code evolving to that over time, no way in hell is it a good engineer who put the final adjustment in and thought that was fine. Don't even get me started on systems that are overly stringly typed. What the other poster said is absolutely true, a good design can turn bad if it doesn't adjust as the business changes. Too many developers think the point is that the initial design should survive first contact or it was bad code, but that thinking is too static. As Mike Tyson likes to say, everyone has a plan until they get punched in the mouth. There's nothing wrong with evolving a design over time, and doing so helps others to be able to recognize good code from bad code.
- sebastialonso 4y ago
  I agree with the overall spirit of your reply. I'd just add that framing "technical debt" with "bad code" is, ironically, what bad engineers tend to do. Easy to solve debt tends to be about "bad code". Fun debt is usually about code design. Real fun, grown-up technical debt is mostly (but no always) about architectural characteristics. Code evolving has to go hand in hand with an evolving architecture, otherwise you're just cleaning the kitchen floor while everything's on fire.

agumonkey 4y ago

Also management / pacing. Never tried it but maybe allocating one day every two weeks for codebase cleanse. Or clear headed review. And accepting that coding requires messy exploration and therefore there's always a need for post-hoc post-rest work.

fendy3002 4y ago
For me the hardest part of codebase cleanse is not the refactoring. It's the thorough testing and ensuring that the modification didn't break any existing functionalities. One day every two weeks is not enough. Better a week every 2 months.
- agumonkey 4y ago
  I never did it and was mostly speaking but I was afraid a N months would make the amount of changes to clean too large. It would be nice to ask people in various companies how they pace it.
scaredginger 4y ago
I'd call that a bad engineering culture