3 ms·

> 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 usu

> 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.

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.