he bridge analogy is plain daft. An engineer gets out a standard bridge, then alters it so that it is appropriate for the situation, as he was taught. The result? A lot of similar bridges, which on the whole, don't fail.
Snort. Something like 50% of suspension bridges built in the 19th century collapsed with 10 years of construction. Look up Petroski if you want the exact numbers.
Engineering is nearly always carried out in the dark: we really didn't have good models for suspension bridge mechanics until the 1960's but it didn't stop Roebling from building the Brooklyn Bridge in the 1880's. Airplanes were built before aerodynamics - largely because without airplanes, you can't build aerodynamic theory. Engineering is always ahead of the theory, whether it be software, hardware, mechanical or chemical.
software should be just as reliable as a bridge - and you'd know that if you'd any experience of formal methods. look at heart machines, air traffic control, the bank networks, even your microwave oven - how often does it crash?
I'd be a little bit cautious around formal methods. I don't think any of the all encompassing approaches will really be widely viable in our lifetime. Admittedly, this is largely 'cos I've got a soft spot in my heart for lightweight approaches to formal design.
But you make a good point - if it's gonna cost a life, you're gonna need caution. There are whole bodies of fault avoidance literature that the Software Engineering profession has largely ignored up until now - largely in favor of a dangerous cowboy approach. It worries me because the other engineering disciplines have learned to work like this because the cost of failure was way too high - and I'd hate to see the accidents repeat. The attitude that software is always going to be fallible just is not acceptable when lives are at stake.
I'm not entirely sure that I'd mourn the loss of a company desperate to be the next pointcast. There's an issue of degree here - you pointed out that doctors, lawyers and P.E.'s have to be certified becaus eof ethics and liability issues. I'd imagine that a good chunk of the code out there doesn't really cost lives the way a faulty power generator or a misdiagnosis does.
Maybe certification would be a form of educated guess - you can hire an uncertified programmer, but you would want to hire a certified programmer to build your weapons systems.
Engineers always complain, but it becomes inevitable. Once failure starts to cost lives, you'll start to see a demand for certification.
There's a story that Robert Stephenson, the bridge engineer, was once asked about what kind of safety factor you needed when building bridges. Traditionally, civil engineers multiply their expected maximum load by anywhere between two to five to determine the minimum strength the bridge should have. Stephenson thought this was a load of bunkum, and never bothered with a multiplicative factor - until his Dee Bridge collapsed and took 11 cars out of a 12 car train with it. After that, he became QUITE fond of multiplicative factors.
Software engineering is in the cowboy stage that civil engineering was in in the 19th century. Until we've killed enough people, we'll probably remain in that stage. Really, the only question is when we'll reach that stage.
Slashdot Mirror
he bridge analogy is plain daft. An engineer gets out a standard bridge, then alters it so that it is appropriate for the
situation, as he was taught. The result? A lot of similar bridges, which on the whole, don't fail.
Snort. Something like 50% of suspension bridges built in the 19th century collapsed with 10 years of construction. Look up Petroski if you want the exact numbers.
Engineering is nearly always carried out in the dark: we really didn't have good models for suspension bridge mechanics until the 1960's but it didn't stop Roebling from building the Brooklyn Bridge in the 1880's. Airplanes were built before aerodynamics - largely because without airplanes, you can't build aerodynamic theory. Engineering is always ahead of the theory, whether it be software, hardware, mechanical or chemical.
software should be just as reliable as a bridge - and you'd know that if you'd any experience of formal methods. look at
heart machines, air traffic control, the bank networks, even your microwave oven - how often does it crash?
I'd be a little bit cautious around formal methods. I don't think any of the all encompassing approaches will really be widely viable in our lifetime. Admittedly, this is largely 'cos I've got a soft spot in my heart for lightweight approaches to formal design.
But you make a good point - if it's gonna cost a life, you're gonna need caution. There are whole bodies of fault avoidance literature that the Software Engineering profession has largely ignored up until now - largely in favor of a dangerous cowboy approach. It worries me because the other engineering disciplines have learned to work like this because the cost of failure was way too high - and I'd hate to see the accidents repeat. The attitude that software is always going to be fallible just is not acceptable when lives are at stake.
I'm not entirely sure that I'd mourn the loss of a company desperate to be the next pointcast. There's an issue of degree here - you pointed out that doctors, lawyers and P.E.'s have to be certified becaus eof ethics and liability issues. I'd imagine that a good chunk of the code out there doesn't really cost lives the way a faulty power generator or a misdiagnosis does.
Maybe certification would be a form of educated guess - you can hire an uncertified programmer, but you would want to hire a certified programmer to build your weapons systems.
Why is Wellington Yueh running through my head?
Engineers always complain, but it becomes inevitable. Once failure starts to cost lives, you'll start to see a demand for certification.
There's a story that Robert Stephenson, the bridge engineer, was once asked about what kind of safety factor you needed when building bridges. Traditionally, civil engineers multiply their expected maximum load by anywhere between two to five to determine the minimum strength the bridge should have. Stephenson thought this was a load of bunkum, and never bothered with a multiplicative factor - until his Dee Bridge collapsed and took 11 cars out of a 12 car train with it. After that, he became QUITE fond of multiplicative factors.
Software engineering is in the cowboy stage that civil engineering was in in the 19th century. Until we've killed enough people, we'll probably remain in that stage. Really, the only question is when we'll reach that stage.