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

Comments

Irony

[Egonis]

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

[BlueTooth]

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

Re:Irony

[antifoidulus]

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.

Re:Irony

[segmond]

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

[iezhy]

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

Re:Irony

[Anonymous Custard]

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

[KDan]

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

Re:Irony

[truthsearch]

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

[Anonymous Coward]

The occasional journalistic integrity of multpiple MS affiliated news outlets...

Will you people ever get off this silly juvenile crap? MSNBC and Slate have never demonstrated anything but complete editorial independence from Microsoft, and they (and MS) deserve credit for it, instead of constant sneering from the audience at VA Linux's propaganda mill.

Re:Irony

[maxwell demon]

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.

No, not every software project. The typical deadline for open source software is "when it's ready". Which often isn't an unrealistic deadline. However, the shitload-of-features problem can happen there, too (and is usually the main reason if "when it's ready" gets unrealistic).

Re:Irony

[micromoog]

It actually seems to be pretty regular integrity . . . wasn't Slate just recommending Firefox to people?

Re:Irony

[mwood]

"Many eyes" is good, but it's the scheduling disaster that works against producing solid designs and solid code in the first place. Linux vN+1 ships when Linus thinks it's ready, not to meet some marketing manager's fantasy deadline. Shipping software when it's ready, not when someone who hadn't a thing to do with making it wishes it would be ready, cannot be overvalued as a component of software quality.

Re:Irony

[BrokenHalo]

MSNBC and Slate have never demonstrated anything but complete editorial independence from Microsoft...

Never ever?

Perhaps you haven't been paying attention. Even Diogenes, living in his barrel, paid more attention to the world than that.

Re:Irony

[horrens]

what a wonderful world it would be without clients
but unfortunately they are with the money

Re:Irony

[ahdeoz]

Actually, the reason Linux security is better than Windows is because of design. Linux has a much simpler design that was based around files, multiple users, and networks. Windows has a complex design that is a kludge of multiple different systems that was originally meant as a single user, non-networked, floppy disk driver.

Buck Passers

[mfh]

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

I think this little gem 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

[MrRTFM]

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

[bladesjester]

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

[TreadOnUS]

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

[Mysticalfruit]

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

[Evangelion]

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

[kfg]

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

Re:Buck Passers

[Evangelion]

The other problem is is that this type of 'message modification' can be done unconciously, from choice of words and adjectives, 'forgetting' to mention bad news, and even body language. Even subtle moderations can have an impact in a large heirachy.

It *is* possible to fight this, but what you then have to do is have a manager and the people they manage feel and act like equals. If there is no fear of reprisals for bad news, and no fear of reprisals for honest mistakes, then the quality of the communication within the organization will rise.

Really, the solution is to try and structure your organization as something other than a pyramid. You don't need to run an organization with a single "alpha male" at the head, and everyone reporting indirectly to that person or board. But that seems to be the cultural norm in western society.

Re:Buck Passers

[DavidTC]

You know, you can tell what 'managers' and 'supervisors' are supposed to do by looking at the word.

Supervisors are supposed to watch. And presumably do something if they notice something wrong, like employees hanging out in the break room for six hours straight.

Managers are supposed to manage people and things. Manage doesn't mean 'control', it means 'watch and direct'. They're supposed to watch paper clips and direct them towards a purpose, they're supposed to watch employees and direct them towards some purpose.

There's a reason we don't have 'controllers' or 'directors'. (Well, unless you're a spy or in a theatre, in which case those actually do means 'someone who controls you'.)

Interestingly enough, I can't figure out where 'boss' come form, only that it also means 'knob or protuberance', hence 'emboss'.

Re:Buck Passers

[DavidTC]

And the theatre point reminded me of something:

While building a show, you have a director who basically controls everything and everyone. He says 'stand here, put that there, turn that light down'. (He hopefully delegates some of that.) This is how some bosses seem to act...but they're managers, not directors.

When the show is ready to open, he's built everything exactly how he wants it, and he then turns it over to the stage manager, who then proceeds to, hopefully, do nothing except call out 'Okay, do the next thing on my mark. Mark.' repeatedly.

Of course, as we're talking about something that, no matter what anyone does, seems to repeatedly involve actors, said stage manager will spend a good deal of time locating them. Or something equally silly, like lighting system tripping a breaker, the curtain failing to operate, or a fly that won't fly.

So, by analogy, the board of directors of a company should 'build the show', and then hire managers to make sure things keep running.

Re:Buck Passers

[kfg]

Interestingly enough, I can't figure out where 'boss' come form, only that it also means 'knob or protuberance', hence 'emboss'.

It is originally New York State slang, which was previously New Holland, the majority of the population remaining of Dutch descent for nearly 100 years after the British took over administrative control of the territory (with a French majority in the Adirondacks). It comes from the Dutch 'baas', meaning 'master.'

Oddly enough, the 'boss' meaning 'knob or protuberance' comes from the French 'boce,' which can also mean to beat to produce a swelling.

I don't have a reference handy for the Indo-European root of these words, but my sense of the sardonic suggests to me that these two words share the same root.

KFG

Re:Buck Passers

[fishbot]

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.


But this is also a problem. I've had so many managers who took the approach 'well, it didn't work once so it is now policy that we never, ever do it again' that it ends up biting you in the ass.

My last manager (I quit 2 weeks ago, yay me!) decided that software unit testing was fundamentally bad, because he'd tried to manage a project using XP (eXtreme Programming, not.. oh you know) and that uses unit testing and it didn't work very well. It became policy that we should never do unit testing. I kid you not.

Creating a policy to never do something that didn't work the first time is as bad as not trying it in the first place.

Re:Buck Passers

[Evangelion]

Good point. But at least they were trying :)

I think it more has to do with how people behave in thier organization rather than the formal org tree. The problem really isn't the formal-on-paper organization, it's the way people interpret that and behave that.

The companies that I've worked in where the org chart was printed out and on everyone's desk, and everyone knew the pecking order were not nearly as positive as the places I worked where they recognize that they have to have a formal organization chart, but really just treat it as a nessecary evil.

When you focus on who is above and who is below you, you start to live the dominant and subordinate roles that they imply. If you treat them as simply another thing that has to be documented, then you don't end up falling into the above traps where you are afraid of the people above you, and where your subordinantes are afraid of you.

Which goes back to Wilson's point, which is that true communication is only possible between equals -- while you never may be on equal ground with your boss, if you're hanging org charts all over the office, that will simply reinforce the belief that you are not equal, and cause the organization to fall into the above trap (faster, anyway).

Re:Buck Passers

[mwood]

I'd like to suggest that the problem with hierarchies is that people often get the idea that one's position in the hierarchy says things about what it's someone else's job to do, but not about what it's my job to do. All those people closer to the leaves than I am (as if there were any!) are depending on me to get them good useful work and the resources with which to do it. Every edge indicates *two* bundles of claims: mine on him, and his on me.

I was somewhat enlightened years ago by the suggestion to turn the org chart upside down, so that we see the CEO at the bottom supporting everyone. The only people *not* in a supporting role are the workers who actually make or do things wanted by customers.

Re:Buck Passers

[ACPosterChild]

In the past, I worked for a contractor who had to deal with another contractor to complete a project. The real workers who knew the parallel contractor did shit work scored them in certain areas as "major negative" (the 2nd contractor said that a deliverable was in the mail for 2 years; *literally*, that's not a figure of speach). By the time the review made it through all the levels of management, with each thinking "aww, they couldn't have been *that* bad", and "what will happen to me if my boss finds out that I hire people that suck", the rating became a "minor plus". Nearly ALL of the ratings were bumped up at least a few notches.

D*mnd if you do and D*mnd if you dont

[slashnutt]

I have worked at CIMM level -3 and at CMMi 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.

Re:D*mnd if you do and D*mnd if you dont

[sscanf]

Errr... I got lost when we divided by the software engineer but:

I have done CMMI and I am not a fan of heavy process done in the heavy handed way CMMI is done. Its a great way for extra levels of management to justify themselvs. That much said, CMMI does ask developers to do important things (and don't quote me, this is just what it means to me):

1. Coding standards
2. Unit testing (automate it!)
3. Peer reviews
4. System testing

CMMI makes you do all of that and document it. The paperwork is over the top but the result is better software.

The big winners are having unit test code that aims for 100% coverage and real peer reviews (the many eyes approach). The peer reviews can be initially painful but everyone learns their bad habits quickly and soon gets out of them.

The downside is that it comes with a whole crew of managers, inspectors, auditors, validators, finger pointers, and beurocrats who are working hard to justiy their existance by beating up the developers and their code as much as possible.

In the end, it all comes down to common sense: plan what you are going to do. Do it carefully. Test it. Ask your peers to review it and learn from their comments. Put it all together and test it again. Remember your problems so you don't repeat them.

Summary of article

[wombatmobile]

Big projects require organization or shit happens.

Uh, that's it. Thrilled?

And the net/net is...

[kinrowan]

IT budgets are still shrinking....

Great.

mm

[Anonymous Coward]

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

[TFGeditor]

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:Also...

[Anonymous Coward]

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.

Bullshit!

[Tom7]

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!

[JanusFury]

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!

[dfj225]

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!

[241comp]

Have you considered the possibility that the 30-day reboot cycle is supposed to ensure that if they were to experience a crash or something that the system would be able to reboot? I mean, there are plenty of people (probably even here on Slashdot) with servers that have been up 5-7 years but if they have to reboot for some reason, what are the chances that the system will have problems coming up? Many hardware faults are discovered at boot (the stress of boot brings them to a head).

Constraints

[johnhennessy]

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.

It's really amazing...

[TreadOnUS]

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.

Fuck You Microsoft-NBC!

[isaac]

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

Re:Fuck You Microsoft-NBC!

[TrancePhreak]

Way to troll doofus.

The 49.7 days refers to stuff that is not based on Windows NT. IE Nothing to do with the system deployed that was Windows 2000. Second, the versions of Windows that are built this way do not require rebooting at this period, an internal timer turns over and the system continues on as normal. The programmer who designed the system for the FAA msut not have RTFM or designed it very poorly to require this.

M$NBC says $oftware is Good! Blame the user.

[twitter]

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

[Mikmorg]

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.

Re:M$NBC says $oftware is Good! Blame the user.

[killjoe]

The real problem is that software marketing WANT the blame. Microsoft repeatedly says that when open open source goes wrong you don't have anybody to call.

If you build an entire campaign around "you know who to blame when things go wrong" then you can't whine when people take you up on it.

Hrm...Theres a problem here.

[Tyndmyr]

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.

Re:Also...

[Advocadus Diaboli]

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?

One of the biggest problems

[grunt107]

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

[russotto]

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.

Re:One of the biggest problems

[dillon_rinker]

PRECISELY!!!

You've hit the nail on the head, thought I didn't realize it until I read your comment. The HARD part of programming is dealing with the people. Everything else can be understood logically, which is easy, but dealing with people is an irrational process. Anyone can find the square root of 8 (ie write code) but not everyone can find the square root of an apple (dealing with people).

Biased View?

[Araneas]

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

Dilbert remains a documentary

[russotto]

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.

Re:Dilbert remains a documentary

[GileadGreene]

Part of the problem is that no one is really trained (or more correctly, educated) in how to develop requirements. Good requirements define a problem to be solved, rather than specifying a solution. Which makes sense, since adequately defining a problem is the first step towards solving it. But people son't want to think about the problme they are trying to solve, or spend time exploring the "problem space", they want to jump straight to a solution. Often their "definition" of the problem consists of a statement of the desired solution.

One approach to minimizing the tendency to state soltuions that I've seen promulgated in a few places is to tackle requirements definition from a different perspective. Rather than expressing requirements in terms of "things the system must do", write them in terms of "problem symptoms that must be suppressed" (i.e. "what do I want to chnage about the current system). This isn't a panacaea, but it does seem to help get people thinking in the right direction.

The fundamental problem, of course, is that problem-definition is just one component of the larger skill of problem-solving, which just doesn't seem to be taught at all any more. Most schools seem to focus on "training" and cookbook solutions (which is what most students seem to want too), rather than on "education" and problem-solving skills. It's particularly annoying that problem-solving skills aren't taught to management types, since (to me at least) a large portion of their job is supposed to about identifying problems (in resource allocation, scheduling, market strategy, inter-personal dynamics, etc), and solving those problems.

So this bluescreen of death...

[salvorHardin]

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

Link to NIST study

[Skater]

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

--RJ

Snippet on blaming the developers

[Morpeth]

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

Re:Snippet on blaming the developers

[Morpeth]

That's a very common problem unfortunately. I've been a developer for ~10 years, and I still run into it all the time, especially the part of business rules being added/changed once the project is done or nearly done.

Being a junior developer is irrelevant your problem - if you have a good PM, hs/she should be willing to go to bat for your team, and demand functional and technical specs as needed. If not the project will be in jeopardy. If the PM does ask for requirements and doesn't get them, at least it's a CYA situation - and they can say look "get me the info the team needs, or I can't promise what will be delivered"

When you have a PM who isn't willing to do that you're bound to get screwed. Best thing to do is document all your requests for information, and tell the PM, if you want this to project to succeed, like it or not - I need information "x" and "y". If the project is a crash and burn, you can say you did what you were able to provided the information that was given to you - and you weren't given all you requested.

Any company-organization that considers you and 'idiot' for wanting clarification is looking to burn money on a failed project and/or happy to waste resources on lots of bugs fixes and patching. They should look in the mirror before viewing others as idiots.

Re:Snippet on blaming the developers

[Morpeth]

I've done f/t perm and contract work. I have zero problem leaving those kind of environments, and do. I find large companies are the worst for organizational problems.

I agree with you than in an ideal world you could go to management of some sort and get the situation fixed. But in my experience, esp as a contractor, it's usually an uphill battle not worth fighting if it's problem with the company's culture.

If the culture is screwed up, I politely decline a contract extension when the time comes. My job is to design and code, not fixed f*cked up management. I had one 3-month contract where I had 4 different managers in that timeframe, due to political power plays and all kinds of crap, there's no way to as a contractor to correct that kind of situation in that timeframe.

When I was wet behind the ears, I used to try, but it was an exercise in futility, so now I don't bother. I certainly will ask for what I need, but if I can't get it - I just document my requests, cover my a*s, and move on when the time comes.

Business Process Broken

[Karma Farmer]

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.

Also Reported In...

[Kurt Wall]

The Pittsburgh Post-Gazette has a closely related story: Software disasters are often people problems. 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.

MS employees

[BigHungryJoe]

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:MS employees

[pjt33]

Of course, being good at CS doesn't necessarily make you a good developer.

Re:MS employees

[poot_rootbeer]

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.

That's not a Good Thing. Very few 21-year-olds, even those who got the best grades at the best schools, understand software design or business process well enough for a major company to be able to rely on them.

Real-world experience is an important factors in successful design, and it's something that can't be taught in a school.

As smart as each new class of new direct-from-school hires might be (and I've known several, and they were all brilliant), Microsoft would probably generate higher-quality software if they hired 35-year-olds with a dozen years of experience at other successful software companies instead. Of course, it's going to be harder to find 35-year-olds willing to work 60-hour weeks in return for $45 grand, a free bike, and all the soda they can drink...

Re:MS employees

[eam]

At MicroSoft.

Re:MS employees

[Anonymous Brave Guy]

Very few 21-year-olds, even those who got the best grades at the best schools, understand software design or business process well enough for a major company to be able to rely on them.

I seem to recall a study, by IBM possibly, into how much young developers really contribute to software projects. The conclusion was that most of the young starters (up to age 25 IIRC) were only good for writing docs and possibly testing. You shouldn't let them near the code, because in the balance of probability, they will be counter-productive overall. Those up to age 30 were found to handle development on a single, focussed project usefully, but no more than that. Those over 30 could handle working on multiple areas at once competently.

Those figures are all from memory, but I'm pretty sure they're close. They're also a pretty damning indictment of the age discrimination that is rampant in the software development industry, and a fairly compelling explanation for why so many projects fail after the management choose to hire youngsters because they're cheap and willing to do whatever to advance their careers...

Re:MS employees

[Anonymous Coward]

That's not a Good Thing. Very few 21-year-olds, even those who got the best grades at the best schools, understand software design or business process well enough for a major company to be able to rely on them.

How is that still not a Good Thing? You start with someone who is smart and you teach them how to be a developer. MS is all about employee retention, so over time, they have not only smart employees, but ones with solid experience.

And by the way, they don't toss newbs right out of college right into major development roles.

Let me guess, who weren't one of those who got the best grades at the best schools.

Re:MS employees

[dmatos]

Hence the importance of a good co-op program (or internships, as they are called in the states, iirc). The University of Waterloo Engineering and CS programs take 5 years to complete, with no summer breaks, but by the time you finish, you've completed six 4-month co-op terms, with real employers, doing real jobs, in the real world (and usually for real money).

Several of my friends spent their co-op terms at Microsoft, starting out in testing, moving up to code monkey, and by the time they graduated and were hired (with 2 years cumulative experience), they were offered jobs as project managers.

My first co-op job was in IT. I very quickly figured out that it was something I did not want to be doing for the rest of my working life. Then it was on to software, which I also didn't enjoy that much. By my 4th co-op term, I landed a job at a hardware design company, and haven't looked back. I graduated with 1 year of hardware design experience, and now happily work at my job designing image sensors.

To anyone out there considering post-secondary education, I heartily endorse programs that allow you to get real-world experience before graduation. Not only does it help you figure out if you're going to like it, and get you the experience that gives you an edge up on your resume, you'll often find that it will almost pay for your schooling too.

Not really Irony

[iconnor]

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.

Nevertheless...

[FunWithHeadlines]

"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

[klang]

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

Speaking as a senior software test goon . . . .

[alhaz]

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.

Re:And the net/net is...A N D

[mr_z_beeblebrox]

IT budgets are still shrinking....

We need to hire MORE managers.

Considering you deal with users who...

[jasonmicron]

Considering that you deal with users who don't really know what they are doing in the first place I would have to place the majority of the blame on them. However you could also retrospecitvely place the blame on IT for not having the systems locked down in the first place but then you would have to blame the CEO and the board for not putting more technology in the budget. Yea we won't go there.

Article is basicly right

[bitswapper]

They bought a Yugo (windows) to do the job of a truck (UNIX). The Yugo needed more maintainence than the truck, and they had an accident. They fired the 'state of the industry' execs who decided to replace trucks with a Yugos. This is actually good news, in a way. Now all they need to do is get the trucks back.

Hmm... I wonder if the execs running nuclear power plants have finished installing windows to run them....

Better yet, we can put windows in charge of the ICBM fire control systems. We'll be *so* state of the industry.

I hate smoking software problems

[magarity]

Last week, my WinXP box locked up in the middle of a game. It was so bad, smoke poured out of the case. The software, probably WinXP but maybe the game, had overused one of the RAM modules so hard that two of the leads were charred black.

%^$#@& SOFTWARE!!!!

UI and errors

[Southpaw018]

I've always wanted to design a system that gets nastier every time a user repeats an error.
In the generic sense, it would start with "Could not do xyz. Please check what you intended to do and try again."
Then, it would progress through "I can't do that. Try again." "You're starting to wear on my nerves. Can't you do anything right?"
Then, it would start to get more down to the source of the problem, beginning with "DOES NOT COMPUTE" and ending, finally, with "You fucking moron, my program works, read the manual before i cut you."
Stupid users always bothering me with crap.

Re:Also...

[Clover_Kicker]

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.

Let's do a little thought experiment:

So in other words the life of airplane passengers is depending on the fact that technicians regularly change the oil in the airplane's engine or not. Thank god nothing really bad happened during this problem, otherwise some smartass would have blamed it on the tech that forgot to change the oil.

Sure, it sucks that mission-critical kit needs to be rebooted. But everyone knew about the constraints, there's no excuse for not doing required maintenance that everyone knew about.

you get what you pay for

[ximpul1]

im surprised i have not come across any outsourcing replies. i understand that the article and summary are about more timeless folleys but when a business outsources a communication gap opens up and that whole team unity thing gets affected "and teams need that shit" (-tycho form PA)

from tfa: "It becomes a major role of (management) to kind of herd the cats in and make them all line up in a reasonable way," said Barry Wilderman

yea its becomes much harder when you have to work with people who not only have bad communication skills but may not know the subject matter.

(sarcasm) enjoy the saved cash you paradigms shifting fucks

let alone the fact that many times you dont know if your getting someone who has made 10 hello world programs and count themselves as a pro in each.

ah and the images in tfa of people holding each other watching their software fail was priceless.

Customers & managers

[vinukr]

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.

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 /. stories

Here it comes..

[WhatAmIDoingHere]

"Microsoft owns MSNBC, so this is clearly an evil plan to blahblahblah.."

Actually, now that I think about it, that's probably closer to the truth than anything else...

Mod parent up

[ohad_l]

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.

Re:Mod parent up

[mwood]

Commercial software's motivators used to be different. You could just buy version N and stick with it forever, with no support beyond a ten-day warranty period. Or you could subscribe to "software maintenance", which gave you rights to expect a certain level of responsiveness whenever you had a problem *and* also helped to fund further development. With a steady revenue stream from maintenance fees, they could afford to work more nearly on a "when it's ready" basis.

Nowadays there's no revenue from quick fixes; the only revenue is from the initial sale. So theres a relentless pressure to ship something, ANYTHING, to keep the sales going. If you don't crank out the versions often enough, you could run out of money because the market's full of what you have today and you have no other source of income.

Some vendors offer per-incident paid support, but my experience is that that never gets used, because of the hassle involved in getting approval for unplanned expenditures. Figuring out a workaround in-house may cost more, but the cost isn't so easy to see and there's no delay while someone ponders whether to spend it.

Re:Mod parent up

[Anonymous Brave Guy]

While I'm not a software engineer, and I don't play one on television, it seems to me that commercial software vendors likely don't test for security flaws at all, or program with that sorta thing in mind. Functionality is their number one concern, and testing for security issues is a bitch.

It really does depend on the development team and their management. In many places, you're certainly correct, but plenty of commercial software houses do take pride in their work and/or realise that producing a well-tested, secure product is priceless in maintaining a good reputation. I've known plenty of development shops where security, and reliability for that matter, are taken seriously, planned for throughout the design and implementation, included in the review processes, and tested with enthusiasm. Unsurprisingly, these places turn out good code.

Of course, a lot of this stuff is done by software houses or contractors whose reputation is their livelihood, and it's done for private clients so most people never know about it. Compare and contrast with a major product company like Microsoft or Apple, where if they screw up even once in an enormous project, the whole world hears about how "insecure" closed source commercial software is, and you can see why a lot of people who aren't in the business get the wrong idea.

blame the users

[AssFace]

We have a user here that sent out an e-mail to 30 people that were definitely not supposed to get it. This came about because she opened up a distribution group and was pulling out the three names from that list and adding them to the e-mail message. But in the process of all of this, she also added the group as a whole (double-clicked to open it, even though that adds it to the message, but a button opens it to retrieve names).
There was then supposedly a program crash and magically the message went out.

I was of course blamed because as the network admin I somehow failed by being unable to bring back all of those e-mails, even though there are a million things wrong with that train of thought.

Clearly they couldn't imagine that:
1) software crashes don't cause mail to send
2) why was she removing names from a group instead of selectively adding them
3) she didn't use the software correctly on multiple counts
4) if she is clearly not competent enough to handle this and it was such an important e-mail, why was she given the task and not someone higher up?

In the end, yet one more reason I hate my job.

So it's the Hardware then...

[funkdid]

I understand what they are trying to say, but ultimately YES it is the code. Two things cause a system crash, Hardware failure, or Software failure. If Management makes all programmers do a shot for each line of code I'm not going to blame the managers, I blame "*/wow I am so drunk" being in my code.

Assuming all my hardware is behaving nicely if a crash occurs that means a piece of software somewhere has failed, be it OS, network or what have you.

Re:Buck Passers - Works Both Ways

[micromoog]

Remember, managers don't have as much "keyboard" time as you do.

Sorry boss, you're getting paid to know. Spend some time (gasp! outside of work if you need to) and read up. While you're not expected to know every last implementation detail, you should understand the capabilities of your chosen platforms completely.

Mission-critical?

[RealProgrammer]

A mission-critical system should be interrupted exactly when you want, not on a schedule dictated by a calendar. The original "BS!" poster was right: if there are memory leaks, garbage collection problems, etc., then that's evidence of sloppy design work.

Saying you need regular reboots is the same as saying you need a firewall to protect against viruses: both show flaws in the design of OS.

And as far as "fscking their disks every day" goes, that's more sloppy design. You shouldn't have to do that. Fsck fixes file system errors resulting from poor application behavior, environmental problems, and (sometimes) hardware troubles. You shouldn't have those every day in mission-critical systems, but even if you do then putting in place a system of daily fsck is not the way to fix it.

I've had a production application server running for the last 288 days. It's due to come down for OS updates, but it will do so on my schedule, not because its operating system is poorly designed.

Too many suits who haven't read F.P. Brooks

[bADlOGIN]

"The Mythical Man Month" should be required reading for every six figure mouth breather out there. Of course, it's thicker than "Who moved my cheese" and can't be purchased in an airport gift shop, so I suppose there's no hope...

Open your eyes

[WebCowboy]

The assumption that MS hires "idiots" is unfair to be sure. However, those in the know who have seen some of the colossal kludges in MS software, and recently almost all Windows users who have been impacted by the repeated, massive virus/worm attacks base their knowledge on the only thing they know about Microsoft--their products.

It has always appeared to me that MS hires top students from the very best schools.

That is true--unfortunately they have been known to hire them AWAY from the best schools too (ie. before they graduate). It doesn't matter if they are top five percentile students--if they have zero practical experience and are thrown into a situation beyond their capabilities the result can be less than ideal. Nonetheless, I think that by now MS has figured out how to select and place recent grads and students hired before graduation. I think the problem is now deeper than that.

Microsoft triumphed over other tech companies that were prominent in its early days because BillG learned it had to become a marketing company (the same reason Apple still exists today--Jobs knew that from the start and Gates is a very quick study). Other tech companies remained software companies--they toiled away to make their next killer app the best it could be and marketing was an afterthought.

At Microsoft, from 1980 on at least, has been a marketing comapny first, with software development second. The most important technology it markets was invented elsewhere and merely extended by Microsoft. Only in the company's latter life have they been truly serious about research. The long time "thinkers" are brilliant but historically little has come out of Microsoft's research that has been commercially successful given the potential funding power MS has had.

Therein lies the problem. The article is right--software isn't the root cause of the vast majority of failures (even when the failure is the direct result of a software bug). At Microsoft, software design is driven by marketing--time deadlines, customer requests for features, backwards compatibility/legacy support etc. The result is the house of cards we build our systems upon today.

That result is unavoidable without EXTREMELY skilled planning and throttling the pace of change. Unfortunately, The MS Ship sails where the winds take it, and the pace of change has been rapid and relentless until now. I once thought the problems with MS products were because too many drop-outs were running the show. After seeing this blog I can see what the development teams have had to cope with. They have to do the impossible and try to get it done before the deadline slips yet again and MS market cap slips a few million and BillG comes down to yell at them. In some cases you have to be brilliant just to survive at MS.

So anyways, I think software bus are the immediate cause of a lot of disasters, but the ROOT cause definitely is poor planning and project management that leads to unstable system development.

Programmers vs. Managers

[Infonaut]

Do all of the programmers you know exhibit a high level of competence? When you're working with other programmers, is it always easy for you to coordinate your efforts? Do you ever have problems with the way one programmer works and find it much easier to work with another programmer? Are there personality conflicts, or arguments over approach, or differences of opinion about what really works?

If you're programming with other programmers, you are operating in an environment that has constraints built in. You are constrained by the quality of your teammates, by the amount of time available, by the list of desired features, and so on.

Now imagine that managers are faced with constraints. They have to deal with the insane deadlines imposed on them by the O-level people in the company. Middle managers in particular are often in a very unenviable position, in that they have to try to make impossible demands possible. But just as there are varying levels of programming skill, there are varying levels of management skill. Some managers can push back on their bosses enough to give the project a chance of succeeding, but many are ill-equipped to do so.

Those that are ill-equipped to do so are in this position primarily because unlike the field of programming, where specialized education is seen as a necessary prerequisite to employment (i.e. - "He's got a bachelor's in Computer Science from MIT, we'll hire him") most managers either have no specialized management training, or they have an MBA (a degree that sometimes offers real management training but often provides no practical hands-on management training at all), or even worse, they've been in the same company or types of companies for years, learning the same bad management habits over and over.

What businesses need to do is pay more attention to actual real-world leadership experience and training. "Manager" is a term that reeks of 19th Century automated factories. When you're dealing with abstract concepts, creativity, and continually-shifting requirements, you need to have leadership skills.

You also need to have people skills, and while it's easy to berate salespeople and managers because they often seem defined by their "touchy-feely" capabilities, the flip side is that without those abilities, it's very very difficult to lead people.

278 Million Dollars later it gets cancelled

[HighOrbit]

If you want to know what a true fiasco is like, just Google "CoreFLS" and read the results.

At the U.S. Department of Veterans Affairs, some of the payroll systems date back to 1964 (that's right - no joke, they were bought when Lyndon Johnson was President), so they decided to replace them with a new system based on Oracle Financials. The new system is called CoreFLS. It has been a fiasco. So far VA has already spent over $270 Million out of an expected $472 Million total budget for the project. The project has been a failure laregly because of mis-management and plain-old stupidity.

First, they decided to do test trials at one of the busiest hospitals (that's right, they first went live at one of the *BUSIEST* hospitals) instead of a smaller test location. The user training for a critical system consisted of a self-paced web-based distance training as detailed here. No hands-on training was provided until a month after deployment and only after problems were apparent because the whole operation ground to a halt. So finally the senior managment decide to commission a $500,000 study from Carnegie Mellon to find out why it failed. The study concluded that CoreFLS was "an exemplary case study in how not to do technology transition." Yeah, they needed to spend a half-million to find the obvious.

Finally Congress got involved and all the senior managers including the Secretary himself were put on the "hot-seat" to testify. Lots of heads rolled (even senior managers like Assistant Secretaries) and lots of people were forced to resign or were fired. Now the place is crawling with federal investigators looking to put people in jail

So now the project gets cancelled. The sad thing is that VA really needed this program to succeed. I suspect that the technology has been made a scapegoat for mismanagement (not that the technology was perfect). Well.. back to 1964.

Your analogy is crap

[phorm]

More like, the plane was known to continuously leak oil and/or other safety fluids to the point where it became dangerous or unreliable. They could have either replaced the plane or fixed the problem for greater cost, but chose to ignore the problem until one day missing that critical oilchange caused a near crash.

This isn't about a standard maintenance procedure, since a server should not have to be rebooted constantly in order to maintain. stability/functionality. That's like saying it's ok to swap the oil every second flight because it's cheaper than fixing the actual problem (that there's a leak in the first place).

And actually, considering that many earlier windows problems were caused by memory leaks... not such a bad analogy now...

Re:MS employees - Not only MS!

[lcsjk]

Back in the late 60's and early 70's Texas Instruments started hiring lots of new college graduates to help them stay abreast of the latest technology. The object was to put them on a project with lots of unpaid overtime, work them at new-hire salary for four years and then, if they didn't leave on their own, gently "boot" them out the door and hire fresh, new replacements. After four years and lots of unpaid overtime, a lot of well trained engineers were ready for better jobs at other companies, taking TI's technology with them. TI trained a lot of engineers. By the mid 70's they realized what was happening and the policy was reversed.

Re:nobody yet knows how to design software

[jesterzog]

Sure they do. The subject's been studied for decades; there's been loads of work (some of it quite good) done on it. The problem is the commercial software producers never pay any attention to any of it. "There's never time to do it right, but there's always time to do it over."

No they don't. It's been studied for decades, but in all that time we've still not settled on anything that's actually demonstrated over long periods of time to be good. Hardware, materials and other available resources are continuously evolving and changing, meaning that software design research has nothing to reliably settle on before things change again.

We don't even have consistent and proven programming languages. Today it's Java, C#, VB and a variety of imperative scripting languages. Yesterday it was C and C++, before that it was Fortran, and before that there have been variants of assembler. And as we use these languages, we're constantly discovering more and more about language design and developing new languages.

HCI is still in very early stages of development, and that's a major part of software engineering. (If people can't use software then what's the point?) The vast majority of software development shops -- particularly smaller ones -- don't even employ HCI experts, and substantial proportions of developers still don't respect them or understand what the point is.

Something like bridge building, for instance, has been studied for centuries (if not millenia). It relies on consistent physics, consistent tools and well understood environments. Organisations that build bridges have well established experience, procedures and regulations that are put in place throughout their organisation. Software development's been studied for a few decades with the existing materials, resources and expectations constantly changed from underneath it.

Organisations that build software still don't have any reasonable idea of how to arrange themselves, or what procedures they should be using. There have certainly been some pretty good ideas from relatively recent ongoing studies, but the fact that managers and developers and marketers and whoever else frequently don't gel together very well with usually bad results is just an ongoing consequence of the fact that it's a very new field.

Just because software engineering has been studied for a few decades doesn't mean we know what we're talking about, or even that we know what we're studying.