My Approach

The software development industry is loaded with buzzwords and people making grandiose promises that their software/methodology will solve all your problems. Despite all of these wondrous claims, a report released by The Standish Group in 2009 indicates that we (software professionals) are actually not that good on delivering on these promises. The reports states:

“This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” says Jim Johnson, chairman of The Standish Group, “44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.” (See: CHAOS Summary 2009)

The book “Facts and Fallacies of Software Engineering” by Robert L. Glass mirrors this sentiment and points out a number of probable causes for this poor performance including:

Fact 5:

Hype is the plague on the house of software. Most software tool and technique improvements account for about a 5 to 35 percent increase in productivity and quality. But at one time or another, most of those same improvements have been claimed by someone to have “order of magnitude” benefits.

Fact 8 & 23: (combined and paraphrased)

The two most common causes of runaway projects (those that go over time and budget) are poor estimation and unstable requirements.

Fact 9:

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.

Fact 10:

Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.

Fact 11:

Software estimates are rarely adjusted as the project proceeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.

There are many other reasons that one could site as possible causes for the high failure rate of projects in the software industry, but if one takes a look at the list above, it would seem that a running theme is that
we are simply not realistic about the process in general. Rather than evaluating if the process we employ actually work, we assume they work and when a project fails, look for explanations of the failure elsewhere (blame the people not the process).

Based on the assumption that a large part of the problem in the software field is that we are simply unrealistic about how we do things, my approach is as follows.

• Admit when you do not know something and takes steps to learn about what you do not know (research it). Not knowing something is not a weakness or a deficiency, but rather and opportunity for improvement.
• The first step in any software project is to identify the problems to be solved. What is it you are trying to accomplish? If you don’t know that, how can you possibly do anything else?
• Once the problems to be solved have been identified, find out what solutions currently exist and evaluate them. If none exist, or none of them are satisfactory, then look at coming up with your own
  solution.
• Related to the previous point and Glass’s Fact 5, don’t simply assume that the latest and greatest out there is the optimal solution to your problems. Older more proven solutions may exists that you may over
  look in favor of using the latest technology.
• If a process or tool does not seem to be working, examine why and don’t be afraid to adapt it if it is not working.

If this approach sounds interesting and you have a consulting opportunity that you would like to contact me about, I can be reached via any of the methods found in the footer of this site.