10 ms·

I work on a product that has been built over 25 years. Lots of the work I did years ago is to ensure the product longevity. Lots of the work I do now is to ens

I work on a product that has been built over 25 years. Lots of the work I did years ago is to ensure the product longevity. Lots of the work I do now is to ensure it lasts another 25 years. Thats good, but its only the start of "my work". It's up to me to "sell" that benefit to upper management. There's no point in assuming they'll figure it out by accident. Part of my job is enumerating the value I add. By all means work on technical debt. But be sure to make a compelling case as to how the eradication of that debt will impact the project over the next decade. Try and throw in immediate results as well (faster, more reliable, reduced support) but more importantly translate that into terms that measure the improvement in cold hard cash.

Fire-Dragon-DoL 2y ago
How do you put numbers in there usually? I'm facing an issue at work where an important factor should be done to correct a serious design mistake, but it doesn't get in the way of any feature. It's probably the cause of a lot of loss of development time over the lifetime of the project, but I don physically know how much of a boost will it give to development. I know it will, but I wouldn't feel comfortable without quantifying. I have some rough idea for approaches to this, but would appreciate some external input as well
- 6510 2y ago
  I only do small solo projects but the value from maintainable code depends on how often it needs to be updated. If management comes with new [crazy] ideas and/or feature [cruft] every other week it should be easy to prefer a warehouse with ready to use components over a scrap yard. If you need a set of usable tires a few times per year the scrap yard will provide. If you need a set of tires 20 times per day you want at least 200 sets of each kind stored in a convenient place. You probably live some place in between. edit: Also, timing is everything. Write down everything you want, add the pony. Wait for the right moment when their head is not raging with 50 deadlines. Most important imho is to not want anything but explain what options they have. If they want faster results they might be able to get them by attacking the technical debt.
- pjc50 2y ago
  > How do you put numbers in there usually? Make them up. If you're uncomfortable with this, ask ChatGPT to make them up for you. Most places don't have any real way to measure productivity or rate of feature delivery, so as long as you promise a reasonable number (5-10%) they have no way of contradicting you. Incremental refactoring is also the other classic way to do this. Slip bits into other tickets until you've slowly dragged the ship around. But it's not always possible.
- jeffparsons 2y ago
  One way to communicate this is in terms of _schedule risk_, rather than straight-up lost productivity. E.g. for a particularly troublesome design flaw, you might estimate that for any given 4-week project there's a 20% risk of the project blowing out by an extra week due to that flaw. Depending on the stakeholder(s) you're dealing with, approaching it like this (as risk assessment/management) might help to convey the short-term impact of a long-term problem.
- bruce511 2y ago
  It can be tough, and in some cases measurable numbers are hard to find. That can make prioritization hard. It's worth keeping open the option that "now is not yet the right time". One key way to understand the situation well is to explore both thd upsides and downsides of the issue. Its almost never an obvious decision and being acquainted with all points of view really helps both to figure out what is right, whether it's worth doing, if now is the right time, and so on. If it was obviously necessary it would likely already have been done, so it may be necessary, but it might not yet be time. Sometimes it comes down to groundwork. Finding out who us affected, and how. (And if you can't find those people, that's a clue too.)
  - Fire-Dragon-DoL 2y ago
    Indeed, I was the one suggesting to not do the refactor because I couldn't find a reason. Today at standup though, a task that would take 1 hour once the refactor is done, will probably take about 2 days instead, so i'm back thinking about it (the refactor would take longer than 2 days)
hansmayer 2y ago
I get your point at the basic level, but as engineers and managers, we need to stop this nonsense. Think deeper about why do you need to "sell" your work inside (some) companies ? Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work. What's the value such busywork managers are adding, besides the anti-value of layers of explanatory communication and wasted time? The busywork folks should be working to understand where their salaries are coming from, not the engineers. Note that I am not saying all managers are useless (its also a part of my job), it's the people-and-ideas-managers who are useless in the technical setting. The point about technical debt should be a non-issue, why the hell would you have to explain that the technical debt is a bad thing? Did we not clear this issue many times over and establish zero technical debt as an engineering ideal a long time ago? Well it is because some person with 1/4 of your experience and competence somehow got lucky and talked themselves into one or two hierarchical positions above you. We need to start a pushback across the industry and stop allowing former accountants and humanist science graduates into "leadership" roles in IT.
- dave4420 2y ago
  There’s a difference between management knowing that it’s worth paying off tech debt in general, and management knowing that now is the right time to pay off this piece of tech debt in particular. Why pay off tech debt A and not tech debt B? Is this really more urgent than implementing feature C? I have some financial debts, but I prioritise paying off some over others, and even allow myself to buy myself nice things instead of paying off the mortgage early. The same principle applies with tech debt, except I have to justify my choices to my bosses instead of to my girlfriend.
- dagw 2y ago
  Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work. Every company I've ever worked at has more work that they would like to do than they have engineers to do it. The problem often isn't that they don't understand why fixing technical debt is important, it's to decide if fixing that particular technical debt right now is the best use of these resources right now. Also they might also know things that I might not know, like long term plans for and the relative profitability of different projects, which will affect how they make decisions. No point in spending effort fixing technical debt if that project/department is already slated for closure. Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.
moduspol 2y ago
100%, although also: Try to be as objective as possible when evaluating that tech debt. It's possible (in many cases, probable) that the tech debt actually isn't as bad for the business as an engineer perceives, and it's quite possible there are other engineering efforts that are more worthy of development time and resources. Being willing and vocal about acknowledging and accepting that reality is also quite helpful.

Fire-Dragon-DoL 2y ago

How do you put numbers in there usually? I'm facing an issue at work where an important factor should be done to correct a serious design mistake, but it doesn't get in the way of any feature. It's probably the cause of a lot of loss of development time over the lifetime of the project, but I don physically know how much of a boost will it give to development. I know it will, but I wouldn't feel comfortable without quantifying. I have some rough idea for approaches to this, but would appreciate some external input as well

6510 2y ago
I only do small solo projects but the value from maintainable code depends on how often it needs to be updated. If management comes with new [crazy] ideas and/or feature [cruft] every other week it should be easy to prefer a warehouse with ready to use components over a scrap yard. If you need a set of usable tires a few times per year the scrap yard will provide. If you need a set of tires 20 times per day you want at least 200 sets of each kind stored in a convenient place. You probably live some place in between. edit: Also, timing is everything. Write down everything you want, add the pony. Wait for the right moment when their head is not raging with 50 deadlines. Most important imho is to not want anything but explain what options they have. If they want faster results they might be able to get them by attacking the technical debt.
pjc50 2y ago
> How do you put numbers in there usually? Make them up. If you're uncomfortable with this, ask ChatGPT to make them up for you. Most places don't have any real way to measure productivity or rate of feature delivery, so as long as you promise a reasonable number (5-10%) they have no way of contradicting you. Incremental refactoring is also the other classic way to do this. Slip bits into other tickets until you've slowly dragged the ship around. But it's not always possible.
jeffparsons 2y ago
One way to communicate this is in terms of _schedule risk_, rather than straight-up lost productivity. E.g. for a particularly troublesome design flaw, you might estimate that for any given 4-week project there's a 20% risk of the project blowing out by an extra week due to that flaw. Depending on the stakeholder(s) you're dealing with, approaching it like this (as risk assessment/management) might help to convey the short-term impact of a long-term problem.
bruce511 2y ago
It can be tough, and in some cases measurable numbers are hard to find. That can make prioritization hard. It's worth keeping open the option that "now is not yet the right time". One key way to understand the situation well is to explore both thd upsides and downsides of the issue. Its almost never an obvious decision and being acquainted with all points of view really helps both to figure out what is right, whether it's worth doing, if now is the right time, and so on. If it was obviously necessary it would likely already have been done, so it may be necessary, but it might not yet be time. Sometimes it comes down to groundwork. Finding out who us affected, and how. (And if you can't find those people, that's a clue too.)
- Fire-Dragon-DoL 2y ago
  Indeed, I was the one suggesting to not do the refactor because I couldn't find a reason. Today at standup though, a task that would take 1 hour once the refactor is done, will probably take about 2 days instead, so i'm back thinking about it (the refactor would take longer than 2 days)

hansmayer 2y ago

I get your point at the basic level, but as engineers and managers, we need to stop this nonsense. Think deeper about why do you need to "sell" your work inside (some) companies ? Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work. What's the value such busywork managers are adding, besides the anti-value of layers of explanatory communication and wasted time? The busywork folks should be working to understand where their salaries are coming from, not the engineers. Note that I am not saying all managers are useless (its also a part of my job), it's the people-and-ideas-managers who are useless in the technical setting. The point about technical debt should be a non-issue, why the hell would you have to explain that the technical debt is a bad thing? Did we not clear this issue many times over and establish zero technical debt as an engineering ideal a long time ago? Well it is because some person with 1/4 of your experience and competence somehow got lucky and talked themselves into one or two hierarchical positions above you. We need to start a pushback across the industry and stop allowing former accountants and humanist science graduates into "leadership" roles in IT.

dave4420 2y ago
There’s a difference between management knowing that it’s worth paying off tech debt in general, and management knowing that now is the right time to pay off this piece of tech debt in particular. Why pay off tech debt A and not tech debt B? Is this really more urgent than implementing feature C? I have some financial debts, but I prioritise paying off some over others, and even allow myself to buy myself nice things instead of paying off the mortgage early. The same principle applies with tech debt, except I have to justify my choices to my bosses instead of to my girlfriend.
dagw 2y ago
Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work. Every company I've ever worked at has more work that they would like to do than they have engineers to do it. The problem often isn't that they don't understand why fixing technical debt is important, it's to decide if fixing that particular technical debt right now is the best use of these resources right now. Also they might also know things that I might not know, like long term plans for and the relative profitability of different projects, which will affect how they make decisions. No point in spending effort fixing technical debt if that project/department is already slated for closure. Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.

moduspol 2y ago

100%, although also: Try to be as objective as possible when evaluating that tech debt. It's possible (in many cases, probable) that the tech debt actually isn't as bad for the business as an engineer perceives, and it's quite possible there are other engineering efforts that are more worthy of development time and resources. Being willing and vocal about acknowledging and accepting that reality is also quite helpful.