Comment by Fire-Dragon-DoL
13 days 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
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.
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.)
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)
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.
> 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.