LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Imagination, process failures doom software projects


By David Worthington
November 2, 2009 — 
Scores of well-publicized software failures have taken a toll on careers, lives and resources, yet projects continue to fail at an alarming rate. Top programming experts, though, say that there are commonalities to these failures that, if avoided, can help organizations achieve greater success.

Sixty-eight percent of software projects were either challenged or failed, according to The Standish Group's 2009 "Chaos" study, representing a "marked decrease in project success rates" for the year. Challenged projects are defined as being late, over budget, or having less than the required features and functions.

The root causes of failure are not difficult to identify. "Most cases of failure that I have seen have been in two categories: imagination and process," said Grady Booch, chief scientist of software engineering at IBM Research.

Common process problem areas that were cited by the experts include requirements failures, failure to validate and verify requirements, failure to adhere to architecture, lack of contingency planning, failure to learn from mistakes, and the absence of best practices in developing conversion software.

An implementation of a requirement that seemingly is correct might actually be incomplete. For example, a Pennsylvania man could not receive a driver's license after a computer system indicated that he was dead, because programmers did not include any way to "resurrect him," said Richard Riehle, a visiting professor at the Naval Postgraduate School, a U.S defense institution in Monterey, Calif. that provides education and research programs for the United States and its allied forces.

In another example, Riehle recalled, "A laser-guided missile that depends on a forward ground crew that focuses the laser on a target will go to the coordinates of the laser beam. During the combat operations, the battery on the laser unit begins to fade. No problem. It is designed for a hot-swap capability. The software, however, was not designed for hot-swap and, without notifying the ground crew, resets the coordinates to origin after completing the hot-swap. Oops!"

Some organizations have lacked a process for judging the risk of requirements, or incrementally examining risk as they do something new along the way, Booch noted.

Adding requirements incrementally, and then delivering the result in a "big bang" release, is another mistake, Booch said. When the U.S. Federal Bureau of Investigation completed its Virtual Case File system in 2005, "Everyone looked and said, 'This is not something that we want,' " after seeing that it was incomplete and error prone, he said.

Consequently, the FBI had to answer to the U.S. Congress, which scrapped the project in January 2005.

The government also failed to assess the cost of those additional requirements, he added, and the project cost soared to over US$100 million.

Communication breakdown
Salon.com founder Scott Rosenberg concluded in his seminal book “Dreaming in Code” that most software failures stem from breakdowns in human communication in a software team or between the team and the people commissioning the software. Rosenberg called Windows Vista one of the biggest failures in recent times and said that it experienced a requirements failure, as the company set out with too many "conflicting ambitions and too few resource constraints," leading to an "organizational breakdown."

Programmer's hubris is also something to look out for, Riehle said. "An early version of the Airbus crashed because the pilot could not wrest control away from the computer and restore the airplane to a safe altitude. The software developers apparently knew more about flying an airplane than the pilot."

In the U.S. Department of Defense, where lives count on mission-critical systems performing as expected, software quality is verified by validating whether the software does the job it is intended to do and whether it is doing the job correctly, Riehle said.

Many developers glaze over that practice. Sometimes software does extra things that no one intended it to do, he noted, such as a programmer's “Easter egg," an intentionally hidden joke or feature. But other unintended behaviors can be far less innocuous.

The Therac X-ray therapy machine killed five patients and seriously injured others when algorithms were largely correct, but the precision of the floating-point numbers was off, he said. Consequently, a typist could inadvertently trigger a race condition, where the software did not detect a lethal series of events, leading to high-intensity radiation beams striking patients.

Another example is in banking, where a failure might occur due to faulty algorithms. "I recall such a system where the interest calculations were in error, and it took months to restore the system to its proper state for thousands of customers of the bank in question," Riehle added.

Aside from process mistakes, there is also "tremendous opportunity cost" when organizations go down the wrong path, Booch said. "When programmers fail to be nimble enough to make systems do 'y' instead of 'x,' it is a failure of imagination. It is less public, but equally if not more devastating to organizations, and I tend to encounter it the most."

The aforementioned FBI case file system failure was not only a failure in process, it was a failure in imagination, Booch said. He added that the FBI could have done "incredible things," but chose to do the wrong things instead.

Learning from mistakes
The primary lesson that should be learned from those aforementioned failures is that "the fundamentals never go out of style," Booch said. He recommends that organizations build software in an incremental and iterative fashion with a focus on testing.

Architecture should also be used as an artifact for governance, Booch added. "Treating architecture as an important artifact gives you something to have a handle onto. You look at the dials and see if you are going off rails, and have levers to control going forward. Failures go off rails of the process."

When failure does occur, organizations should have recovery and control procedures in place, said Riehle. He provided the real-world example of two banks in the same town, on the same street, that are being serviced by the same computer in the same service bureau.

One bank has manual controls in place to minimize disruption in teller lines; the other hangs up a sign saying, “The computer is down. Sorry for the inconvenience," Riehle said.

"In this case, one bank understands the vulnerability associated with computer systems and creates a contingency plan. The other remains unprepared and fumbles the ball."

Unfortunately, many organizations that do experience failures are doomed to repeat them. Organizations have institutional amnesia because they never do post-mortems to understand what they need to do better next time, Booch said. "It’s not a contributing cause [this time], but it's a contributing cause to the next failure."

Organizations should not "flog themselves," he said. "Grieve, but don't just walk away from it." Finger-pointing that persecutes is also unhelpful, he added, stating that the end result should be institutional policies to make certain that mistakes won't happen again.

Booch cautioned against overreacting, which he said could "harm innovation. Organizations should have a light touch," he said.

However, there are some circumstances that warrant a heavier hand. As an example, many organizations fail to convert a legacy system to a new one by not following the complete process that would be applied to a new software project, Riehle said.

For example, the development of conversion software is handed to the most qualified programmers and systems analysts, but important tasks such as data conversion are left to a relative novice, Riehle said. The data conversion software is not rigorously tested, he explained.

Consequently, he said, "No one checks on it very carefully. The new system, with incorrectly reformatted data runs perfectly—except the data in many of the accounts is wrong from Day 1. There are often data items in the old system that do not directly correspond to data items in the new system.

”I chose these cases because they are not obvious to the layperson," Riehle explained. "They actually happened on real software systems." And the layperson rarely hears about how common development failures happen.

The cases outlined in this article represent a large class of failures where things are built and "chucked out," or scrapped entirely, Booch said. Some are simply a lost opportunity, but others were in full operation with critical errors.

Many failures don't often get press, he said. "They are shuffled away, but millions, if not tens of millions [in currency] are spent. The system does not do what you'd imagine it would do."

In each case, Booch concluded, a set of expectations is not met—in subtle ways or catastrophic ways.


Related Search Term(s): QA


Share this link: http://www.sdtimes.com/link/33870
 

Comments

11/02/2009 02:48:26 PM EST

Interesting article. There is, additionally, another key reason for project failures: lack of viable cost & schedule estimates http://www.galorath.com/index.php/library/abstract/a-case-for-software-estimation/ in the first place along with insufficient tracking and control during development. Many say more projects fail due to lack of planning than any other reason. Hence programs end up on “death marches” http://www.yourdonreport.com/index.php/2007/11/27/death-march-presentation-download/ get canceled after huge wastes of resources, or ever provide business value sufficient to justify their cost. According to Donsani 80% of projects cost more than they return.

United StatesDan Galorath


11/03/2009 04:55:27 AM EST

It seems that every time I read an article on software project failure the writers attribute such failures to just about the same issues they have been arguing over for the past 30+ years. As a senior software engineer for 35 years I have seen these very same arguments in fact cause countless project failures. Surprisingly the rate of failure has hovered around the 70% mark for the same length of time. However, the problems and issues analysts write about are merely symptoms of much deeper problems in the field of software development. Where the majority of problems stem are from the underlying sociological basis for software development as whole. At the top-most level you have a host of bad management who barely understands both the technical and Human dynamics that go into making quality software. Most managers who believe they know a lot about such development are often extremely poor about understanding the necessities of the process from an overall process. Most technical managers, especially in the realm of business applications are nothing more than political hacks who are there to push projects through for the purposes of deadlines they have too often readily agreed to leaving quality as something you push on the developers after the fact. The next issue are the vendors themselves. Like most technical managers they are attempting to push software out the door to beat competition instead of deadlines, which are in themselves deadlines. The software is then full of bugs leaving software developers to develop timely work-arounds at crucial points in their projects. Then of course you have the avalanche of software that vendors keep on producing with new versions having newer technologies and methodologies included in every new release making it impossible for the software development community to develop a solid knowledge base whereby the issues and problems have ready answers. The last time such a knowledge base existed was with Windows 3.1. Finally, you have the massive ongoing dislocation that is constantly occurring to the software development community itself. With the rush to constantly save costs under the argument of increased competition, companies are abandoning any sense of commitment to the actual developer community themselves leaving them in massive states of insecurity. This in turn leads developers to concentrate on understanding technology for interviews and not good project development. Of course, you have the competitive spirit among software developers who are always attempting to work with the "latest and greatest" technologies but this again is a factor of the constant state of flux of the field that has jettisoned quality as a keystone to professional development for random knowledge. These contentions are basic generalities but they encompass the underlying factors for why software failure is a constant in the Information Technology field. After 30+ years of the same issues with the same reasons for them you would think that business would finally allow for some positive change in the software arena. However, this will never happen since business leaders tend to be very short-sighted and with very narrow priorities that always make up the realms which they make decisions within. Running off to India, China, and other such countries may have resolved some of the more short-term issues such as costs. However, in the long run such policies and endeavors have created a havoc in the industry that it cannot readily extricate itself from. The result will be merely more project failure and more articles like this one...

United StatesSteve Naidamast


Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading