3 ms·

Let’s be honest this is the kind of thing that can happen to anyone. We all like to think we have picked up habits that immunize us from certain kinds of error

Let’s be honest this is the kind of thing that can happen to anyone. We all like to think we have picked up habits that immunize us from certain kinds of error but large software systems are complex and bugs happen. The number of people in here taking ‘Raymond Chen tells an anecdote about the time a dumb bug shipped in Windows and was fixed two weeks later’ as an indictment of Microsoft’s engineering culture is frankly embarrassing. Trading war stories is how we all get better. It would be better for us all if culturally, the reaction to a developer telling a story of how they once shipped a stupid bug were for everyone to reply with examples of worse stuff they’ve done themselves, not to smugly nod and say ‘ah yes, I am too smart to make such a mistake’.

phkahler 1y ago
>> Let’s be honest this is the kind of thing that can happen to anyone. I didn't say I'm immune to doing this myself, nor did I condemn anything about the particular scenario in the blog. My pain is in trying to articulate why some ways are better when any code that works is in some sense just fine. >> We all like to think we have picked up habits that immunize us from certain kinds of error but large software systems are complex and bugs happen. We sure do, although "immunize" is too strong. We try to minimize the likelyhood of these kinds of things. Experience is valuable and sometimes it's hard to articulate why.
- jameshart 1y ago
  That’s been my experience of what it means to try to do ‘software engineering’ as a discipline; it’s the ongoing process of developing ways to articulate - beyond just ‘this way feels better to me’ - what attributes we are trying to build into the software we construct, what methods we use to imbue the software with those attributes, and why certain ways of doing so are better than others. It still feels more like craftsmanship than actual engineering. A lot of the time it’s more like how a carpenter learns to use certain tools in certain ways because it’s safer or less prone to error, than how an engineer knows how constructing a particular truss ensures particular loads are distributed in particular ways. And one of the best tools we have for developing these skills is to learn from the mistakes others have made. So I agree - I think your instinct here was to look at this error and try to think whether you have engineering heuristics already that would make you unlikely to fall into this error, or do you need to adjust your approach to avoid making the same mistake. My criticism here was more directed to others in the thread who seem to see this more as an opportunity to say ‘yeah, Windows was always buggy’ rather than to see it as an example of a way things can fail that they need to beware of.
SoftTalker 1y ago
I don't think this kind of thing can happen to anyone. This strikes me a feature that was not tested. So, you're going to implement bitmapped backgrounds. Naturally, after writing the code, you test with and without bitmapped backgrounds and make sure both cases work. Right?
- jameshart 1y ago
  And nobody ever changes any of the code again.

phkahler 1y ago

>> Let’s be honest this is the kind of thing that can happen to anyone. I didn't say I'm immune to doing this myself, nor did I condemn anything about the particular scenario in the blog. My pain is in trying to articulate why some ways are better when any code that works is in some sense just fine. >> We all like to think we have picked up habits that immunize us from certain kinds of error but large software systems are complex and bugs happen. We sure do, although "immunize" is too strong. We try to minimize the likelyhood of these kinds of things. Experience is valuable and sometimes it's hard to articulate why.

jameshart 1y ago
That’s been my experience of what it means to try to do ‘software engineering’ as a discipline; it’s the ongoing process of developing ways to articulate - beyond just ‘this way feels better to me’ - what attributes we are trying to build into the software we construct, what methods we use to imbue the software with those attributes, and why certain ways of doing so are better than others. It still feels more like craftsmanship than actual engineering. A lot of the time it’s more like how a carpenter learns to use certain tools in certain ways because it’s safer or less prone to error, than how an engineer knows how constructing a particular truss ensures particular loads are distributed in particular ways. And one of the best tools we have for developing these skills is to learn from the mistakes others have made. So I agree - I think your instinct here was to look at this error and try to think whether you have engineering heuristics already that would make you unlikely to fall into this error, or do you need to adjust your approach to avoid making the same mistake. My criticism here was more directed to others in the thread who seem to see this more as an opportunity to say ‘yeah, Windows was always buggy’ rather than to see it as an example of a way things can fail that they need to beware of.

SoftTalker 1y ago

I don't think this kind of thing can happen to anyone. This strikes me a feature that was not tested. So, you're going to implement bitmapped backgrounds. Naturally, after writing the code, you test with and without bitmapped backgrounds and make sure both cases work. Right?

jameshart 1y ago
And nobody ever changes any of the code again.