3 ms·

> There's a real anti-engineering bias in this industry. What we do is hardly real engineering in most cases. I don't mean medical or transportation systems.

> There's a real anti-engineering bias in this industry. What we do is hardly real engineering in most cases. I don't mean medical or transportation systems. In BigCorp, most of us write line of business applications, which will generally speaking not directly kill anyone - unlike designing/engineering bridges, roof systems, etc.

subway 9y ago
I've watched the "my product isn't safety critical" line of thinking utterly fuck some companies. Any recommendations on which of your projects I can keep an eye on?
- GiorgioG 9y ago
  I've done work for organizations where the practices ranged from extremely strict processes, to no process at all (from requirements gathering to devops.) I feel my best experiences were always in places that had some process that was developed over time, that had management in place that was willing to experiment with changes to said processes. But the way Agile is bought into at most big companies these days...it feels like management just wants to be lazy: "follow the process because hey that's what these smart guys say worked over in org X" even if it's a waste of time/resources/etc.
zbentley 9y ago
Part of the reason this becomes so dangerous is myopia. If I'm "just building an internal issue tracker", sure, I don't need to spend ages securing it . . . until someone else exposes it to the open internet because that's the only way to make it available to offshore partners (which in turn is because someone in networking made the--from their perspective reasonable--decision not to pay for the setup of a VPN because it was expensive). Each person is making more or less reasonable decisions, but the way they interact with the rest of the whole is what causes disasters and inflicts real harm on people's lives. A question I'm interested in is: "real" engineering has the same issue of scale and potential myopia. Consider the guy mixing concrete at the batch plant on a tight schedule who, faced with an impending shortage of aggregate, mixes a little less into his mud--he does this so the trucks lining up to fill won't have to wait for the other truck bringing more aggregate. Now, his concrete was headed for a bridge, which is genuinely structurally compromised by the lack of aggregate. Do things like this happen in other fields of engineering with anywhere near the same frequency they happen in software? Why or why not? (In the concrete example--and, to be honest, this is just 'cause I like talking about concrete--there is no "right" answer given the shortage. "Fatten" the mud by lacking aggregate? Structural issues. Let trucks wait? Jobs with unfinished pours may have premature cementing, which, unless their contractors are willing to bite the "tear down the partial pour; it's too cemented--wreck it, rebuild the forms, start over" bullet which pretty much always ends up pointed at them and not the batch plant, leads to . . . you guessed it, structural issues).

subway 9y ago

I've watched the "my product isn't safety critical" line of thinking utterly fuck some companies. Any recommendations on which of your projects I can keep an eye on?

GiorgioG 9y ago
I've done work for organizations where the practices ranged from extremely strict processes, to no process at all (from requirements gathering to devops.) I feel my best experiences were always in places that had some process that was developed over time, that had management in place that was willing to experiment with changes to said processes. But the way Agile is bought into at most big companies these days...it feels like management just wants to be lazy: "follow the process because hey that's what these smart guys say worked over in org X" even if it's a waste of time/resources/etc.

zbentley 9y ago

Part of the reason this becomes so dangerous is myopia. If I'm "just building an internal issue tracker", sure, I don't need to spend ages securing it . . . until someone else exposes it to the open internet because that's the only way to make it available to offshore partners (which in turn is because someone in networking made the--from their perspective reasonable--decision not to pay for the setup of a VPN because it was expensive). Each person is making more or less reasonable decisions, but the way they interact with the rest of the whole is what causes disasters and inflicts real harm on people's lives. A question I'm interested in is: "real" engineering has the same issue of scale and potential myopia. Consider the guy mixing concrete at the batch plant on a tight schedule who, faced with an impending shortage of aggregate, mixes a little less into his mud--he does this so the trucks lining up to fill won't have to wait for the other truck bringing more aggregate. Now, his concrete was headed for a bridge, which is genuinely structurally compromised by the lack of aggregate. Do things like this happen in other fields of engineering with anywhere near the same frequency they happen in software? Why or why not? (In the concrete example--and, to be honest, this is just 'cause I like talking about concrete--there is no "right" answer given the shortage. "Fatten" the mud by lacking aggregate? Structural issues. Let trucks wait? Jobs with unfinished pours may have premature cementing, which, unless their contractors are willing to bite the "tear down the partial pour; it's too cemented--wreck it, rebuild the forms, start over" bullet which pretty much always ends up pointed at them and not the batch plant, leads to . . . you guessed it, structural issues).