Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

I'd look at it differently. I would firstly work out exactly how much money is generated through effective IT services and projects, and then I'd work out how much money is saved through effective IT services and projects, and then work out how much is lost through projects that go wrong. I think this sort of analysis would give a more true picture of the benefits and risks of IT projects.

The amount of time / effort / money I've lost over the years due to buggy and crashing computer software is staggering. And I solely blame this on incompetent software developers. I'm talking of both commercial software (I'm surprised they let some of this crap out the door - do they know what testing is?), and also my own experiences working with development teams.

I've had developers work for me that think they know everything there is to know, refuse to listen to any advice, and basically try to write software only in the way they believe it should be done, completely ignoring the needs and requirements of the system lead and the customer. Throw in to the mix some elitism and a complete lack of ability to communicate without insulting an derogatory statements, and you've got a profile of a large percentage of current software developers. I'm still working to undue to colossal mess of my last ex-software lead that I ended up kicking off the program because he fundamentally didn't know what he was doing (despite thinking he was the best developer on the planet). I've also worked with some amazingly brilliant software developers, but unfortunately they are few and far between. The sheer arrogance of some software developers is astounding.

The amount of time / effort / money I've lost over the years due to buggy and crashing computer software is staggering

The amount of time / effort / money lost over the years due to poor management, bad analysis, and improbable times lines is staggering.

There, fixed it for you. You do see that your own statement is about as arrogant and condescending as the programmers you want to insult. Buggy code, crashing software is not just the responsibility of the programmer, it is the responsibility of the leadership as well. Why was it buggy? Bad design specs, no code reviews, tight time lines with large interruptions? Why did it crash? Poor QA and review by business owners? ridiculous deadlines, poor working conditions, low morale?

There is more there then just "bad programming" as if programming exists in some bubble. Developing is not assembly line work, it is a complex art and yet over decades management has viewed it from an industrial age mentality. Work from x to y, produce x lines of code, stop what you are doing and look at something else no matter where you are at. Certainly there are arrogant programmers, just like there are arrogant managers. I challenge you though to see that both need each other to reduce the number of bugs, the minimizing of crashes (really "crashing computer software? Not Abending or exception failures?) When a positive work environment is set that people tend to work better, with less error. That is the job of management and yes, even leads. For the record, I have been in lead and oversight positions. The best role I played was to get out of the way and let my people do their job. Along the way I would just ensure that we maintained a high quality of effort and we kept on focus to the requirements provided.

Manager: We need to add Feature Y.Coder: But that builds on Feature X, which is still buggy.Manager: I don't care. The customer wants it.---(A month later)Coder: Can we take some time to fix the bugs in Feature X and Y?Manager: No, we have to make Feature Z, which builds on X and Y. We can fix them later.Coder: If we'd known you wanted Feature Z, we would have done X and Y completely differently.Manager: Hmmm. Well, it needs to work by next Tuesday.Coder: (very quiet expletive)

I agree with what you say is an aspect, but you cannot just poor working conditions for bad coding. If software was properly architected from the ground up, then there wouldn't be so many bugs, and the schedule wouldn't be blown.

Where I work, the schedule is determined by the actual developers, and the features are finalized at the beginning of the program. If development stays on schedule, then management doesn't interfere (why interfere if there are no problems?). The conditions you state I'm certain exi

I've had developers work for me that think they know everything there is to know, refuse to listen to any advice, and basically try to write software only in the way they believe it should be done, completely ignoring the needs and requirements of the system lead and the customer. Throw in to the mix some elitism and a complete lack of ability to communicate without insulting an derogatory statements, and you've got a profile of a large percentage of current software developers.

I think I know your problem you keep hiring noobs right from college and are giving them large of tasks with little oversight. If your employees do not follow your direction then either you're and idiot because you don't know where you are going or you're an idiot because you don't know how to manage your personnel. There are many excellent developers you just have to properly interview candidates so you can weed out the morons there are idiots in every profession and the good managers know how to spot t

So I'm not a programmer because I don't accept crappy buggy code? Get real. I've 20 years of real-time mission critical coding experience; I know what constitutes good code and architecture, and what is bad.

Software developers need to learn they have to ARCHITECT code. You cannot just hop in and start writing code without a plan. It would be the same as trying to build a house without blueprints, just nailing up wood at one of the corners.. It will kind of look like a house when done, but will have lots of problems. Code is the same thing.

And some managers need to learn that coding takes time!!!!
I was on a project where 98% of the time was design and Analysis and then I was supposed to code it in the few remaining days/hours.
The waterfall model IS NOT valid for less than multi-year projects.
Or at least incompetent can NOT use waterfall model.
Tim S.

:) That's the problem with many of the projects I've seen: No time for requirements gathering, no time for testing, and deployment should take less than a day. So no matter how well you design and execute your design - you end up with last minute poorly thought out enhancements and any testing done happening from a developers standpoint instead of an end user's.

You are a person in power over a program with missing QA, poor communication, where you try to control technology instead of what gets produced, a program you yourself describe as a "colossal mess", and where you are describing those you work with as "arrogant".
Do you think there may be more problems with your program?

I'm in charge of a program where the ONLY problem was with the software lead. Mechanical, electrical, controls, etc - no issues at all. It also happens that the software line manager is friends with the moron software lead and refused to do anything despite repeated warnings that software was an impending train wreck. I was told to let him do what he wanted to do. My hands were effectively tied.

Several wasted millions of dollars later, I finally get him kicked off. Now its a matter of cleaning up the aft

Most people aren't stone-cold psychopaths, or even consistently self-interested egotists. They're just plugging along, mostly trying to get along with one another. And yet, despite the inputs being, on average, good(or at least OK), the system as a whole puts out an unrelenting stream of shit.

In IT, there are certainly some truly impressive morons(and their much more dangerous cousins, the slick frauds); but most people are more or less OK, and some ar

with far less experience. Much of the successful teams have members with DECADES of experience. That is why IBM was willing to pay money (but not salaries) from employees to move to India and China. They know that they need experience, but do not want to be saddled into the long term costs. In time (1-2 decades), China/India will gain that experience and this will change. In the mean time, a western business is better off hiring from the west where Coding was developed and the experience still resides.

Actually, this is more likely mostly due to user incompetence. This number has to include the cost of all the extra IT and helpdesk personnel that are required to help PHBs who forget their passwords, download malware onto their work computers, can't figure out how to run a financial report and so on, you can get into the trillions pretty quickly.

The other big item is probably the industry-standard 20% of losses on IT projects due to scope creep, cancellations, system defects and projects that shouldn't hav

No ! It just means the guy who wrote the white paper, and the guy who comments on it, are both incompetent.

A large number of these will eventually fail. I assume the failure rate of an "at risk" project is between 50% and 80%. For this analysis, I'll use the average: 65%.

Using the same kind of bullshit reasoning here is what I found: A large number of human beings will eventually die. I assume that human beings live between 0 and 100 years. For this analysis, I'll use the average: 50 years. Except that the average life expectancy is not 50 years but actually much higher. Taking the mean of the minimum and the maximum is not at all the same as taking an average, you may

To be blunt, I have noticed a MASSIVE decline in the quality, intelligence, and desire to do a 'good' job in the companies I've been at over the last 5 years. The outsourcing boom chronicled so nicely in Office Space and the like has not done anything to improve the quality of tech work.

I would say good IT people are probably 1 in 100 or less - the rest are either grossly incompetent, lazy, or completely burned out by carrying 2-3 times the workload that should be expected of them.

Many IT people are incompetent. They are hired by incompetent managers who are more interested in keeping salaries down and maintaining a corporate cube farm than they are in hiring good quality people. Very few understand that the best are 10 times more productive than the run of the mill if you stay out of their way. The problem is exacerbated when management refuses to believe that the assembly line is not at all an appropriate analogy for software development.

Standardization on DOS gave a huge boost to MICROSOFT at the detriment to anyone else that wanted to build compatable software.

Binary "standardization" just gives the owner of the standard a lot of control and the ability to destroy anyone else in the industry it finds to be a threat. It also allows the monopoly owner to continue to forcefeed their product to customers no matter how crappy or unsuitable it is. Everyone ends up like a strung out junkie stuck on a perpetual upgrade treadmill over DECADES. Hel

Not only are you awesome at bad analogies, you are terrible at syllogistic logic.

Premise A: Global GDP = $60 trillionPremise B: Total lost due to IT failue = $6 trillionConclusion: Every company on the planet has lost 10% of their productivity due to IT failures.

Let me restate this another way - this is like saying there were 100 million bananas grown in the world in 2009, and that monkeys threw 10% of bananas on the ground, which means that 10 million people slipped on bananas every year.

Read again , for the US it is only 1.2 trillion, or more like 2% GDP which isn't too far off when I could all the loss of time my colleague and me get with POS windows software breaking down.
WORLD is 6.2 trillion USA 1.2 trillion [zdnet.com]

... every time someone starts talking about "complexity theory". When I got to the point in the original article where he just freaking made up the indirect cost as ratio as "between 5:1 and 10:1"... and then took the "average" of the two made up numbers to proceed with his "analysis", I lost all interest in the story. News flash: when you make up your own numbers, you can get any answer you want... and really big, scary numbers sell more articles. Yawn.

The credulity problem gets worse when one considers how much more productive people have become when using various applications. Yeah, some of them are probably counter-productive, but others (office apps, line-of-business apps) have transformed how we do business for the better. The number seems terribly grandiose even if you push all of the negatives to one side of the equation.

We see this in our clients relatively frequently. Primarily because small to medium sized businesses are some how allergic to backups. No matter how hard we push for them to actually spend money on a backup system that is appropriate to the size of their business a lot of them end up cheaping out on either no backup, or a backup that isn't the right fit for them.The resulting failure a year or two down the line can cost then a huge piece of their annual revenue.

Other places we see this are when clients try to put their own (Windows) servers in and screw something up that requires the OS to be reinstalled to undo.In my experience a lot of these "IT Failures" are actually management/client/accounting failures that happen to overlap the IT spectrum. If you can't get the proper budget to do your job, that's an accounting failure that shows up in your area. If management refuses to abide by their own usage guidelines on the network and constantly are passing around infected files that's going to increase your infection rate. And if a client adamantly refuses to change their tapes then when they have a flood in their server room and it gets toasted that's going to translate into longer recovery times, longer down time, and lost revenue.

Tapes are orders of magnitude slower, with only slightly higher reliability, and a funny habit of only working in the _one_machine_ that a small/medium business might have their single tape drive installed in.

Including "startups" is perhaps counterproductive, as they don't have any real business model to start with, they float "ideas" to dumb VC's, and never generate a real dime in income before they fail.

The only money lost was the venture capital.

To understand the "cost of losses due to IT", you have to have a functioning business in the first place (with no IT infrastructure), and then see what happens once IT is deployed, and then subsequently fails, weighed against

Money that could be better spent elsewhere. This is called "opportunity costs". That money could've have been used to back a company with a good idea that had to fold due to lack of capital. E.g. the next RIM, the next Google, the next Apple.

I agree. Totally pointless dribble, it would have some merit if actual failed IT projects were scrutinized in multiple companies and then a hypothesis gathered from there.

If you take a read of the whitepaper, this is really just a sales pitch for SIP ("Simple Iterative Partitions"). You would think someone training clients in SIP would have a few real metrics on failed IT project costs.

While it's true that many IT project failures are truly spectacularly expensive, many are also a learning experience. We should strive to eliminate failure, of course, but some inefficiency will always be present in any sufficiently complex undertaking.

If one failed project helps a business prevent similar failure in future projects, has the failed project not produced some value after all?

This is more philosophy than anything else, but things are seldom black and white in this world, are they?

If one failed project helps a business prevent similar failure in future projects, has the failed project not produced some value after all?

Not really. Let's say that one succeeded and the future projects still succeed. Obviously that is positive compared with the failure you described. Let's say that the one succeeded and a future project failed, which then led to the experience to succeed at the other future projects. The overall state would have been neutral, on average.

There's no use praying for failure just so you can gain experience at failing.

We've been building bridges for what, four, five thousand years? And some still fall, and we still learn from them.

Yet somehow, people expect that their software will be as stable as a bridge - despite the fact that behind each and every bridge there are more than ten thousand years of collective human experience, while software has maybe a scant thousand.

Seriously guys, take it in perspective: software is a ridiculously new field compared to basically every other field of human endeavor. Don't expect rock-

The real issue is that companies like IBM, Qwest, Verizon, ATT, etc have been moving their work from Western countries to China and India. These countries do not have the experience. Experience is what keeps projects from failing. Youth, combined with adventuresome and lack of knowledge of what fails is what allows new directions to be taken. A good company needs both. Most of these large companies are gutting their experience, but not taking on those that want to be adventuresome. That is why companies

Integrating data from social media networks(get your checkbooks ready and form an orderly line, venture capitalists), particularly those, like linkedin that handle professional affiliations; along with influence peddling/lobbying data from the likes of opensecrets, this tool could automatically grade the trustworthiness and cheap-hackticity of a given article's author, saving you the trouble of manually ignoring the astroturf and marketing fluff.

It'd be a lot trickier, and less precise, than just using regex and blocking known-evil domains; but, in principle, it should actually be possible to use "social media" normally a stalwart friend of subhuman marketing scum, as a source of the information necessary to thwart the same in their vile designs...

When I read Roger Sessions described as a "noted author and expert on complexity", my first reaction was [citation needed]. Particularly since this 'noted' expert didn't even merit a Wikipedia article (the article for "Roger Sessions" is for a very talented early 20th century musical composer).

And it's not because authors of IT and CS books aren't meeting Wikipedia's notability rules, since lots of others are: e.g. Tanenbaum, the Gang of Four, Larry Wall, Guido, etc.

So let me get this straight... You spend a dollar trying to improve your business process. It doesn't work out. So you're out a dollar. I get it. But then you're out a further $10 because if it HAD worked out, that's what you WOULD have saved. Puh-lease. That's assuming your idea was worth a fuck. NOT ALL IDEAS ARE.

I can easily prove that you personally have lost millions of dollars because there were plenty of things you COULD have done to earn those millions. Why didn't you start a search engine? Why didn't you write the twitter application? Not skilled enough? Heck, you should have bought that winning lottery ticket! And while we're at it, why did you waste your money on fixing your car when it just got wrecked a month later?

Sir! You will NOT sully the good name of(...what was it, hang on, let me check...Roger Sessions...)Roger Sessions! He is a respected and noted author and expert on The Internet! He knows exactly how SRS this business can be!

When thinking about indirect costs, you need to include the costs of replacing the failed system, the disruption costs to your business, the lost revenue because of the failed system, the lost opportunity costs on what that lost revenue could have driven, the costs to your customers, lost market share, and on and on.

You're claiming that his "the lost opportunity costs on what that lost revenue could have driven" is bogus. However, thats only a small part of his otherwise pretty good argument, so overally, not too bad.

Also, at least some times, its pretty easy to calculate a lost cost revenue cost... Imagine you've got a signed contract to deliver product A, yielding a profit, and you fail. You needed that profit to grease the wheels for totally independ

... he apparently just pulled the indirect:direct cost ratio out of his ass! If there had been any data backing this up, it would be one thing, but apparently this analysis was at least in part based on numbers he just made up.

Yea but you just cant play the coulda woulda shoulda game, it didn't work when I was 5, and its not gonna work when corporations do it now.

OK, but you fail to give a logical argument why it won't, other than, "cwix says so".

Yes, everyone knows there is a difference between wild daydreams and signed legal contract obligations. I think the article is more about the latter than the former.

You cannot budget money you don't have yet, not reliably. Sometimes money thats supposed to show up doesn't for whatever reason, and blaming it on IT workers, and selling your service as an IT expert smacks of

smacks of breaking a signed legal contract for IT services with a failure to perform penalty of a specified # of dollars, which is going to have a realistically calculable dollar impact on other areas of the company and other company projects.

<tongue position="cheek">How is this money wasted? It's a lot of work to produce a spectacularly failing projet. All those programmers and project managers are not free you know. They have to pay their mortgage like everyone else.</tongue>

I wonder how much of this IT failure is actually user (non-IT) failure? From experience, the amount of user error that becomes an IT problem is far greater than the actual IT problems. Also, these are user failures that generally cannot be prevented by IT using error catching or better UI by the way.

What nonsense. One of the foundations of project falure is built from the top down. Executive leaderships say "make this work" what ever "this" may be. Top leadership runs around then looking for a solution. Many times they go to a vendor and of course the vendor says "Why yes, our product will solve "this" problem". So instead of so good due diligence on the part of analysts to truly see what the specific needs are, the company purchases this cost saving solution; perhaps it is a service, perhaps it is a soup to nuts enterprise system, perhaps it is off the shelf, out of the box software.

Soon into implementation or pilot the upper levels managers finally begin to see what their own IT staff and their customers were trying to tell them1 - We don't need "this"2 - "This" does not fit our needs3 - "We have to use "this?", the current system works.

Even worse, while the company has a qualified in house staff that understands the specific needs, they will hire consultants to tell them how "this" can work for them. It could be that certain decision makers were favored by the vendor to "try it out" only to find later that the trail cost more in lost time, money, effort while the vendor pockets the dough.

Cynical? Not really. Over my long time in the business I have seen this time and time again. Even though there is a good staff structure in place to handle company IT needs top corporate leaders will buy from a vendor because the perception is that the goal will come quicker. Never mind that the product may not fit, IT will make it fit. Never mind the internal customers that need retraining, we'll hire new people...and on and on. All to try and save time. The bottom line is that any failure of an IT project begins with the top leadership not doing their job. The first question they should ask and answer before dropping a dime is "Do we really really need "this". The second, "Is it an emergency?". The third, "Do we have staff to create "this"?, the fourth "how will this effect our internal customers?. In a world where the attitude is "We need it yesterday" there will be more failure, but do not fault just IT, fault corporate leadership.

Owner: I just bought 50 gold plated facuets, put them into the house your renovating.

Builder looking at the blueprints for the two bathrooms: where do you want them?

Owner: I don't care, just put them in because I paid for them.

Builder: how did you pay for them?

Owner: oh, I decided that your electrical upgrade is not needed. The guy who installed it, what's his name, Thomas Edison? I'm sure there is plenty of capacity to handle the fifty ton HVAC and my million volt tesl

And the REALLY sad truth of all this is that if you do kill yourself working unpaid overtime, giving up your vacation and your health and personal life and succeed, what is your reward? You are then *EXPECTED* to do this from now on, and if you don't, your slacking off and not being a team player.

Either that or you are expected to train your outsourcing replacement in India with everything you know because you are being laid off.

As much as I hate to say it, you are dead wrong about this. Many people think the job of top leadership is to make the company run smoothly. It's not. Their job, specifically, is to:

Improve the overall impression of the company in the mind of the shareholders, i.e. "increasing shareholder value" or stock price. Notice that this activity has nothing to do with the solvency or efficiency of day-to-day operations. It is why companies blow billions of dollars on unworkable "solutions" (i.e. outsourcing) and hare-brained ideas (i.e. Web 2.0...)

Reflect the bias and preconceptions of the shareholders. Again, this explains why CIO's typically choose vendors and products which have no relevance to day-to-day operations: the shareholders know little to nothing of operations, and when every other company is using SAP or Oracle, you had better make sure you do as well. Even if all of the company data could fit on a floppy disk.

Finally, most importantly, the job of the CxO is to finish projects. The shareholders and CEO has no clue what the company actually needs, so the CIO must finish *some* project, regardless of how irrelevant it turns out to be. He'll pave the way for later CIO's by installing a ticking-time-bomb of a system which eventually gets so bad that it must be replaced. No matter how badly the project turns out, no matter how useless or counterproductive, the CIO gets paid based on the size and complexity of the project. The only way a CIO can fail is if he is so concerned about "getting it right the first time" and "making a smooth transition" that he wears out the CEO's/shareholder's patience and fails to finish a project in what they consider a reasonable timeframe. It doesn't matter if it is complete junk; the CEO won't ever hear the problems.

I found it much easier to get along in Corporate America once I discovered the quality of the job is less important than the careers of management. Nobody got fired for shipping a buggy product, but people have been fired for not meeting deadlines.

how about uniform standards and less versions of sql, less browsers, less version of unix/linux, and maybe even standards in linux so that installations and menu additions and gui stuff was easier like windows. Yes linux folk open source 1000 different distros is not helping linux take over the desktop. And must windows really move stuff around each version just to confuse people and make them relearn again? But most of all why must applications be given so much freedom in terms of operating system. Can't t

Basically, a self proclaimed IT efficiency expert writes that "the world is wasting TRILLIONS of dollars a year, because it has bad IT". The subtext is, you must hire an IT efficiency expert, and "um, I happen to be one".

It would be nice if people that publish all these shock numbers were not so transparently self motivated. It almost makes me not trust any number at all. It's like, if Newton were alive today, and published that Earth's gravity acceleration, I'd have to ask, well, what's in it for you, Isa

It would be nice to have some mod facility to get these nuked. It's disappointing that such a long running resource like/. is now being infected with self promotion. One of the best self promotion FAILS was the one about face book switching to some C++ frame work from php in order to save 10s of thousands of servers resources. I'm still laughing about that one.

I can give you perfect IT systems. It will cost you Infinite Dollars. Or I can give you a totally failing IT system for nothing. Somewhere along that line is the break-even point, and if we assume the market is working the way it is supposed to, we are riding that break-even point.

Exactly! It's the cost of doing business. It's staggering the amount of productivity that is accomplished despite IT failures. And human idiocy, corporate theft, pinhead bosses...the list goes on and on and yet profit is still generated. Yes, it's a problem and I won't discount the need to do something about but it's reality.

Seriously - this is dumb - IT projects, just like life, will often fail. We know they will and we know why. If it was such a problem then clients and project managers would actually do something about it - but they don't. So in that case all I care about is that I get some of the money - and I work in IT - so I do. Hooray!

Also, failure isn't such a bad thing - my past relationships failed, I didn't regret them (well, ok, I did...) - my latest poem failed to be any good, I didn't regret trying - my last batch of home brew has gone bad (I may still drink it of course) but that's life.

Vendors grossly over selling what they can do.
How many times has your company bet on a future product of a vendor that is the best thing since sliced bread and will be available in 3 months,
and then 3 months after that, and then 6 months after that, and then a year after that, and then 3 months after that, etc.
And when it finally comes out most of the pie in the sky features you were depending on don't really work.
But they say it will work in the next version.
Real Soon Now.

Star Trek style management: Managers who think their crew are Scotty who pulls off a miracle every week.
Its never been done, we don't have time to do it right, but its got to work right the first time given not enough resources.
Sure it works on Star Trek, its in the script.
FYI: I love the Star Trek series, but I also know the difference between fiction and reality.

Changing requirements: tell me, who could build a house if you were changing the design every week? One week its a ranch, next week its an apartment building, next week its solar power, next week its wind power, next week it has 5 bathrooms instead of one, next week the bathrooms get moved to different areas of the house, next week the water supply gets moved to the other end of the house. And by the way, we need to cut your budget and move up the deployment date.
Doesn't that sound like what happened to Duke Nukem Forever?

Big Bang deployments. Designs where a completely new design replaces an old one. No system wide testing (remember the Hubble? The system wide test was deleted to save money.). The old system is torn out, the new system is thrown in, and everything has to work the first time because you can't go back. And there are no facilities for debugging or diagnostics or changes because of course the programmers got everything right the first shot.

Ignoring your own staff.
Staff does a detailed bakeoff of competing products and chooses the clear winner. Manager goes with the looser because he owns stock in that company. Company deploys product, deployment goes badly, manager blames staff.

Note: these are composite examples from many sources I have gotten over the years. They are not against any one company.
But I think they are indicative of the industry as a whole.
And that is sad.

All excellent points. In my experience one of the really big ones you left out is "feature envy", especially when it comes from the sales staff (aka "Marketing"). If management/architects would be happy with seeing only the 80% of the functionality delivered in 1.0, more systems would make it out of development on time.

Star Trek style management: Managers who think their crew are Scotty who pulls off a miracle every week. Its never been done, we don't have time to do it right, but its got to work right the first time given not enough resources. Sure it works on Star Trek, its in the script. FYI: I love the Star Trek series, but I also know the difference between fiction and reality.

Geordi: "Yeah, well, I told the captain I'd have this analysis done in an hour."
Scotty: "How long will it really take?"
Geordi: "An hour."
Scotty: "You didn't tell him how long it would really take, did you?"
Geordi: "Of course I did."
Scotty: "Laddie, you got a lot to learn if you want people to think of you as a miracle worker!"

I actually think Scotty had a more realistic view then Geordi. Sure, it would take one hour. If that were the only thing you were working on and you didn't get any interruptions.
And your double checking is simply "Computer: verify results" and the answer is always "Results verified".
Welcome to the real world where that never happens.
Requests get piled on top of requests.
And then there are the "This is an emergency, and I'm sure it will only take you a minute because you never seem to be working enough

"According to the 2009 U.S. Budget [02], 66% of all Federal IT dollars are invested in projects that are "at risk". I assume this number is representative of the rest of the world."

"A large number of these will eventually fail. I assume the failure rate of an "at risk" project is between 50% and 80%. For this analysis, I'll use the average: 65%."

"You can see that indirect costs add up quickly. I will assume that the ratio of indirect to direct costs is between 5:1 and 10:1. For this analysis, I'll take the average: 7.5:1."

In summary, if you assume Federal IT expenditures have the same rate of being "at risk" (whatever that means) as every business in the world, and multiply it by the average or two numbers I just made up, then further multiply it by the average of two other numbers I also made up and wouldn't even make sense to use if they were real, then multiply that by a semi-legitimate percentage and the GDP, you get A Large SCARY Number!

You did notice that he's claiming that IT failures cost over 3 times as much as the total spent on IT, right?

"2.75 % of GDP is spent on hardware, software, and services." OK, so that's $1.92 trillion for the world total spent on IT.

"To predict the cost of IT failure on any country, multiply its GDP by.089" Wait, 8.9%? $6.21 trillion in costs on $1.92 trillion spent? Is this the accounting from "the Producers"?

I expected someone would have checked the math before posting this kind of story on Slashdot

does this amount take in to account the massive amounts of money made by ignoring bugs and pushing forward anyway?sure a program might have a bunch of bugs that costs $$ to patch and deal with on a daily basis, but the fact that you now need 90% less staff or that you can do 1000 times more business is likely to far outweigh the cost. Which of course is why businesses still love IT.

Sure better and less complex solutions could be created, but they take thinking and planning time and usually then have to deal

My take on this is that the main cause of failure is the fact that IT still hasn't settled on a set of engineering principles to deliver projects. Things change way too fast still -- over the life of a 2-year project, your hardware platform may be changed out from under you, for example. PHP,.NET or Java may be swapped out for YetAnotherCoolLanguage0.1alpha4. This is made worse by unscrupulous vendors, poorly-trained consultants, and lack of acceptance by the user base of the software.

I think the author is referring to the direct cost of a failure. Every few months, the technical publications run an article or two about a large company or government agency writing off millions of dollars for a failed SAP/Oracle Financials/similar package deployment. Whenever I see one of these, it's interesting to see what happened. Usually it has something to do with one or more of the causes I listed above. Generally, the more expensive, tranformational and long a project is, the worse the results are. It's not just vendors either - I've seen in-house projects spiral down the same way. The other thing that comes to my mind when I read articles like this is why they didn't see it coming. Don't IT executives talk to each other over golf or something and say, "Yeah, SAP screwed us out of $100M in consulting fees. I'd watch them if I were you..."?

Other branches of engineering aren't immune to this though. Construction and infrastructure projects often run over time and budget. The difference is that a construction project gets finished one way or another. A software project failure means throwing away two years of work and putting the hardware on eBay.

Well *I* am not only a noted expert on complexity but a specialist in improbability and a noted chaos activist (having a doctorate in activism) and *I* say that IT errors cost TEN QUINZILLION DOLLARS so pay attention to me me me.