On today’s New York Times op-ed page, Nicholas Carr of “Does IT Matter?” puts the FBI software meltdown in the context of other recent enterprise-scale software train wrecks like McDonald’s Innovate and Ford’s Everest (he could have dragged in the IRS, too). As everyone does who addresses this topic, he references the Standish Group “Chaos” report from 1994, with its dire statistics about software failure.
As with his previous arguments on the topic, Carr gets things just about half right: Of course the record of large-scale software projects, particularly those meant to replace existing systems that are functional but graying, has been awful, and the complexity of these systems remains daunting. Carr concludes that the complexity is so overwhelming we should give up on innovating in software and just concentrate on doing the same things we currently do more efficiently: “When it comes to developing software today, innovation should be a last resort, not a first instinct.”
He’s forgetting that, in the world of software, innovation is the primary way to add value. We move existing “off-line” systems and processes into software not only to make them more efficient, but to give them capabilities the physical world can’t provide. Thus online publishing isn’t just about delivering text and images more cheaply; it’s about connecting publisher and information consumer in new ways that change the whole relationship. Manufacturers implement inventory control systems not just to save money but to transform their businesses so they can build products when customers ask for them, rather than trying to guess what the market needs. If software isn’t providing new capabilities, why bother? It seems obvious that we’re a long way away from exhausting the possible new wrinkles software can offer business, government and society.
Carr is right that large institutions get into trouble when they try to replace big old systems and introduce complex new features at the same time. But his advice — give up on those new features, be happy with what you’ve got — is needlessly ostrich-like. The answer is not to abandon change but to structure change so that it’s not a big bang but an evolutionary process. The failures in so many of these software disasters don’t stem from ambition but from impatience and bad planning.
Post Revisions:
There are no revisions for this post.