Anyone who has worked in IT knows about some shady practices here and there...and when it comes to databases many companies don't engage in much oversight. I suspect part of the problem is that the higher managers are distanced from the technological day-to-day and just assume that the nerds on the ground are taking care of things. I bring this up because today I had to resolve a problem with my cell phone provider. Apparently all my online administrative information was deleted when Sprint merged its databases with Nextel. This is a rather large corporation; you can imagine the sort of f*ck ups which occur lower down the food chain in smaller shops.
- Log in to post comments
More like this
By Kim Krisberg
Wally Reardon stopped climbing towers for a living back in 2002 due to an injury. He had spent years putting up communication antennas anywhere employers wanted them — smokestacks, buildings, grain silos, water tanks. Just about anything that rose up into the sky, Reardon would find…
Graduation was this morning, and it just so happens that I was the speaker. That I am posting the speech below should tell you that I thought it went pretty well. I'll do a separate post describing some of the reactions, and commenting on a few of the other graduation-speech related stories that…
All that stuff that the wireless industry says about being competitive is baloney! Cell phones in the US are big and stupid, and deliberately crippled to get you to pay extra for things that are natively supported in devices, like custom ringtones. And most Americans don't know any better…
On Sunday DailyKos frontpager, DemFromCT (who is also a founder of the FluWiki and a pulmonary specialist) finished up his two part interview with us. It's cross-posted here below the fold. If anyone doubted we were academics, the display of watching us argue with ourselves would have but those…
I'm a software developer, and I agree. Most people do just enough to not get fired. And even the few true craftsmen remaining in the field are often overridden by management. I think we need a culture more like the engineering world, where developers are certified and have a professional duty to not make moronic decisions or take part in dangerous actions.
when engineers make errors people can die. on the other hand, blue screens of death only cause frustration. i don't know...it seems that a lot of identity left is due to people not doing basic db security, but i think there's a psychological break on customers freaking out as they would if a concrete physical product broke down.
Ever hear of Therac 25? Look it up if you haven't. In short, a bug in a radiation therapy program resulted in severe radiation overdoses and at least five deaths. Even ignoring actual bodily harm though, software bugs cause plenty of damage to society. It'd be nice if we could reduce them.
Ever hear of Therac 25? Look it up if you haven't. In short, a bug in a radiation therapy program resulted in severe radiation overdoses and at least five deaths.
good point. but my hunch is that when a bridge collapses it is psychologically easier to comprehend that one engineer made an error. when software glitches occur which result in death i think the public has a harder time understanding that someone did a sloppy job in handling their memory leaks.
I was formerly a systems guy for the RI Sec of State's office before they laid me off. I made a prediction that exactly two months after I left there'd be a major catastrophe. There was.
Even though I'd warned them repeatedly and documented that the version of MySQL that lived on the web server had to have its indexes rebuilt at least once a month else MySQL would consume all CPU cycles and tank the Plone/Zope instance that served up web content.
Sure enough, two months later it happened. They fluffed the whole thing, said it was a rootkit, etc. I know for a fact it wasn't. They just never rebuilt the damned indexes.
They just never rebuilt the damned indexes.
right, a lot of this sort of theoretically basic stuff doesn't occur and that causes problems. the issue is that software guys aren't immune to cognitive biases...they put shit off cuz the shit hasn't hit the fan, and then when it does, well....
The problem is that with engineering a bridge there are well defined procedures and principles already developed. And there are finitely many points of failure. Software as an engineering practice is still pretty new. And, potentially every single line of code in a project is a point of failure.
I've worked in both engineering and IT. From my point of view the "problem" with software is its easy to make patch or load a backup. If you ship defective product or invest capital in a poorly designed production line (and we're just talking about stuff that doesn't work, not stuff that's dangerous), the cost of correction is large - you have to recall and scrap the product and replace it or rip out the old equipment and put new stuff in (which means shutting down the line too, which wastes a lot of man and machine hours in other parts of the line). Thus, things get throughouly vetted before they're implemented - at one place I worked, any change to production procedures or equipment had to be presented to and approved by a 5-person change management committee. Software does reflect the different cost of mistakes within the industry - the kind of calculation errors fixed in a typical WoW patch would be serious trouble if they were being made in e-prescribing software.
The other issue is that since the substrate of software is more or less free, adding more complexity to it is relatively cheap. Adding a configruation option to software is a lot cheaper than making a new version of a manufactured product with different specs.
Since the cost of adding complexity and making errors are low relative to manufactured products, software is more likely to have problems. This does seem to be a stable equilibrium, though - software that was more throughouly vetted would have less features and be more expensive - and for non-mission critical software, it's a tradeoff people are generally willing to make.
Never discount the Dilbert Factor!
PHB: "We need to merge the databases."
Dilbert: "But we can't, since there is overlap, and the two data sources do not contain any common unique value by which we can decide which rows to merge and which to insert."
PHB (who got lost at "data sources"): "Do it anyway. Have it finished by Friday." (thinks: "Dilbert and Wally can have the weekend to fix whatever problems they think there are, if they're so worried about them.")
I suspect that another issue is that it is much easier, particularly from an external(or worse, marketing) perspective, to evaluate and appreciate features than it is to do the same for "bugs that don't exist". Visible bugs are bad; but people are shockingly tolerant of them, as a rule, and are more likely to see them after the sale is already made. Hence you get pressure to add features rather than fix bugs.