3 ms·

IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned p

by korijn 8y ago

IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.

deanmoriarty 8y ago
In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.
PhantomGremlin 8y ago
That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed. But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon. Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.
nradov 8y ago
Only lazy, sloppy developers fail by repeating the same mistakes as others. Unless they're working on something truly novel (unlikely) there are books and articles out there which explain the problems to avoid.

by korijn 8y ago

IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.

deanmoriarty 8y ago

In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.

PhantomGremlin 8y ago

That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed. But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon. Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.

nradov 8y ago

Only lazy, sloppy developers fail by repeating the same mistakes as others. Unless they're working on something truly novel (unlikely) there are books and articles out there which explain the problems to avoid.