Slashdot Mirror
Lessons From a Decade of IT Failures (ieee.org)
New submitter mixed_signal writes: IEEE Spectrum has an online set of articles, or "lessons," on why big IT projects have failed, including analysis of the impacts of failed systems and the life cycles of failed projects. From the summary: "To commemorate the last decade's worth of failures, we organized and analyzed the data we've collected. We cannot claim—nor can anyone, really—to have a definitive, comprehensive database of debacles. Instead, from the incidents we have chronicled, we handpicked the most interesting and illustrative examples of big IT systems and projects gone awry and created the five interactives featured here. Each reveals different emerging patterns and lessons. Dive in to see what we've found. One big takeaway: While it's impossible to say whether IT failures are more frequent now than in the past, it does seem that the aggregate consequences are worse."
You will never write good code without writing bad code first.
And you will never stop writing bad code without being accountable for the results of writing bad code.
Experience is not how long you spend writing code. Is about how much time you spend fixing code, learning how to avoid having to do it again,
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
impossible to verify?
There are a million reasons why things fail, but they fall into a few broad categories:
Failure to plan ahead ("we'll worry about demand later, once we have a viable product"),
Failure to adapt to changing circumstances ("buggy whips will always be essential to our lives"),
Failure to avoid predictable or likely failures (i.e. "develop a perpetual motion machine")
Failure to manage resources properly ("have everyone working on this and not that).
There are millions of others, but most of them fall under one of these primary categories.
Just cruising through this digital world at 33 1/3 rpm...
The list of failures from TFA proves that software cannot be created and then not maintained, not constantly observed, not updated. Complex software that interacts with real life systems cannot be treated as if it is a 'fire and forget' thing. It is not.
The "disappearing warehouse" case is perfect, nobody was keeping an eye on the system, nobody at all was actually personally invested, personally responsible. I have created a lot of software over my life, I built and own a retail chain management system, store management, supply chain management, customer relations management, logistics, shipping, payment, warehouse management and some other systems. These are used by medium sized companies (actually in the world they could be called small, only dozens of stores, only hundreds of employees and a hundreds of suppliers, but actually tens of thousands of SKUs)
I know this: the owner of the business does not forget anything. The owner of the business is the person whose personal wealth is tied into the business, that person does not miss anything and if he or she is personally involved in the project, they understand the system (not entirely, but the parts that are important to running the business), no warehouse would go missing, no store would go missing, no supplier would go missing.
The reality is that combining complex software with lack of personal responsibility leads to real world issues.
You can't handle the truth.
* Poor Management - people, time, money, hardware
* Poor Code -- either assumptions, or sloppy code
* Lack of Quality Assurance
Usually one or more.
Dock the severance pay of the old IT guys that failed to train the HB1's right.
Suggests that management hubris plays a big part in IT Failures.
We have a lot more code failures now than we have had in the past. One can look at security issues with basic things (hypervisors) as proof that this is endemic across the board.
The problem is that there is no encouragement, no carrot, for doing anything in a dev shop other than "It builds! Ship it!" In fact, it is expected, and companies, even consumers wait for the x.0.1, x.0.2 version before attempting to use an app or a service. The -only- exception to this rule is malware, and perhaps some small embedded shops that actually get paid on code quality, rather than features and release dates.
Development as a whole has changed, especially with CI/CO programs and the Scrum model, to be an ongoing effort, where it is perfectly OK to write poor code, as there will be a pass eventually to correct the glaring errors. The days of actually having a tried-and-true x.0.0 release are long gone.
Don't attempt to do what you are too stupid to grok.
Danish. Dutch. All the same.
It all comes down to the time, money, quality triangle. The more you focus on one aspect the more you lose on the other two. And because in the end projects are always focused on time and money, quality is almost always neglected. Especially in highly political environments where the ideas have to be implemented with low cost and this year projects are bound to fail.
Perhaps they should study why my employer fails at everything IT based lol
There was a saying that if builders built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization. Having spent a few decades of my life writing compilers, dbms internals and similar I tend to agree. But I think that at the root of the problem is the issue of the invisibility of it all to those folks in expensive suits that control our resources and direct requirements and delivery dates. With a building, the construction is a matter that all can look at and to some extent agree upon. Hard to carpet the lobby when the foundation hasn't been dug, etc. But software is different -- the real guts are hidden. So it becomes easier for management to make impossible demands -- and for programmers to create kludges to get 'er done and move onto the next thing. All the while hoping against hope that when this particular can of worms explodes it won't be their pager that goes off at 2am. And the problem with major screwup analysis is that management learns nothing from it, generally, while the folks in the trenches mentally recount the number of times they have seen problem 'x'. Be nice if there were a solution that was not intrinsically self-corrupting. Like the way digital electronics have encapsulated functions in easy to implement modules...sigh.
Existing organisations in developed countries have years of IT failure and legacy cruft to deal with... It's very difficult to make significant improvements because replacing existing systems is expensive, time consuming and often meets resistance. People dislike change, and most people are simply unwilling to challenge the status quo and/or don't understand the improvements that change could bring.
IT in most places is horrendously insecure, buggy and unreliable. Things don't work well, and businesses end up having to adapt to how their software is designed rather than the other way round. Data is locked in to proprietary formats, and companies are stuck on the upgrade treadmill or faced with systems that suffer from major problems but cannot be replaced.
However what is even more disturbing, is that new companies and developing countries want to copy what big organisations in developed countries are doing... They absolutely refuse to learn from our mistakes, and instead are trying to repeat them!
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Actually, you're the biggest idiot here. The OP was referring to HB1 pencils. Only the old I.T. guys knows what those are and how to use them.
Sadly, the problem I see is that no one wants to admit the cost of the labor. We sell software, and the most troubling part is we try to explain the cost of the software might only be 10% of the whole cost to implement. But, no IT department wants to believe it, or they want to figure out a "shortcut".
"We are smart, we can do it ourselves". No, that's not true, you have never seen this software, you need training at the least, and then you don't want to be training and making mistakes on this large implementation, hire someone to help.
"Jonny will work on this"....Uh, Jonny has a full time job. This is going to be a full time job to work on this project.
"We will just buy less amount of the software" . No. It won't help, buying less still makes know difference to how long it will take to learn it.
Day in, day out, I see this across the industries.
Hey, it's only a stereotype that visa workers are skinny.
Table-ized A.I.
Actually, you're the biggest idiot here. The OP was referring to HB1 pencils. Only the old I.T. guys knows what those are and how to use them.
Mechanical Drawing class flashbacks! Nooooo!
What do you think?
I have worked for a lot of large companies, and one of the things I've seen cause a lot of failures is thinking a problem will disappear by throwing Magic at it.
- Cripplingly-slow WAN speeds? Vendor X is the Gartner Magic Quadrant leader in WAN Optimization, we'll just use that! Here's $2 million, Vendor X. Just put it in, you're smart IT guys, how hard could it be?
- Developers and IT guys are expensive. I know, let's call Infosys/Tata/Accenture/HP/IBM, all I have to do is write them a check and all my IT problems disappear offshore!
- I don't want to pay for equipment. I know, let's put it in the cloud! The cloud makes all problems disappear for a low low monthly fee!
I'm a pretty avowed generalist, but my two "specialties" are end user computing stuff and systems management. EUC is rife with magic solutions -- I can't tell you how many thin client/zero client/cloud desktop/VDI/Citrix/Whatever iterations I've been through where the CIO didn't realize that the problems don't go away. Problems just get moved around and may be more expensive to solve in the new configuration. Systems management is a whole other ball game. In this field more than others, vendors like CA, Microsoft and some of the startups have the art of the stunning sales demo down pat. As a result, people like me have spent untold hours and company dollars on expensive vendor consultants getting even a fraction of that sales demo working in the real world.
I love the constant innovation that our field serves up, but one needs to temper that with the reality that most innovation is a rehash of something done before, with the underlying pieces improved. I think the IT field is long overdue for at least some standardization where we don't let vendors run the show.
You can't have mismanagement without "management".
Anyway there are plenty of reasons, much of them boring like budgets and staff resources.
One however that isn't talked about much, is the ability to say "No" when talking about requirements analysis. Usually this is where nobody wants to say no to a manager who has seen things like the internets and iphones.
Typically an application is created to solve a business problem. There is a tendency to want to throw everything and the kitchen sink into the project, more less because you can. I think if a lot of projects concentrated on producing a simple product that solves the core business problem in a very stable way without a lot of bells and whistles increasing the complexity of the project they would be a lot more successful. Nothing wrong with collecting the bells and whistles as requirements, that might be added at a later date, once the core business requirements have been met, deployed, and proven. If more time was dedicated to core than on fluff towards something that is functional, I think it would pretty much eliminate project failure, at least in that there would be some usable results, and not just a huge pile of code and documentation that is non-functional. Big healthcare systems come to mind.
There are more people in the world fulfilling the needs of the many than before. Ever larger proportion of those people don't have the experience to avoid easy failures. "Soft skills" are difficult to learn in a typical CS program, as the learning related work is left as an exercise to the student.
Don't mention offshoring and outsourcing, with companies hiring H1B visa holders with a pulse.
They overpromise, underdeliver, and screw everyone when all is said and done.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
H with increasing numbers makes a lighter, thinner line. B with increasing numbers makes a darker, thicker line.
HB is basically the middle[1]. Assigning a number to it makes as much sense as saying something is very zero.
(an actual oldtimer, with a preference for 2H)
[1] apart from F, which is stupid, and stands for "fuck off".
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Just out of curiosity, how does this list differ from similar lists made 10 and 20 years ago? Are we learning?
-- Everything is wonderful until you know something about it.
Just look at any Oracle Project that wasn't a DBMS.
Something like Oracle-CRM or Oracle-Financials. I've never seen one of those succeed anywhere. The goal appears to be to get as much money for as long as possible from the client.
After 2 years and 200+ $300/hr Oracle Consultants, management killed each of those projects.
Learned 2 things:
a) Never buy any software that isn't a DBMS from Oracle.
b) Never let any CxO go golfing with anyone from Oracle.
I will admit that the same company pulled the plug after spending $500M on another project - mostly in custom software development off-shore. They believed the SW vendor consultant level-of-effort estimates, which seemed 20x too high for my part of the project.
Of course, what did I know? I'd only been an enterprise architect for 5 yrs, infrastructure architect for 5 years and application architect and lead developer for 10 years. No reason to believe me.
Because of their technical foundation, these projects require managers with hands-on experience and more than a buzz-word grasp of the underlying technologies. What you get are articulate corporate politicians, promoted more for their ambition than any relevant skill. What's worse is that the title is more important than any success on the job. Unless or until things change, simply rinse and repeat.
TFA lists a few big failures. But in isolation that list doesn't mean anything. Are we getting better or worse at implementing big projects? How many multi-million dollar projects were completed successfully versus failed? Humans are not perfect so there will always be failed projects, but there have also been many, many successful ones in the past decade.
I've worked on big IT projects, and I've worked with government people who've worked on them, or managed or procured them. One director at Livermore Labs in the late 80s commented that he'd never seen a billion-dollar computer project succeed - it's just too big to do the communications that are needed to make it work, through the requirements, design, and management parts, and he was trying to work on how to break projects down into things that were small enough that they could be managed and implemented. Even the successful things are messy at large scale.
This was long before Agile (which is pretty tasty Kool-Aid, for some kinds of projects, but has its own limitations).
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
When small projects fail, the contractors move on. By the time large projects fail senior managers need to be promoted.
Over time, people that work on smaller projects are the competent ones, whereas the people that work on large projects have fantastic skills in working in a bureaucracy, but none in actually developing software.
Whenever a large IT project succeeds, some piece of bureaucratic process can and thus will become more complex.
Consider the Australian tax office (or IRS). It costs the same proportion of GDP as it did 60 years ago, before any automation at all. But the tax legislation is several orders of magnitude more complex now. You could simply not support the current mess without a computer, it would have to be kept simple. It is the successful projects that enable the mess to be produced. Fortunately, many tax office projects fail. Imagine how bad things would be if they all succeeded!
http://berglas.org/Articles/Im...
Revisiting the old article, I notice there is only ONE of the 12 failure categories that DOESN'T apply to the project I'm on now! We are so fucked!
People have been making complete fuck-ups of IT projects for as long as there has been IT to make grandiose projects from. And people remain confident that they won't repeat the mistakes of the past in the future. But they do.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"