| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 | ||||
|
|
|
||
|
||||||||||||||||||||||||||||||||||||||
 NEWSSoftware failure can lead to financial catastrophe By Bruce Abbott, For InfoWorld Test Center September 29, 2000 WE SAT IN A GRAY cafe at 8 a.m., eating gray eggs and gray home fries. Our watery coffee wasn't even strong enough to be gray. Since four o'clock the previous afternoon we had been trying, with little success, to install a relatively simple custom-built software program.
"I've got customers I can't bill because I can't get their data. I've got people waiting to come online but since I can't install the program, I can't get any new cash flow. My business is on the line. My reputation is at stake." Software failure is a terrifying possibility that should scare the bejeezus out of any company looking to stay in business. Although the media inundates us every day with software success stories, news on the growing economy, and reports that the Internet has caused an information revolution that rivals the advent of Gutenberg's printing press, we rarely hear the flip side of this fairy tale: Hundreds of thousands of software projects fail every year. Of course, software companies and IT professionals are not eager to share their disaster stories with the public, which is one reason we don't hear of these doomed efforts. But application failure happens with alarming regularity. In fact, The Wall Street Journal estimates that 50 percent of all corporate technology projects don't meet expectations, and that 42 percent of software projects are abandoned before even getting off the ground. This is scary stuff. Application failure can be cataclysmal. Consider NASA's 1999 mission to launch a spacecraft into the orbit of Mars. Instead of reaching a cruising altitude around the planet, the spacecraft crashed into Mars, destroying itself and kissing $125 million goodbye. Investigators blamed the crash on NASA's failure to convert English rocket thrust measurements into newtons. Ouch. Maybe we shouldn't feel so bad when our little Web sites flop. After all, it's only our jobs and reputations at stake. Complicating the problem Considering all the money and time that goes into these projects, it seems peculiar that the application failure rate is so high. But developers and managers consistently make several mistakes that help explain this phenomenon. First of all, software programs are often made more complex than they need to be. Programming is the art of taking complicated requirements and breaking them down into simple solutions. But sometimes the opposite occurs, and overly complex solutions are used to solve simple tasks. This may be because the programmer does not fully understand the project requirements or is not familiar with the tools used to create simple solutions. Or perhaps the programmer simply does not think simply. Many programmers take deliberate coding joy rides, often using unintended side effects of certain language functions to perform crucial tasks. Repairing such a system is like removing a wall in a house of cards: Have fun playing 52-card pickup. At times the dreaded Wizard of Oz syndrome strikes desperate developers in need of immediate resources. Let's say a manager is seeking a Java programmer for a business-to-business application that is running behind schedule. In his blind desperation, he may hire a Cobol programmer, who although very competent, lacks the training necessary for the Java project at hand. Just as the Wizard of Oz makes the Scarecrow a Doctor of Thinkology, so the manager anoints the Cobol programmer a Java programmer. Because he is clever and hard-working, the Cobol programmer may soon learn the Java syntax. But what the manager ends up with is "Jobol" and a project even further behind schedule. Giving in to temptation Philip Riles of Gemstone Associates, a Sacramento, Calif., company that builds educational software, believes that because software professionals usually come straight out of academia, they are not accustomed to "the real world of budgets and deadlines." Unlike construction workers and auto mechanics, software engineers often choose inventiveness over practicality. Because they are curious and forward-thinking, they often use the latest, most flashy solution where a more mature one might work better. Stephen Flower, author of the book Software Failure: Management Failure, calls this "the lure of the leading edge." By contrast, the newest technology in the construction industry is the cordless drill. No wonder construction workers are better able to keep their minds on the job. Being too agreeable Overoptimism is a dangerous virus that crosses all party lines and one that feeds on itself. Salespeople like to sell it, customers like to believe it, project managers like to hear it. When a manager asks for an estimated date of completion, programmers, eager to please, often respond, "I can whip that out in a few hours," when the answer ought to be, "It seems pretty complex and may take a long time to finish." Optimism makes everybody happy and promises big money -- never mind that it causes false expectations, missed deadlines, untested programs, sloppy coding, and bug-ridden applications. Testing is the No. 1 safeguard against software failure, especially against potent postproduction bugs. Yet testing always gets dropped when a project is under the gun. The project manager, in a rush to meet a promised deadline, is happy to assume that the programmers have conducted sufficient testing on their own. But of course the programmers, under the same pressure and already late on another unrealistic deadline, have had no time to test their software. That's OK, right? After all, nobody makes any money from testing (except testers) and customers never demand more testing over fewer features. With these truths in mind, programmers and managers would rather spend time churning out new code than wasting time testing finished software. And so the bugs take hold. Flip-flopping requirements Changing software requirements is a necessary evil in today's evolving market. Business practices are shifting at such a rapid rate that software models must be very flexible to adapt. Of course, flexibility is good. It allows for some mistakes along the way and also for a fickle customer's new ideas. But it is essential to have a pretty solid idea of your project's requirements before you invest a lot of money in it. Some developers are so confident in the flexibility of their software that they fail to define a sufficient number of specifications at a project's outset. This inevitably leads to costly design tune-ups and a convoluted end result that is difficult to test or is overly complex. The fewer changing requirements, the more direct the distance between your business objective and your application. The truth is that software people love changing requirements. Ever drop by your car mechanic's to replace an $8 hose and learn that what you really need is a new $1,700 transmission? Oh! And you'd better replace the clutch while your transmission is out. Sure, your mechanic is shaking his head and clucking his tongue, but inside he's jumping for joy. He can almost see that big-screen TV in his living room. Software people are the same way. Changing requirements mean more money. Changing requirements also give developers a catchall excuse for failure. The application doesn't work? Well, there were changing requirements. The project isn't on time? A change in requirements held me up. Yes, you ought to utilize today's flexible software to accommodate design modifications. But try to manage your changes wisely and make sure your customer understands the implications of redefining requirements along the way. Missing precious pieces Successful projects require that all involved components and parties work together in perfect harmony. If even one of these components is missing -- and it doesn't have to be the most important or expensive one -- the entire project will come to a screeching halt. These "missing links" cause a bevy of software catastrophes every day. There are many reasons for the missing link. Vendors may go out of business or sell products that do not perform to expectation. Now the project is suddenly way over budget. Someone on your staff may be better at promising than producing results. Now you're way past deadline. And of course Joe, who alone holds crucial information on the project, may get hit by a truck. Now your project is history. To avoid these missing links, managers should use mature products from reliable vendors and make sure there is a strong knowledge overlap among team members. Biting off too much Experience tells us that project success is inversely proportional to project size. A study by the Standish Group reveals that projects costing less than $750,000 succeed 55 percent of the time, those in the $1 million to $2 million range have an 18 percent success rate, and those in the $5 million to $10 million range succeed only 7 percent of the time. The authors of AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, boldly state that "extremely large projects are futile efforts." The Internal Revenue Service's failed $4 billion Tax Systems Modernization Program (TSM) of the 1990s is a glaring example of this tendency. TSM failed because it took a "big bang" approach in which the IRS tried to build a new and gigantic information system to integrate many disparate and out-of-date systems. Having learned from this lesson, Arthur Gross, former CIO of the IRS, declared that the agency would from now on take "an evolutionary approach to modernization," building on systems already in place. Denying the negatives In his book Death March, Ed Yourdon dismisses certain software projects as exercises in futility. These "death march" projects are identified as having at least one key factor 50 percent off reasonable norms. Either the schedule is 50 percent too short, the staff is 50 percent too small, the budget is 50 percent too meager, or the scope of features is 50 percent too large. Many death march projects are caused by dysfunctional organizations in which certain groups won't support each other, goals are unrealistic, and good old-fashioned stupidity reigns. But perhaps the most significant contributing factor to these death marches is the software industry's refusal to acknowledge its own problems. The Standish Group reports that that because the computer industry has a tendency to cover up or rationalize its failures, it continues to make the same planning, programming, and management mistakes again and again. This is very different from practices in other fields, such as construction and engineering, where every disaster is investigated and reported upon. And lucky for us. If bridges collapsed and elevators plunged as often as applications fail, none of us would be here to complain about it. Related article Backup and recovery on an enterprise scale Bruce Abbott is a self-employed Java developer. Send him e-mail at heyabbott@mindspring.com.  RELATED SUBJECTS  Software DevelopmentSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
