3 ms·

> Laurent Bossavit, an Agile methodology expert Congratulations, you got me to stop reading just at the start of the article. On topic, I don't think any good

> Laurent Bossavit, an Agile methodology expert Congratulations, you got me to stop reading just at the start of the article. On topic, I don't think any good engineer ever claimed the title of the article. The "more expensive" part stems from having to rush and maybe do a sloppy job, introducing regressions, higher hosting costs or other maladies. So the "higher cost" might just be a compounding value borne out of panicky measures. Sometimes you really do have to get your sleeves rolled up and timebox any fix you have in mind and just progress and/or actually kill the problem. Often though, you just deflect the problem to somewhere else temporarily where the "bleeding" will not be as significant. Which buys you the time to do a better job. Titles like those of the articles are highly dramatized. I am surprised any serious working person ever took them seriously.

tobyjsullivan 1y ago
> I don't think any good engineer ever claimed the title I don’t claim to be a good engineer but I have made the claim in the title many times. Though it’s usually in the form of a more nuanced statement. It’s about time, rather than money. If you can change a line of code to fix a bug before making your commit, that’s a lot faster than all the rigmarole of shipping the same fix later (new PR, code review, wait for CI, merge, deploy, etc.). Not to mention troubleshooting and debugging effort. The multiplier depends on your context but the bar isn’t high. 100x a 30-second fix is about an hour of effort. I’ve worked in several teams where the average effort to change a line on prod approached that (with honest measurement, including context switching costs)
- TeMPOraL 1y ago
  I believe in a soft form of that too (i.e. no specific numbers); the severity really depends on the type of project. In few industrial and enterprise projects I worked on, once you cross past "testing", fixing a bug involved coordinating with another team, which was doing a test deployment or evaluation at customer site; at that point, extra process would kick in, and if it was severe enough (or you were unlucky enough) the customer side got wind of it, you could expect some extra e-mail rounds and possibly a meeting. Now, if your bug didn't get noticed then, and failed in actual production... the time and cost multiplier was effectively unbounded. A fix for a simple and low-impact bug could take a week to get from commit to being ready to release, and then wait a month in limbo, because there are schedules to these kinds of projects (can't really do continuous delivery if each release triggers a validation and sign-off process on customer's end, that engages a team of people for a day or more). A fix for a more complex or impactful bug could become... the last thing you release, if the customer gives up on your product over it. Etc. People like to focus on technical aspects (restoring databases, hard-to-reach hardware, etc.) when discussing this concept, but there are whole classes of projects where the driving aspect is bureaucracy - coordinating business side, altering long-term project plans, getting sign-off on testing, re-evaluating regulatory compliance, etc. That can quickly get arbitrarily expensive.
jdlshore 1y ago
> On topic, I don't think any good engineer ever claimed the title of the article. It’s been a common claim in the past, usually preceded by the phrase “research studies have found…” Steve McConnell is probably the most well known these days, but Barry Boehm is probably the first person to popularize the claim. Separately, just because you haven’t heard something doesn’t mean it doesn’t happen.
- pdimitar 1y ago
  Obviously it could be a thing. But I feel it's been blown out of proportion, as it often happens.

tobyjsullivan 1y ago

> I don't think any good engineer ever claimed the title I don’t claim to be a good engineer but I have made the claim in the title many times. Though it’s usually in the form of a more nuanced statement. It’s about time, rather than money. If you can change a line of code to fix a bug before making your commit, that’s a lot faster than all the rigmarole of shipping the same fix later (new PR, code review, wait for CI, merge, deploy, etc.). Not to mention troubleshooting and debugging effort. The multiplier depends on your context but the bar isn’t high. 100x a 30-second fix is about an hour of effort. I’ve worked in several teams where the average effort to change a line on prod approached that (with honest measurement, including context switching costs)

TeMPOraL 1y ago
I believe in a soft form of that too (i.e. no specific numbers); the severity really depends on the type of project. In few industrial and enterprise projects I worked on, once you cross past "testing", fixing a bug involved coordinating with another team, which was doing a test deployment or evaluation at customer site; at that point, extra process would kick in, and if it was severe enough (or you were unlucky enough) the customer side got wind of it, you could expect some extra e-mail rounds and possibly a meeting. Now, if your bug didn't get noticed then, and failed in actual production... the time and cost multiplier was effectively unbounded. A fix for a simple and low-impact bug could take a week to get from commit to being ready to release, and then wait a month in limbo, because there are schedules to these kinds of projects (can't really do continuous delivery if each release triggers a validation and sign-off process on customer's end, that engages a team of people for a day or more). A fix for a more complex or impactful bug could become... the last thing you release, if the customer gives up on your product over it. Etc. People like to focus on technical aspects (restoring databases, hard-to-reach hardware, etc.) when discussing this concept, but there are whole classes of projects where the driving aspect is bureaucracy - coordinating business side, altering long-term project plans, getting sign-off on testing, re-evaluating regulatory compliance, etc. That can quickly get arbitrarily expensive.

jdlshore 1y ago

> On topic, I don't think any good engineer ever claimed the title of the article. It’s been a common claim in the past, usually preceded by the phrase “research studies have found…” Steve McConnell is probably the most well known these days, but Barry Boehm is probably the first person to popularize the claim. Separately, just because you haven’t heard something doesn’t mean it doesn’t happen.

pdimitar 1y ago
Obviously it could be a thing. But I feel it's been blown out of proportion, as it often happens.