Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Don't Shoot Me, I'm Only the Software

CmdrTaco posted more than 9 years ago | from the it's-really-the-hardware-guys-fault dept.

Software 392

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. "

cancel ×

392 comments

Irony (3, Funny)

Egonis (155154) | more than 9 years ago | (#10438603)

How ironic that MSN(BC) is pushing a story about 'don't blame the programming'.

Although legitimate in the concept, I would say that poor programming is most definitely a cause for system failures.

Re:Irony (2, Insightful)

BlueTooth (102363) | more than 9 years ago | (#10438647)

The occasional journalistic integrity of multpiple MS affiliated news outlets has bitten MS in the ass more than once.

Re:Irony (5, Interesting)

antifoidulus (807088) | more than 9 years ago | (#10438746)

I beg to differ. People seem to think that "coding" is the only important aspect of software. It's far from it.
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 /., 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.
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.

MS employees (5, Insightful)

BigHungryJoe (737554) | more than 9 years ago | (#10438834)

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

Re:Irony (4, Insightful)

Anonymous Custard (587661) | more than 9 years ago | (#10438897)

The talking heads at the top want a shitload of features, and they want it by an unrealistic deadline

Welcome to every single software project ever.

Re:Irony (2, Funny)

truthsearch (249536) | more than 9 years ago | (#10438939)

...but even good programmers aren't miracle workers.

"Damn it Bill, I'm a programmer, not a miracle worker!"

Sorry, couldn't resist.

Re:Irony (5, Insightful)

segmond (34052) | more than 9 years ago | (#10438765)

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.

Re:Irony (4, Insightful)

KDan (90353) | more than 9 years ago | (#10438928)

Yep. There's the same difference between software engineering and programming as between architecture/structure engineering and building construction. Doesn't matter how good the builders are, if the architect built a bad plan the house will fall down. To push all this planning stuff out of the responsibilities of the "programmers" is unjust on the managers, though. A good software engineer should be aware of the whole process and how it needs to be conducted and be able to advise his manager (if he's not a manager himself) on how to proceed. It's part of his job.

If the builders get given a plan where the roof is placed underneath the house, they should question it, not just build it blindly without asking.

Daniel

Duh. (1, Interesting)

darkmeridian (119044) | more than 9 years ago | (#10438782)

The planning and stuff hurts the usability of the program. The UI, the basis of the program itself. Sometimes, it could give rise to Internet Explorer's tight integration with the OS.

However, it seems to me that bad programming gives rise to buffer overflows and the like. These are more serious harms because they lead to the exploits. If you programmed well, you'd have a crappy program that would simply suck.

Re:Irony (5, Interesting)

iezhy (623955) | more than 9 years ago | (#10438820)

...contributed to the Sept. 14 radio system outage over the skies of parts of California, Nevada and Arizona.

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 :)

...the move went well except the new system required regular maintenance to prevent data overload.

wtf? the new system, designed to replace old one, was incapable to deal with data load? why would they "upgrade" it anyway?

Not really Irony (2, Interesting)

iconnor (131903) | more than 9 years ago | (#10438841)

Irony would be if MSN(BC) blamed windows. For instance, here they were saying that the problem with the FAA UNIX to windows migration was not software (windows) but the lack of testing and maintenance. They say that the system required regular maintenance (in windows I think this means rebooting) but I am sure there is probably more to it than that. However, I don't see that MSNBC is being Ironic - there is nothing anti-Microsoft or anti-windows that could be taken from this. In fact, it is right on the correct spin factor you would expect. Here they are saying the recent bad press associated with a public outage from a UNIX to windows migration was not a problem with buggy windows but a problem with management of the system.

Buck Passers (4, Informative)

mfh (56) | more than 9 years ago | (#10438604)

If you've been looking to blame your boss, this article from MSNBC says your ship has come in!

I think this little gem [dilbert.com] says it all. Strangely enough, it's today's Dilbert. Thing is, the buck-passers are who protect their own image or the image of those who write their cheques. The result? Too many projects are blamed on interns or programmers, rather than the truth coming to light.

Why? I think it's simple, really. Management often has no clue what they are doing in terms of managing a technical project so they make decisions about things like the exact features, and they often fight to get things a certain way -- unwittingly forcing programmers to code all the way around the block to get to the house next door, leaving problems in the wake.

The best case is when a programmer is given design autonomy. That's why Open Source is such a threat to large companies like Microsoft... because the guys who know what *can* be done, are the same guys doing it -- the result is 1111x better, and cheaper too.

I am so lucky to be working now for a company that allows me to have full autonomy with my projects. They tell me what the customer wants and I do it the way I think is best. Every single project done in this manner has resulted with happy customers and excellent systems.

Re:Buck Passers (3, Interesting)

MrRTFM (740877) | more than 9 years ago | (#10438713)

...unwittingly forcing programmers to code all the way around the block to get to the house next door, leaving problems in the wake

While I agree with you in principle and acknowledge that stupid managers are ... stupid; I dont buy this theory - a programmer should know to say 'this wont work', or 'this *might* work in the demo to management, but it WILL FAIL IN PRODUCTION IF MORE THAN 'xxx' USERS ACCESS IT'

Fuck - isnt it time we stood up and just told the truth - or are we all too scared of being outsourced to India?

Re:Buck Passers (5, Insightful)

bladesjester (774793) | more than 9 years ago | (#10438827)

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.

Re:Buck Passers (4, Interesting)

TreadOnUS (796297) | more than 9 years ago | (#10438850)

That does seem to be the case at I company I consult for. As a part of an assessment, we received several unsolicited comments that they would be resistant to changing the way they performed development because the business customer was free to outsource. And it's happened on a few projects when the development team pushed back on timelines and requirements.

As a result, the development staff here lies to their managers, who lie to their directors, who lie to their VP's and on up the line. This points to a breakdown in communication between all levels in IT including the lines between IT and the business.

Re:Buck Passers (3, Insightful)

Evangelion (2145) | more than 9 years ago | (#10438935)

As a result, the development staff here lies to their managers, who lie to their directors, who lie to their VP's and on up the line. This points to a breakdown in communication between all levels in IT including the lines between IT and the business.

This is not something unique to IT -- it's something fundamental to any command structure which relies on communication between unequals.

It's only common name is the SNAFU Principle [jargon.net] , which was coined by Robert Anton Wilson (there's a very good discussion of it in his book Prometheus Rising).

In Illuminatus!, a satirical study of social pathologies, Robert Anton Wilson and Robert Shea brought out an important principal that causes trouble in hierarchies: the Snafu Principle. People tend to say what they think the boss wants to hear, especially if they have noticed that the practice of ``shooting the messenger'' is common. This means that the information passed up the pyramid is distorted at each level. Thus, each higher layer of managers tends to have less and less contact with reality, and near the top they are often completely out of touch.

Re:Buck Passers (4, Interesting)

Mysticalfruit (533341) | more than 9 years ago | (#10438883)

I used to worry about that until my company tried an experiement and outsourced a project to india.

They fucked it up so horribly and it cost so much money that in the end they threw up their hands, wrote off about a million dollars worth of expenses and developed the app internally.

The internal developers (several of which were Indian might I add) finished the app on schedule.

Our company then passed an internal policy that we would insource (bring programmers in to work on a project) but that outsourcing was out of the question.

Re:Buck Passers (1)

halowolf (692775) | more than 9 years ago | (#10438741)

A project I worked on, that shall rename nameless to protect the guilty, was actually audited to discover the reason why it came in late and over budget.

Progammers (me and 5 other people) were found to have complied with the requirements and the software worked. We were not to blame. A bad customer (an internal customer who had not undertaken web development before, you guessed it a Marketing department trying to cash in on the dot-com boom!) was found to be the culprit with ever changing requirements and the inability to register trademarks requiring massive changes to the style of the site, once all the dynamic content programming had been done of course, in a time were there were not as many options as there is nowadays for dynamic content generation.

Re:Buck Passers (0)

Anonymous Coward | more than 9 years ago | (#10438794)

"They tell me what the customer wants and I do it the way I think is best."

That would be great except that half the time the customer doesn't know what they want. They know what they'd like a project to do (everything) and how much effort/money they want to put into it (none) but in the end, it comes down to the account manager to pry the information out of them and put it together in a sensible manner for the developers.

So, it comes back to management. I've worked with great account managers and some pisspoor ones and the bad ones have convinced me that project management makes all the difference.

Why does he have an aussie accent? (1)

tod_miller (792541) | more than 9 years ago | (#10438806)

Sport? So buck passers are Australian now are they? Streth shiela, didja here that? grab skippy and flipper, I am off croc hunting for the savo, they got me riled up, pass me a tinny, and put some prawns on the barbie.

MSNBC report that is isn't the softwares fault, but the person who wrote the software... erm... so this is Microsoft trying to make the masses docile again.

It isn't windows fault that it crashes, but erm, our, because, erm, we have poor planning, poor execution and poor leadership. But our code is top notch! not a security flaw any... where....

the result is 1111x better

The latest OSTG figure is 1111.9x better [sorry gotta be bleeding edge on stats]

Re:Why does he have an aussie accent? (1)

tod_miller (792541) | more than 9 years ago | (#10438829)

Strweth and hear.

why do I bother?

nuthing two sea hear. moove alloong. (-1)

tod_miller (792541) | more than 9 years ago | (#10438852)

s t r e w t h.

Buck Passers - Works Both Ways (1)

laetus (45131) | more than 9 years ago | (#10438906)

Having been on both sides (technical and management) I can assure you the truth is somewhere in between.

You're right in that often technical managers don't have a clue about the technology being implemented and often "manage what they know" and force programmers into coding inside a new platform using methods the manager once used in an old platform.

That said, I've often seen programmers (and network administrators, and DB admins, and ...) get a demo copy of a technology and run with it, proclaiming how the new software is close to the second coming, the manager looks at it and takes the word of the technical staff and voila, instant gulf in knowledge created.

Why? The manager's juggling two balls, one of learning (and actually) managing people and projects, as well as trying to keep up with the latest technology.

And as you move higher up the management chain, the less "hands on" time you have with the actual technology, and the gulf grows wider between what a manager knows (or knew) and the actual details of the technology they are being called upon to manage.

So, it does cut both ways. It's as much the programmers responsibility to "educate" the manager on new technologies as it is for the manager to "learn" them. Remember, managers don't have as much "keyboard" time as you do. Cut them some slack.

Re:Buck Passers (1)

qray (805206) | more than 9 years ago | (#10438949)

While I agree there are few managers that truly know how to manage a software project. There are few engineers that can really manage a large scale project. Open Source cheaper? It be interesting to add up all the donated hours. And then compare a comparable Open Source project with a similar commercial one. For me I've been really frustrated with lack of technical documentation on the open source projects I've dealt with. No requirements, no design, and lots of duplicated code. So in the end I think it's poor management of a project or lack of management that cause most of the problems and that's a global problem not just in the commercial realm.

D*mnd if you do and D*mnd if you dont (4, Interesting)

slashnutt (807047) | more than 9 years ago | (#10438610)

I have worked at CIMM [af.mil] level -3 and at CMMi [cmu.edu] level 5 groups. Starting at level 5, you're about as likely to win the lottery and while on the vacation at the moon than getting fired for bad software; at level 1 your highly likely to get fired for a bad programming mistake; level -3 you try to point the finger for anything.

Now there's a mathematical formula (let me see if I can derive one) for each level you go down, the half-life of bad software divided by the software engineer goes up a log base 10 (4 - 95%, 3 - 90%, 2 - 75%, 1 - 50%, 0 - 25%, -1 10%, -2 - 2%, -3 - .01%). Thus, if you want management to point fingers go down in levels but if you want the group to be aware of problems then look for a high CMM level group to work for. Disclaimer this is now way scientific but used as illustrative purposes; objects may be closer than they appear; no left turn on red; do not pass Go.

From the Horse's Mouth (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#10438611)

Must I point out that MSNBC wrote this article?

Re:From the Horse's Mouth (1)

dcphoenix (528517) | more than 9 years ago | (#10438807)

Don't you mean the horse's a$$? After all look at what comes out of each of them......

Ah, and of all sites MSNBC is saying this? (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#10438613)

Funny! ;-D

Yikes... (2, Funny)

Ionizer7 (814098) | more than 9 years ago | (#10438615)

This is a double whammy for Billy Gates, it's his software and he is the boss.

I'm masturbating furiously! (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10438616)

Seriously though, this topic sounds like mental masturbation to me.

Also... (1, Insightful)

Tuxedo Jack (648130) | more than 9 years ago | (#10438618)

The lack of robust testing during and after such a project likely contributed to the Sept. 14 radio system outage over the skies of parts of California, Nevada and Arizona.

As I recall, it also came from a tech who didn't do his job right in rebooting the machine that handled the software.

You can't always blame software; you have to blame the end-users too.

How do you fuck up a reboot? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10438651)

Huh?!? You just hit the freaking power button!

Re:Also... (3, Informative)

Anonymous Coward | more than 9 years ago | (#10438664)

The story was that windows had to be rebooted regularly or simply would stop working and reboot on its own.

Now of course you are right that some admin forgot the fortnightly reboot and that led to the problems, but I simply can't totally dispute the notion that a server OS that has to be regularly rebooted should at least take a share of the blame.

Re:Also... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10438686)

Uhh, right, because Windows would shut down after 49 days. So a tech failed to work around a completely retarded problem with the OS.

Re:Also... (2, Insightful)

Advocadus Diaboli (323784) | more than 9 years ago | (#10438721)

As I recall, it also came from a tech who didn't do his job right in rebooting the machine that handled the software.

So in other words the life of airplane passengers is depending on the fact if a computer is rebooted manually or not. Thank god nothing really bad happened during this radio outage, otherwise some smartass would have blamed it on the tech that forgot to reboot.

The main problem is obviously we're relying on systems and procedures that never have been tested under emergency conditions.

So far I was never scared to board a plane, but now I am. Especially after learning that air traffic communciation relies on something that I abandoned at home because of security reasons.

If someone is to blame, then the authority that gave permisson to run such systems without proper testing. The question still arising is if this will have consequences. AFAIK there were 5 incidents where the safety distance between planes was violated... shouldn't the FAA invstigate this and enforce procedures to avoid those sort of incidents in the future?

Re:Also... (1)

ajs (35943) | more than 9 years ago | (#10438749)

Speaking of blaming people, that particular example involved running an OS in production which was end-of-lifed over 3 (4?) years ago!

Re:Also... (0)

Anonymous Coward | more than 9 years ago | (#10438769)

Win 2000 server was end of lifed 4 years ago? Aha, if you say so.

This one is too easy. (0)

Anonymous Coward | more than 9 years ago | (#10438802)

But I still have to try.

Linux? Woops, my mistake. I forgot, EOL for Linux typically runs in the 12 month range.

Summary of article (2, Insightful)

wombatmobile (623057) | more than 9 years ago | (#10438644)

Big projects require organization or shit happens.

Uh, that's it. Thrilled?

Re:Summary of article (1)

ackthpt (218170) | more than 9 years ago | (#10438756)

Big projects require organization or shit happens.

Sometimes, when you look really carefully, you can see a project failing before the system has even been purchased.

I must say, though, that this whole concept is about 10,000 years old. Whether you are discussing building a system to manage personnel and finances or building a pyramid, you don't have a man-uh-ger waggle a finger at it and say, 'make it work'. I can remember instances where I laughed at the failure and where I nearly quit over the idiocy of the failure and it's always the manager to blame (got a bag guy on the project? take him off and replace him, that's what management is for.)

This is probably news to newbies in any field, but old hands, uh-uh.

MSNBC says your ship has come in! (1, Funny)

Anonymous Coward | more than 9 years ago | (#10438650)

Unfortunately, a bug in the ship's navigation software caused the ship to overshoot the dock, killing all programmers waiting for the cruise.

+1 Funny (-1)

Anonymous Coward | more than 9 years ago | (#10438795)

Where are modpoints when you need them?

Mod parent up +1 Hilarious :-)

And the net/net is... (2)

kinrowan (784107) | more than 9 years ago | (#10438654)

IT budgets are still shrinking....

Great.

Re:And the net/net is...A N D (3, Funny)

mr_z_beeblebrox (591077) | more than 9 years ago | (#10438942)

IT budgets are still shrinking....

We need to hire MORE managers.

mm (3, Interesting)

Anonymous Coward | more than 9 years ago | (#10438659)

Bugs and errors do not neccessarily mean BAD programming. Bad means that it sucks and it's of no quality level.

There may be minor flaws in things that an application relies on i.e. external code libraries or methodologies which have not been proven and tested.

Speaking of tested, how many coders here can testify that they are great programmers, but so many times have not been given appropriate amounts of time or resources to write something that works perfect.

That to me is not bad programming, because many times under these situations programmers do an amazing job of writing amazing code which actually works for the most part.

There's too many managers out there who like things to work 90% and say that the other 10% (which usually ends up being crucial to end users) can be dealt with after the initial release.

Management vs. Intelligence (4, Insightful)

TFGeditor (737839) | more than 9 years ago | (#10438660)

The more things change, the more they stay the same. I fought in the Brain Wars with management 30 years ago, and it was the same thing. The Powers wanted X, but system capabilities were Y. They did not want the issue confused with facts, they just wanted wehat they wanted, and wanted it yesterday. My peers and I coded it as close as we could, implemented it, and crossed our fingers. We kept the app running for about a week (with frequent bailing wire and BandAide patches), but the system eventually melted down due to data overload (fancy-speak for filled up the disk).

Management skated, two programmers fired.

That's why I raise cattle and write hunting articles these days.

Re:Management vs. Intelligence (1)

hsmith (818216) | more than 9 years ago | (#10438701)

Same issue for me. My boss slated the project for 3.5 months. the PM wanted it done in 1, with integration and testing. So we pushed through in one month. And of course the fingers were pointed at us becuase we 'didnt do a good job at testing' Then again, he also oversold the project to the client and promised things a web app couldn't deliver, but we managed to pull it out of our asses

Bullshit! (5, Interesting)

Tom7 (102298) | more than 9 years ago | (#10438668)

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.

Re:Bullshit! (1)

klang (27062) | more than 9 years ago | (#10438742)

...and a Windows machine isn't supposed to be able to run for 30 days without reboot anyway. It was a honest mistake on part of the programmer! :-)

Re:Bullshit! (3, Insightful)

JanusFury (452699) | more than 9 years ago | (#10438767)

I don't see what's ridiculous about performing regular restarts of a mission critical system. Would you rather have a a system that booted correctly this morning routing your flight, or one that booted correctly last year and may have its components functioning properly anymore? Do you think that people incapable of rebooting a computer every 30 days are going to perform regular maintenance and testing of electronic components? Do you think they're going to remember to fsck their disks every day?

I don't think so.

Re:Bullshit! (1)

DrSkwid (118965) | more than 9 years ago | (#10438907)


some institutions reboot the machines between jos !

luckily when you use [url:http://www.linuxbios.org] then such reboots take 10s so it's hardly an overhead, even the freebsd box in my car running from a CF card will boot to playing mp3s in 35s.

Windows truly sux0r5

Re:Bullshit! (0)

Anonymous Coward | more than 9 years ago | (#10438938)

35s is 150% longer than 20s

35s for Linux
20s for Windows

Re:Bullshit! (-1)

Anonymous Coward | more than 9 years ago | (#10438842)

AMEN!!!!!!!!!!!

IF THEY DIDN'T USE MICROSOFT SOFTWARE, they wouldn't need to hire some chub sit there and hit a button once a month.

Still poor planning (1)

brucmack (572780) | more than 9 years ago | (#10438867)

Perhaps the software was never designed to be used for that task, so it was still poor management? That's what I would guess...

If I make some application that's never intended to be used in a mission-critical, always-on setting, is it my fault if some administrator decides to use it for that purpose, with disastrous results?

Re:Bullshit! (2, Informative)

dfj225 (587560) | more than 9 years ago | (#10438872)

While you are correct that the Windows system needing a reboot every 30 days is a software problem, I think the article was speaking about the lack of testing -- especially the backup system-- that was also key to the whole system failing. That is just bad management. A system as important as this, should have been fault tolerant and tested on a regular basis. Sure there was a programming error, but the whole system could have been kept from going down through proper management.

Re:Bullshit! (1)

Karma Farmer (595141) | more than 9 years ago | (#10438917)

As I recall, the system in question has to be rebooted every thirty days, which is a software problem!

And it wasn't rebooted, which is a management problem.

Look, the system required a periodic maintenance task. That maintenance task wasn't being performed. Management had the option of spending resources to modify the system so that maintenance task was no longer nescessary, or of spending resources to make sure that maintenance task was performed.

They did neither. That's not a software problem.

Re:Bullshit! (1)

rve (4436) | more than 9 years ago | (#10438919)

Database servers are regularly rebooted or shut down to single user mode, because cetain kinds of database maintainance tasks cannot easily be performed on a running system, due to file- and record locking, so this is not necessarily a faulty assumption on the side of the software developer.

If regularly scheduled downtime is absolutely unacceptable, then maybe they chose the wrong architecture?

Constraints (4, Insightful)

johnhennessy (94737) | more than 9 years ago | (#10438674)

I beg to differ slightly.

Software projects seem to be primarily constrained by time/money which is usually controlled by management (read: boss)

If one wants to test software properly then you will need lots of the constraints (i.e. time and/or money). Just before a coder is testing his block, he/she will generally say something like:

"I'm finished the block, just need to test it a bit more"

Generally that is not what management will hear, they hear:

"I'm finished"

So they think "its ready". I've seen several first generation projects get hit by this problem (in commercial environments). In the IC design world (where its not generally possible to just flash the firmware to fix a bug) its accepted that at this point - i.e. primary design is finished you are only 50% of the way through. We spend at least half the time verifying the blocks. Management in IC design have accepted that this just as important as the implementation and so don't go off making wild assumptions.

So rather than just pawn off the blame onto your boss, it really is (partially anyway) your fault as well for not highlighting the fact that your block is not as tested as you would like it to be.

The philosophy of open source seems to limit the "its ready" effect to a good degree and hence the better code quality perception. When main stream commercial coding picks up the slack, it should get better as well. But generally a lot of these messes can be attributed to communication (person to person) failure rather than coder/boss failures.

Re:Constraints (1)

qwijibo (101731) | more than 9 years ago | (#10438886)

What about when you have told your boss several times that it's not well tested and the message they've already communicated is "it's done" which means "you're done"? The "it's done" message is pre-communicated in the form of project plans that are based on the least information that will ever be available about the project - what is available before the project gets justified and any time is allocated to it.

For the majority of the time I've been working for my current employer, I've been saying " doesn't have any technical problems. All of our problems are people." This article is articulating the same thing with better examples than I have.

Our next big project is a prime example of how people problems create what look like software problems. Our last solution came in on time with an extremely agressive schedule. We have a reputation now for being able to do whatever it takes to get the job done. Our next project is several times more complex. We have a general idea of what needs to be done, but no written or solid requirements at this point. We put together some really vague estimates of what needs to be done, which came out to over a year for our group of five specific people and two additional people. Management turned that into four months for three people. We've pointed out until we're blue in the face that this is completely irrational.

Many large companies foster this kind of environment where the people who can actually do the job have the least input on the job to be done. The reason the problem is poor management isn't because the little people never speak up, but because management doesn't value the input of their people.

Our next project's funding will come from next year's budget, which is being justified by all the different levels of management right now. However, the project was killed last month by decisions that ensure that the result does not meet the needs of the business. If it were even remotely possible to do what middle management wants done in the time frame given, the end result would appear to be poorly implemented software. Of course, it has to appear that the problem is bad software, because the only other conclusion on the table is the one that can never be spoken. Bad management.

It's really amazing... (2, Interesting)

TreadOnUS (796297) | more than 9 years ago | (#10438682)

how many large companies think that they can still be successful by programming their way out of problems.

If you work at a company that places some value on requirements and design development before you start cranking out code, consider yourself fortunate. And for those of you that have a consistent process for development and deployment, you're not that common either. There are still a considerable number of large companies with a presence on the web that rely on individual heriocs to keep their business running.

In most cases, it's management's reliance on a few people within development that keeps them from making any improvements. That and the lack of undestanding that spending some money could make (or save) them significant amounts of money.

Re:It's really amazing... (1)

toganet (176363) | more than 9 years ago | (#10438771)

I fear I may work for one of those large companies relying on individaul heroics -- and I am unfortunately one of the evil pointy-haired bosses. (Ok, it's more tousled than pointy).

It's easy to fall into that trap, too -- what I call "organizational ADHD". Too many projects and not enough resources. I don't have any say in 'personnel' decisions, or I would be posting a help wanted ad on Slashdot.

Hmm.... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10438683)

If you start blaming the programmers, they will lose there self-esteem and move on to other projects. There is only a small percentage of elite programmers that have rarely if ever made a mistake past the prototype stage. This small percentage of elite are not enough to write the programs for everybody. So if we sue/harass/fire all the non-elite programmers, how are we going to make up the deficit?

Re:Hmm.... (-1)

Anonymous Coward | more than 9 years ago | (#10438783)

Thank you for making me regret setting my threshold to 0.

Hmm.... (-1, Redundant)

GreyOrange (458961) | more than 9 years ago | (#10438688)

Hmm.... (Score:0)
by Anonymous Coward on Tuesday October 05, @09:50AM (#10438683)
If you start blaming the programmers, they will lose there self-esteem and move on to other projects. There is only a small percentage of elite programmers that have rarely if ever made a mistake past the prototype stage. This small percentage of elite are not enough to write the programs for everybody. So if we sue/harass/fire all the non-elite programmers, how are we going to make up the deficit?

Father of VMS and winNT (1)

linuxislandsucks (461335) | more than 9 years ago | (#10438690)

what does that say about the Father of VMS and winNT then or maybe Gates?

Poor? (1)

gmuslera (3436) | more than 9 years ago | (#10438691)

Poor planning, poor execution and poor leadership

... OR made by Microsoft. How Windows.* fails and/or is insecure deserves a new whole category for it.

Well, after all, was that company that started the culture that if software fails is something normal and just reboot, and popular culture attributes the problem to the software.

In the other hand, we use to think that software in Linux is so reliable (well, at least Linux itself) than if something fails, must be users or hardware fault, while that is not so true (again, at least for non linux-kernel software)

Fuck You Microsoft-NBC! (2, Interesting)

isaac (2852) | more than 9 years ago | (#10438695)

Dear Microsoft,

The fact that YOUR SOFTWARE shuts down after 49.7 days "to prevent data overload" is YOUR FAULT and BAD SOFTWARE DESIGN, no matter how much you use your pet news outlet to spin otherwise.

You're right about one thing, though. The FAA guys were idiots for deploying your software to replace an (eminently more reliable by all accounts) UNIX-based system. Call it a compound failure.

-Isaac

M$NBC says $oftware is Good! Blame the user. (5, Insightful)

twitter (104583) | more than 9 years ago | (#10438697)

"No really, it's a people problem, blame the user", they say. How lame can you get.

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.

Re:M$NBC says $oftware is Good! Blame the user. (2, Interesting)

Mikmorg (624030) | more than 9 years ago | (#10438924)

Being an actively-voiced anti-MS radical (quite obviously) like you are, I must insist that you take the following quiz:

1. Who most likely wrote the software?
A) Ground-breaking AI
B) People
C) Monkeys

2. A user always reads and follows instructions.
A) True
B) False

3. Windows' registry was designed for software protection.
A) True
B) False

4. Which OS is the most compatible with today's hardware market?
A) Windows
B) Linux
C) OSX
D) Other...

5. Name one piece of software that is perfect:
______________________

6. In windows, you can turn off a screen saver.
A) True
B) False

7. Microsoft _tries_ to make their code better.
A) True
B) False
Just curious as to a radical's answer sheet.

Please note that I chose linux over windows for my applications, but I still have an open mind, and am willing to use it for its purposes (yes, it does have its purposes). I am no radical either way as it is obvious that these operating systems each have their own niche. Even OSX, although I've never used it.

It _might_ be the code. (1)

noselasd (594905) | more than 9 years ago | (#10438698)

[noselasd@labsrv noselasd]$ flight_control
Segmentation fault

"Damn you, management!"

Re:It _might_ be the code. (1)

maxwell demon (590494) | more than 9 years ago | (#10438914)

A segmentation fault is never the fault of the software. Proof: If you would run the software on a system which doesn't have memory protection, you wouldn't get a segmentation fault. So, it's the choice of a platform with memory protection which is at fault. Ok, without memory protection the system might behave somewhat strange instead, but then it's again the fault of the management which decided to use systems without memory menagement.

You see, you can always blame it on the management.

umm.. (-1, Offtopic)

Chimmy Chonga (817689) | more than 9 years ago | (#10438699)

Don't Shoot Me, I'm Only the Post

From the article (1)

sczimme (603413) | more than 9 years ago | (#10438706)


Such disasters are often blamed on bad software, but the cause is rarely bad programming. As systems grow more complicated, failures instead have far less technical explanations: bad management, communication or training.

Really? So the buffer overflows, et al occur because people are not properly trained? I believe the buffer overflow is one of the more prevalent causes of vulnerabilities. The SANS Top 20 list [sans.org] text contains 24 instances of the word 'overflow'. Hmmm.

"In 90 percent of the cases, it's because the implementer did a bad job, training was bad, the whole project was poorly done," said Joshua Greenbaum, principal analyst at Enterprise Applications Consulting in Berkeley. "At which point, you have a real garbage in, garbage out problem."

Perhaps we need an additional step in here: garbage processing.

Hrm...Theres a problem here. (3, Informative)

Tyndmyr (811713) | more than 9 years ago | (#10438716)

I'll agree with many of the points here... All too often I or other programmers get handed some vague specifications and an unreasonable deadline for a project. Requests for more information usually get met with blank stares... And testing? Testing can take a nice chunk of development time, and its often the first thing to get cut when a project starts going late.

However, I do take issue with the following quote:

"Another common theme in failures lies in the ranks of employees who actually must use the systems. Often they're not given proper training. There's also a chance that they don't want the project to succeed, especially if they see it as a threat to employment."

Never give the credit so quickly to evil intent if you can chalk it up to simple laziness instead. I doubt many employees conciously try to cause software crashes, in comparison with the number who just dont have a clue what they're doing.

And, naturally, programmer error will always cause a certain amount of crashes...we are human too. Testings just a way of minimizing that.

One of the biggest problems (3, Insightful)

grunt107 (739510) | more than 9 years ago | (#10438724)

is that IT tasks have been highly compartmentalized - to the point where coders are actually versed in a limited set (or 1) coding language.

And coders cannot be designers, DBAs, or possess much business knowledge. Interaction with the end user is done with a 'business designer'.

As with the childhood game of post office, some of the information gets lost for every node in the SLCD (sftwr life-cycle design) chain.

One of the best fixes is to allow direct interaction of coder/end-user, and merge the designer/developer roles for a better industry understanding.

Re:One of the biggest problems (1)

segmond (34052) | more than 9 years ago | (#10438817)

I very well agree with your thoughts on the limited set of coding languages for most.

I believe every programmer should know at least a low level language C, C++ or Asm.

A dynamic language like Perl, Python or Ruby.

Our modern cobols, Java or .NET

A functional language, Haskell, ML or even Lisp...

I have never met a programmer who knows at least 1 of each from those categories who is a bad programmer. But I rarely trust programmers who can't code in more than one or two languages.

Re:One of the biggest problems (2, Interesting)

russotto (537200) | more than 9 years ago | (#10438863)

Most coders don't want to interact with the end-user, and aren't good at it either. Those who can understand their customer's business and do like interacting with the customer either become architects or sales engineers, thereby both making more money and outsource-proofing themselves. Or they become self-employed.

Biased View? (5, Interesting)

Araneas (175181) | more than 9 years ago | (#10438726)

"In 90 percent of the cases, it's because the implementer did a bad job, training was bad, the whole project was poorly done," said Joshua Greenbaum, principal analyst at Enterprise Applications Consulting in Berkeley. "At which point, you have a real garbage in, garbage out problem."

Translation: they didn't hire enough analysts

...said Bill Wohl, an SAP spokesman. "These projects require very strong executive leadership, very talented consulting resources and a very focused effort if the project is to be successful and not disruptive."

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.

WTF? (1)

http101 (522275) | more than 9 years ago | (#10438727)

Its not the software that goes bad, its my fault? You can only whip an Indian so many times before he starts writing hate comments into the code! Besides, whenever I write code and it doesn't work, I march right into my boss' office and let him have it! I tell him exactly what I think of his poor leadership skills and that my poor code-writing ability is his fault; not mine! That'll teach the lil bastard.

Hold on, are they are blaming the implementer? (1)

witcomb (636938) | more than 9 years ago | (#10438753)

I always thought it was the code that was the problem, turns out I just write poor code.

Well, no shit!

Was there ever a time the code was to blame? This is like blaming the newspaper, the actual peice of paper, for spelling mistakes.

Dilbert remains a documentary (4, Insightful)

russotto (537200) | more than 9 years ago | (#10438764)

From the article: "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,"

I used to think this. Then I realized that at least the developers knew one end of it -- they knew what the software can do. The other end, what the customer wants out of the system, is usually not known by anyone. Not management, certainly not sales, and not the customer either.

A customer with an existing system will often try to write requirements which amount to "do exactly what the existing system does in exactly the way it does it", which is not what they want or they wouldn't be replacing the system. Or, whoever is providing the business requirements will be so out of touch with their own business that the requirements will be incomplete or wrong. Or on the flip side they'll be so familiar with the system that they'll leave out things which are obvious to them -- but so obscure outside their field that no one on the software side will even notice the omission.

Of course, these problems will be discovered very late in the development cycle, resulting in a scramble to redesign and redevelop, a bunch of fingerpointing, mandatory overtime, and a host of other ills all of which lead to bad and buggy software.

Its not the software's fault, but lack of teamwork (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10438768)

"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, referring to cases where development takes place offshore.
This quote cuts to the heart of what is wrong with much software development. It seems to imply that if you simply hand the developers valid business requirements you are going to get good software.

No

You get good software from good teams of business people and developers. Every successful project I've been on has been successful because of a good team comprised of users, "business" people, and developers. Add to a good team a good software development process and you have a better chance of success.

True that (1)

gregarican (694358) | more than 9 years ago | (#10438844)

It is indeed a collaboration. An outside developer cannot step into a business environment and understand workflows and their operational requirements without the customer doing their job as well. So if something fails just as the success of something is shared so is the blame. Poorly conveyed requirements hand off to poorly constructed code which hands off to a poorly tested app which hands off to buggy or clumsy results which finally hands off to an unproductive business environment.

So this bluescreen of death... (4, Funny)

salvorHardin (737162) | more than 9 years ago | (#10438770)

...isn't actually the fault of MS programmers? In that case, given that leadership is one of the factors, then I can legitimately blame Bill Gates personally. So that's alright, then.

I don't know about you... (1)

Stoutlimb (143245) | more than 9 years ago | (#10438772)

But I just blame my employees!

Link to NIST study (2, Informative)

Skater (41976) | more than 9 years ago | (#10438778)

I've bitched about this before, but why can't news sites provide links to their sources? This is the internet, after all; we have the technology. It would take seconds, and obviously the journalist already has the information. Yes, I know I can search it myself, but I shouldn't have to - the supporting documentation should be provided by the person writing the article. (And, yes, I'm aware of the irony of saying that without providing a link. :) But I'm stating an opinion, not a fact.)

http://www.nist.gov/public_affairs/releases/n02-10 .htm [nist.gov]

--RJ

Of course! (1)

Dark Lord Seth (584963) | more than 9 years ago | (#10438781)

Poor planning, poor execution and poor leadership are more likely to blame than bad code when it comes to systems that fail.

Suppose I worked at a store where the use a cheap PC based POS ( Point of Sale, not Piece of Shit ) system that uses basic networking, a central database and the basics POS stuff with electronic payments handled externally. Sounds decent you say? The central database was an MS Access 2000 database, the basic networking meant that every cash register would have to use Remote Desktop to get into the "central" database. I doubted the system but because the store was small ( Just 2 POS ) and the Access database itself came across as stable enough. Mind you, we had to log in to Access and use and internally scripted GUI to access stuff. Horrible idea and I never know wether it was a success or not, I worked with that system for just two weeks or so.

However, the point is, that system was also available for larger stores. Now a store with 2 POS I can imagine. I'd guess the system would be decent enough for 5 POS as well, but anything above that would be ASKING for problems. In that case, the software can not be blamed, it is management who should have known better then to use Access related crap.

Never attribute to poor programming what can be attributed to irresponsible users.

Snippet on blaming the developers (5, Insightful)

Morpeth (577066) | more than 9 years ago | (#10438785)

"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"

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!

Business Process Broken (2, Interesting)

Karma Farmer (595141) | more than 9 years ago | (#10438816)

So, lets see if I can boil this article down to three talking points:
  • software projects are usually done in concert with business process changes,
  • business process changes are often poorly managed, and
  • the resulting problems are usually not due to software implementation issues
In other words, if you want your software projects to succeed, recognize that the management and executives are where a company's resources should be concentrated. The programmers are usually unimportant to the success of a project, and businesses can safely spend fewer resources on them without negatively affecting most projects.

it's a more complex issue (1)

recharged95 (782975) | more than 9 years ago | (#10438823)

Poor programming is due to management, customers, and people in general not taking into the consideration of both technical (design, impl, environment) and non-technical details (time, $$, politics, power). Then there's the problem of buy in by the developers: they desire a good design, otherwise mutiny occurs... In the end, it's a mutual problem.

Remember Mythical Man Month? [slashdot.org] . Again, another news org realizing the importance of stuff written light years ago.

(And CNBC had a slew of business folks yesterday saying how tech was "on the outs" again this year--and that it's construction, oil, and old econ that's en vogue. When your down, they just keep hitting ya...)

Also Reported In... (2, Interesting)

Kurt Wall (677000) | more than 9 years ago | (#10438831)

The Pittsburgh Post-Gazette [post-gazette.com] has a closely related story: Software disasters are often people problems [post-gazette.com] . Well, duh: "Garbage in; garbage out."

What I find really interesting is that this story, or various versions of it, while hardly "new," starts popping up on news sites all at once? It sounds like some organization is running a PR campaign, but it isn't quite astroturfing [catb.org] .

Re:Also Reported In... (1)

russotto (537200) | more than 9 years ago | (#10438899)

It's an Associated Press story. The various versions of it are the same story cut to fit different ad-holes.

Like /. Editors (0)

PetoskeyGuy (648788) | more than 9 years ago | (#10438832)

The software works great, but dupes, typos and bias are plaguing the system.

Lack of IT management training (1)

chiph (523845) | more than 9 years ago | (#10438846)

This article shows the results of a lack of career planning & training for managers in IT.

All too often, an IT manager is a programmer whose technical skills were weak or out of date, and so got pushed into middle managment. They then are responsible for making decisions that affect the success of the project. All without any additional training on how to be a manager. It's a situation just waiting for the Peter Principle [wikipedia.org] to kick in.

Everyone agrees that managing programmers is like herding cats, so throwing these people in there without any training or mentoring is just asking for trouble. Sometimes it results in money being wasted. In the case of an air traffic control system, it results in dangerous flying conditions and possible loss of life.

Chip H.

Nevertheless... (2, Insightful)

FunWithHeadlines (644929) | more than 9 years ago | (#10438861)

"Poor planning, poor execution and poor leadership are more likely to blame than bad code when it comes to systems that fail. "

Nevertheless, it's those poor planners, poor executors, and poor leaders who are in charge. You really think they are going to take the blame? No, of course not! It's so much easier, more fun, and better for your career to tell upper management that it was just the programmers who couldn't follow their instructions correctly.

Programmers will then get blamed, the poor managers will get a bonus for "correctly" identifying the problem, and corporate America will sail on as it always has: giving the big bucks to the managers and sales folks, while ignoring the programmers.

Who me, bitter?

time to marked, deadlines and rushed projects (4, Interesting)

klang (27062) | more than 9 years ago | (#10438874)

...that's the reason why bad code is written and why systems crash.

I have, time and again, been asked to cut corners in the design during the implementation phase of a project. The result is, that too much is cut in order to meet the deadline, another project sucks out key resources after the deadline and the product is rushed into production.

Everybody is happy until things start falling apart .. patch time!

44% of the employees (a couple of hundred) in my department are consultants , employed on a timelimeted contract. Some slam things together knowing they are not present when "patch time" starts ..

Bad testing, bad deadlines and rushed projects is the cause of a lot of evil!

Luckily, I can still express myself in the cvs comments and the random comments in the code :-)

Don't blame Mt Helen (1)

octal666 (668007) | more than 9 years ago | (#10438884)

just poor planning and a lack of leadership!

Bad management (1)

thepeete (189121) | more than 9 years ago | (#10438908)

They obviously mean Microsoft's bad management...

Speaking as a senior software test goon . . . . (4, Insightful)

alhaz (11039) | more than 9 years ago | (#10438912)

The article is a bunch of malarky. Well, I suspect it is, but i stopped after the first couple paragraphs, after I read this:

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.

Yeah. That maintenance they failed to perform? It was their mandated once-a-month reboot of their windows system, because it locks up after 43 days.

This was the result of bad programming.

Anyway, as a QA guy, I can assure you that bad programming abounds. It's my job to make sure you never see it. Part of that job is trying to drill into programmer's heads the concept that performing to spec when used as directed is not sufficient.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...