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
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.
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.
Suggests that management hubris plays a big part in IT Failures.
I think it's a combination of hubris and naiveté. Management and architects look at legacy systems and think all the complexity is unnecessary - that they can implement a "modern" system with the methodology that is in vogue (OOA/OOD, SOA, whatever). Anyone who tries to point out that the complexity is there for a reason is branded a naysayer and ignored. Years later management and architects are still struggling to deal with all the complexities they didn't want to see at the beginning, then the money runs out.
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.
Hey, it's only a stereotype that visa workers are skinny.
Table-ized A.I.
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.
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.
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.