5 ms·

Sure, and credit cards can be a good thing, too. The problem is that most non-technical and formerly-technical project managers just charge everything to their

Sure, and credit cards can be a good thing, too. The problem is that most non-technical and formerly-technical project managers just charge everything to their credit cards and don't even know they own debt and are making interest payments on it. When that's the level of awareness the average development team is dealing with, there's limited practical purpose in exploring the nuances of healthy debt management. It's more useful to talk about technical debt like nutritionists talk about empty calories and transfats.

allyjweir 9y ago
I like your comparison to nutrition. To stretch the analogy slightly, sometimes in life you only have time for that microwave meal rather than a freshly prepared salad. It's about ingestion of calories to keep going, not the quality of those. The same _can be_ true with code. There can be a better way to do something but if you cannot afford the time to develop and iterate this idea then it can be advantageous to develop the simplest solution that meets your needs today and make progress.
rebeccaskinner 9y ago
I see accusations of this a lot, and honestly I just really wonder what the team structures are like at a lot of companies- or what the experience level is of the average HN reader. Because you're right, PMs don't have the insight to understand the nuances of technical debt and the benefits and costs associated with varied approaches, and really it's not their job to. As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. Regardless of how much PMs might want things or fiddle with the schedule, as professionals it's our job- not theirs- to say when things can't be done, shouldn't be attempted, or might cost more than they're worth.
- snarfy 9y ago
  You must be an expert[1] [1] - https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
- knz 9y ago
  > As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. That gets back to company culture (which others have identified higher up). Not every organisation responds appropriately when developers push back (either due to imposed deadlines or office politics).
  - humanrebar 9y ago
    > Not every organisation responds appropriately when developers push back... In my experience, organizations generally do the right thing if all the developers push back. The problem is that you can always find developers that will push a hack or deploy an overwrought solution for a simple problem.
- notabee 9y ago
  And then after saying no, you can watch the executives hire or promote up someone who says what they want to hear regardless of its feasibility, usually while using the latest buzzwords. Lacking domain knowledge or the interest to acquire it is a good sign that they will lack the awareness to avoid facile answers.
  - eanzenberg 9y ago
    Saying "No" or shutting that door down is a bad thing that I don't like either. Rephrase it by using "sure, we could build that, however it will require X person-days with a team of Y senior level engineers."
    - s73v3r_ 9y ago
      Don't do that. All they're going to hear is "Sure, we could do that." They're not going to listen to the rest of it, and then it's going to be your fault when stuff doesn't work.
      - Thrymr 9y ago
        Another way to say it is "We could do that, but it will delay this other thing that is on your roadmap as top priority for X months."
        s73v3r_ 9y ago
        The second they hear "We could do that," they tune the rest of everything out.
        NegativeK 9y ago
        I've interacted with some bad sales people before, but they rarely tune out when you say things are going to be delayed.
      - eanzenberg 9y ago
        That's the point. Almost anything is possible with the right team. Once it's communicated in terms of cost then the assessment is made whether it's worth it or not.
- s73v3r_ 9y ago
  And just like there are plenty of crappy software developers, there are plenty of crappy PMs who choose not to listen to developers, and ignore all of that. Recall the article about the toxic culture over at Take Two from yesterday. No matter how much push back happened, they would be met with "Tough. I guess you live here for the next 6 months."
- humanrebar 9y ago
  > I just really wonder what the team structures are like... Maybe you're lucky or maybe I'm benighted, but it's rare that an organization consciously decides that this is the quarter to finish off the Java 5 migrations, even if that means delaying the Jabberwocky Project and even if there's a non-zero chance of customer impact. Partly because it's a really hard problem to attach an accurate and objective number to the value of something like that. > ...technical debt and the benefits and costs associated with varied approaches... That's not entirely accurate. Engineers are experts at technical benefits of different approaches. And they should be experts on the entire cost of the systems they are responsible for. But they're not necessarily experts on the benefits. They aren't necessarily qualified to anticipate what different features and different release schedules will do to the revenue for the product. In B2C companies with millions of users, you can run statistics and A/B testing to make this stuff more objective, but a lot of companies live and die by big sales to a smaller number of customers. So determining the benefits of shipping a month early depends a lot on knowing particular people well enough to guess how they'll react to good or bad news.
wes-k 9y ago
YES! As a developer I can FEEL the pain of our code debt but I don't know how to convey the importance to management. There's definitely a balance to it and I'm certainly biased in favor of letting those in the code make the judgement call. One solution I thought of was to enact a 20% code debt policy, similar to google's 20% time but for code debt. Hey developer, is there something causing you pain? Fix it!
- maxxxxx 9y ago
  "One solution I thought of was to enact a 20% code debt policy, similar to google's 20% time but for code debt" That's sort of how I do it. The key is to never tell management explicitly. It's just normal part of the job.
  - wes-k 9y ago
    Ya I usually "sneak in" cleanups associated with stories. The problem with that is it doesn't allow for bigger more impactful refactors. So usually the debt that hurts the most never gets dealt with.
    - maxxxxx 9y ago
      I find that a lot of pain is in the details that can be fixed with a few hours or days of work.
  - humanrebar 9y ago
    This approach tends to work well. If they don't want to worry about it, they've effectively delegated it to you. The only problem is that this setup is subject to the tragedy of the commons. If it takes 25% more work to make a change cleanly, the developers throwing hacks around look 20% more productive if we ignore technical debt. And, worse, they're often the only people in the world that understand the hacks, so they get to be the hero-experts that come in and save the day when everyone else is trying to figure out what the hell is going on. So even if we'll do our best to bake the cost of cleanup into our day-to-day tasks, that only works as long as a critical mass of the developers in the organization do the same thing. Otherwise, you'll have a full time job plus some just cleaning up messes.
maxxxxx 9y ago
In the end it's up to the devs to make it clear dealing with debt is just part of being a professional dev. In my team I never tell management about refactoring. We just do it as part of the daily job. You won't get major rewrites done that way but over time you can clean up a lot of problems if you are a little strategic.
gnulinux 9y ago
> Sure, and credit cards can be a good thing, too. Can you give an example?
- nhaoe89n 9y ago
  You're stranded in a foreign place and have no cash in the local currency. There's no ATM around, but there are businesses that take credit and you can pay the bill for it at the end of the month. Something unexpected pops up like a family member dies and you need to arrange a funeral, but don't have the cash on hand because some other emergency last month used up your liquid savings. You know that you can pay it off over the long run, but don't have any other way to deal with it right now. So you go into a small amount of debt that you can likely pay off without paying too much over the original cost. There are a million ways that they can be good. There are probably more ways they can be bad, but this question is very simplistic.

allyjweir 9y ago

I like your comparison to nutrition. To stretch the analogy slightly, sometimes in life you only have time for that microwave meal rather than a freshly prepared salad. It's about ingestion of calories to keep going, not the quality of those. The same _can be_ true with code. There can be a better way to do something but if you cannot afford the time to develop and iterate this idea then it can be advantageous to develop the simplest solution that meets your needs today and make progress.

rebeccaskinner 9y ago

I see accusations of this a lot, and honestly I just really wonder what the team structures are like at a lot of companies- or what the experience level is of the average HN reader. Because you're right, PMs don't have the insight to understand the nuances of technical debt and the benefits and costs associated with varied approaches, and really it's not their job to. As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. Regardless of how much PMs might want things or fiddle with the schedule, as professionals it's our job- not theirs- to say when things can't be done, shouldn't be attempted, or might cost more than they're worth.

snarfy 9y ago
You must be an expert[1] [1] - https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
knz 9y ago
> As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. That gets back to company culture (which others have identified higher up). Not every organisation responds appropriately when developers push back (either due to imposed deadlines or office politics).
- humanrebar 9y ago
  > Not every organisation responds appropriately when developers push back... In my experience, organizations generally do the right thing if all the developers push back. The problem is that you can always find developers that will push a hack or deploy an overwrought solution for a simple problem.
notabee 9y ago
And then after saying no, you can watch the executives hire or promote up someone who says what they want to hear regardless of its feasibility, usually while using the latest buzzwords. Lacking domain knowledge or the interest to acquire it is a good sign that they will lack the awareness to avoid facile answers.
- eanzenberg 9y ago
  Saying "No" or shutting that door down is a bad thing that I don't like either. Rephrase it by using "sure, we could build that, however it will require X person-days with a team of Y senior level engineers."
  - s73v3r_ 9y ago
    Don't do that. All they're going to hear is "Sure, we could do that." They're not going to listen to the rest of it, and then it's going to be your fault when stuff doesn't work.
    - Thrymr 9y ago
      Another way to say it is "We could do that, but it will delay this other thing that is on your roadmap as top priority for X months."
      - s73v3r_ 9y ago
        The second they hear "We could do that," they tune the rest of everything out.
        NegativeK 9y ago
        I've interacted with some bad sales people before, but they rarely tune out when you say things are going to be delayed.
    - eanzenberg 9y ago
      That's the point. Almost anything is possible with the right team. Once it's communicated in terms of cost then the assessment is made whether it's worth it or not.
s73v3r_ 9y ago
And just like there are plenty of crappy software developers, there are plenty of crappy PMs who choose not to listen to developers, and ignore all of that. Recall the article about the toxic culture over at Take Two from yesterday. No matter how much push back happened, they would be met with "Tough. I guess you live here for the next 6 months."
humanrebar 9y ago
> I just really wonder what the team structures are like... Maybe you're lucky or maybe I'm benighted, but it's rare that an organization consciously decides that this is the quarter to finish off the Java 5 migrations, even if that means delaying the Jabberwocky Project and even if there's a non-zero chance of customer impact. Partly because it's a really hard problem to attach an accurate and objective number to the value of something like that. > ...technical debt and the benefits and costs associated with varied approaches... That's not entirely accurate. Engineers are experts at technical benefits of different approaches. And they should be experts on the entire cost of the systems they are responsible for. But they're not necessarily experts on the benefits. They aren't necessarily qualified to anticipate what different features and different release schedules will do to the revenue for the product. In B2C companies with millions of users, you can run statistics and A/B testing to make this stuff more objective, but a lot of companies live and die by big sales to a smaller number of customers. So determining the benefits of shipping a month early depends a lot on knowing particular people well enough to guess how they'll react to good or bad news.

wes-k 9y ago

YES! As a developer I can FEEL the pain of our code debt but I don't know how to convey the importance to management. There's definitely a balance to it and I'm certainly biased in favor of letting those in the code make the judgement call. One solution I thought of was to enact a 20% code debt policy, similar to google's 20% time but for code debt. Hey developer, is there something causing you pain? Fix it!

maxxxxx 9y ago
"One solution I thought of was to enact a 20% code debt policy, similar to google's 20% time but for code debt" That's sort of how I do it. The key is to never tell management explicitly. It's just normal part of the job.
- wes-k 9y ago
  Ya I usually "sneak in" cleanups associated with stories. The problem with that is it doesn't allow for bigger more impactful refactors. So usually the debt that hurts the most never gets dealt with.
  - maxxxxx 9y ago
    I find that a lot of pain is in the details that can be fixed with a few hours or days of work.
- humanrebar 9y ago
  This approach tends to work well. If they don't want to worry about it, they've effectively delegated it to you. The only problem is that this setup is subject to the tragedy of the commons. If it takes 25% more work to make a change cleanly, the developers throwing hacks around look 20% more productive if we ignore technical debt. And, worse, they're often the only people in the world that understand the hacks, so they get to be the hero-experts that come in and save the day when everyone else is trying to figure out what the hell is going on. So even if we'll do our best to bake the cost of cleanup into our day-to-day tasks, that only works as long as a critical mass of the developers in the organization do the same thing. Otherwise, you'll have a full time job plus some just cleaning up messes.

maxxxxx 9y ago

In the end it's up to the devs to make it clear dealing with debt is just part of being a professional dev. In my team I never tell management about refactoring. We just do it as part of the daily job. You won't get major rewrites done that way but over time you can clean up a lot of problems if you are a little strategic.

gnulinux 9y ago

> Sure, and credit cards can be a good thing, too. Can you give an example?

nhaoe89n 9y ago
You're stranded in a foreign place and have no cash in the local currency. There's no ATM around, but there are businesses that take credit and you can pay the bill for it at the end of the month. Something unexpected pops up like a family member dies and you need to arrange a funeral, but don't have the cash on hand because some other emergency last month used up your liquid savings. You know that you can pay it off over the long run, but don't have any other way to deal with it right now. So you go into a small amount of debt that you can likely pay off without paying too much over the original cost. There are a million ways that they can be good. There are probably more ways they can be bad, but this question is very simplistic.