|
> "Oh, the bridge fell down and killed 15 people, but it was worth it because I built a lot of bridges this week" Not everything non-software engineers do is life or death either, and there are plenty of software people who do work in critical areas that don't have that attitude. This oft-repeated view is a caricature. Licensed engineers make all sorts of crappy consumer goods that fail all over the place. Conversely, there are software engineers involved in medical devices, defence and various other spheres that follow very risk-averse, formalised coding, verification and release procedures. The fact that a lot of consumer-oriented software is insecure, flakey crap is a consequence of time pressure and risk tolerance, as well as nebulous or amorphous requirements. Should I release this now, and try to capture the market, move fast and break things, adapting functionality as I go, with quality important but not that important? Or should I spec out a complete and formal design, maybe formally verify it, implement to that spec and thoroughly validate it all afterwards? There'll be no product for five years but that's OK. This latter category does exist, but isn't especially visible because it's not very sexy, it doesn't have 'hero' engineers, and there are few techbros getting rich off it. |