Slashdot Mirror
Don't Shoot Me, I'm Only the Software
ctwxman writes "How often have you heard about some massive crash and then the blame was placed on the software? "Disasters are often blamed on bad software, but the cause is rarely bad programming." If you've been looking to blame your boss, this article from MSNBC says your ship has come in! Poor planning, poor execution and poor leadership are more likely to blame than bad code when it comes to systems that fail. "
The article cites as an example,
Last month, a system that controls communications between commercial jets and air traffic controllers in southern California shut off because some maintenance had not been performed.
As I recall, the system in question has to be rebooted every thirty days, which is a software problem! The very fact that there were ridiculous procedures to fail to carry out is due to the poor software in the first place.
Sorry Microsoft, it's the software. When I go to the local airport and see a kiosk displaying a Windoze 2000 screen saver instead of information, something is wrong with the software running the kiosk. I'm sure that the kiosk owner followed all of the directions given and the stupid thing did not work anyway. A box that has to be restarted once a month and crashes when it's not has a software problem. Having two of them will simply multiply the problem by a factor of two.
How am I so sure that software not people are to blame? It's easy, I started using non Microsoft software and most of my problems went away. I've got the same old hardware, it just works better under Linux. It does more for me too.
Why is that? It might be that there's no nasty registry that's designed to keep me from "stealing" software. It might be that sane networking models really do eliminate most problems with worms and viruses. It might be that free software really works to make better code. Who cares?
The bottom line is obvious. No amount of blame shifting will change it.
Friends don't help friends install M$ junk.
Translation: they didn't hire enough analysts
Translation: They didn't hire enough consultants from SAP.
"Developers are least qualified to validate a business requirement. They're either nerds and don't get it, or they're people in another culture altogether," said Michelsen,...
Translation: It's not our fault the developers couldn't understand our brick of a business case.
Another common theme in failures lies in the ranks of employees who actually must use the systems.
Translation: It's not our fault the interface sucks - it's the stupid users too dumb to adapt to our software.
I beg to differ. People seem to think that "coding" is the only important aspect of software. It's far from it. /., MS does not hire idiots to write their code, but even good programmers aren't miracle workers. When they have their hands tied with a looming deadline and a feature list that only grows longer, they can't do it all, and bugs are bound to sprout up.
Case in point, MS Windows. I actually read a book on programming security from the head of security at Microsoft(yeah, laugh all you want), and it gave some interesting insight to the corprate culture at Microsoft. The talking heads at the top want a shitload of features, and they want it by an unrealistic deadline(which, with the exception of longhorn, they almost always meet), and security gets pushed to the back, and maybe only added in as an afterthought.
Contrary to popular belief here on
I think Linux main security advantage lies not in that almost anyone in the world can look at the code(though that helps) it's that there is no "mono culture", you get a lot of interesting ideas contributed to the kernel, some are good, some not so good. Eventually the bad ideas fade away and you are left with a very solid operating system.
Monstar L
good programming is not enough to prevent system failure. good programming is good for your homework project or a little module.
good software engineering is required for large systems. when you are developing hundred thousand lines of code to million lines of code. no amount of good programming will guarrante a good system without solid software engineering processes.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
Not surprsing that a CEO would make this remark. I can't count the times I've asked the business community I'm working with for clarification of a business rule or requirement, and then get a 'sigh' or other look that says - "I'm too busy to worry about this".
And on the contract I'm working on now, they consider a 30 min phone meeting enough information to build a full blown app - trying to get documentation is like pulling teeth. And of course we know where the finger will be pointed if there's any issues.
To say we're nerds who don't "get it" is just an asinine, condescending remark; a) I'm perfectable able to learn about the business involved, b) If you explain the rules properly most developers I know have no problem at all coding the solution. I find most of the developers I work with brighter than the business community they're working with. The CEOs remark has a dilbert-like quality to it imo, and this guy's one of the 'experts' on the problem in the article... ha!
'The unexamined life is not worth living' - Socrates
...contributed to the Sept. 14 radio system outage over the skies of parts of California, Nevada and Arizona.
:)
...the move went well except the new system required regular maintenance to prevent data overload.
The genesis of the problem was the transition in 2001 by Harris Corp. of the Federal Aviation Administration's Voice Switching Control System from Unix-based servers to Microsoft Corp.'s off-the-shelf Windows Advanced Server 2000.
they violated the golden rule: dont touch the system if its working. and they were punished
wtf? the new system, designed to replace old one, was incapable to deal with data load? why would they "upgrade" it anyway?
That works really well in theory. The problem is when management looks at you and tells you to do it the way they said anyway because they're in charge and you aren't. I've run into that a few times in the past. The fact that the IT manager was an idiot and thought he was an authority on the subject because his wife was a programmer didn't help.
Everything I need to know I learned by killing smart people and eating their brains.
Contrary to popular belief here on /., MS does not hire idiots to write their code
Amen to that. I don't know where this idea that MS doesn't hire skilled people to design and develop software came from, but it's wrong.
It has always appeared to me that MS hires top students from the very best schools.
bhj
. . .a programmer should know to say 'this wont work'. . .
Programers, at least the good ones, know how to say this, and say it loud and often. Likewise, the true professional salesmen who have actually studied their craft know how to say "This promotional technique of yours has actually been proven in study after study to be a pointless waste of time." The cabinet builder knows how to say, "That joint will fail." The day laborer knows how to say "If you really insist I do it that way you'll get less real work per day out of me and I'll be out on comp in six months."
Managment knows how to say, "I'm sorry, but our policy is. . . "
They're often very good at saying it, because they get a lot of practice saying it, instead of practicing how to listen to the people they've hired because they possess certain special skills and knowledge.
Engineers know how to say, "The Space Shuttle will blow up if you launch below a certain temperature."
It turns out they were right, but managment followed policy.
Managment's solution? Fire the engineers for speaking out.
So long as you work for managment that views its role as telling you what to do, and your role to just shut up and do it, actually doing your job the way you percieve it as an expert is simply a short walk to the unemployment line.
Once upon a time my mother was the manager of vehcile registration renewal for the NYS DMV. Her superior walked into her division one day and found her cleaning a microwave oven.
"Do you think we pay people at your grade level to clean ovens?" he asked her.
"Everyone of my people is working on production, in the only profit making division of the state government. Do you want me to stop one of my people from making money for the state just to clean an oven when I've really got nothing better to do right now myself?"
Fortunately for her, after a moment of reflection, he actually got it and replied, "You know, I never thought of it that way before. I guess sometimes we do pay people at your grade level to clean ovens."
Both he and my mom are fairly rare examples of managment. Managment serves the purpose of making sure the secretary has paper clips when he needs them, the assembly line workers have bolts when they need them, and to gently nudge people back on course if they should happen to stray a bit from the path, not "tell them what to do."
But somebody has negelected to tell most of the managers that.
KFG
One major thing that comes inbetween coding near-perfect software (Perfect software is never going to be possible) is also the demand the customers place on the team.Of course, they know very less about the technology and so cannot blame them totally.
/. stories
In India, software companies treat the customer as God accepting his/her unreasonable targets.. I wouldnt blame the customers alone for it... the managers too are responsible. They agree to whatever the customer says even though the actual development team asks them not to. And then, the normal work timings stretch to 10 AM to 3-4 AM next day... Now, anybody think anyone can write quality code when they are working this timing??
Well, the only advantage that comes here is that we get to read all the
This is why Free Software tends to be more secure. The project managers tend to be programmers, not non-techy businessmen. They understand the concepts of "still needs work" and "not ready yet" even if a product is late. Commercial software vendors would rather release a program on time and hide any last-minute security flaws that pop up (to be fixed in some patch, which is perhaps another profit generator). Open Source projects, lead by the programmers themselves, will usually prefer to hold back a new version if they feel it's not reliable enough for release. Besides, that's what developer versions are for.
If it weren't for fog, the world would run at a really crappy framerate.