By: Tony Di Pollina
The high risks of software development
According to http://www.versionone.com/Agile101/Agile_Benefits.asp “A study in the United Kingdom shows that of 1,027 projects, only 13% did not fail” “A 1995 study of over $37 billion USD worth of US Defense Department projects concluded that 46% of the systems so egregiously did not meet the real needs (although they met the specifications) that they were never successfully used, and another 20% required extensive rework to be usable.”
And according to http://stylusinc.com/Common/Concerns/software_development.php “Fact: A majority of the software projects commissioned never go into production. Software development fails to deliver, and fails to deliver value. The failure has huge economic and human impact.”
Although these statistics sound a bit high to me, still it's true that software development is a risky business. No other industry has even near these failure rates, imagine if a car company had to throw away more than half of the cars they produced.
However most of these risks are avoidable, this blog analyzes what can be done to lower the risks of software development.
You could start a business without having a carefully written business plan, but it’s going to be more risky and expensive.
You could build a small house without first creating design drawings, but the risk of cost overruns will be higher, and the quality won’t be as good. And you definitely can’t build a 20-story building without detailed design plans.
You could build a small software application without first writing a software specification, but the risk of failure will be higher, and in case it doesn’t fail, costs will be higher and quality will be lower. And you definitely shouldn’t write a large software application without a software specification, although it’s not uncommon to see this happening.
A Software Specification, or “spec” for short, is a plan that is written before a software application or module of an application is constructed. Depending on the type of application it can for example describe what are the requirements, what the application will do, how it will do it, what it will look like, the internal architecture, the database, how it will communicate with other applications, and other aspects.
Waterfall and Agile methodologies
There are several methodologies for planning software development; two common ones are the Waterfall method and the Agile method.
The Waterfall methodology was more popular a few years ago but today it has become somewhat discredited, in favor of “lighter” methodologies such as Agile, see http://www.versionone.com/Agile101/Agile_Benefits.asp
In the Agile methodology we “create documentation only when you need it at the appropriate point in the life cycle”, as per http://www.agilemodeling.com/essays/agileDocumentation.htm
Deciding what is needed in a spec
So the Agile methodology tries to make documentation as brief and simple as possible, but not less than what is needed.
But how do you decide what is needed and what isn’t? It’s not that easy.
Just writing a software specification is no guarantee of success, you have to do it right. Otherwise the specification can become a negative for the project. The potential for making mistakes is high, according to http://www.agilemodeling.com/essays/agileDocumentation.htm : “There is no solid relationship between project success and writing comprehensive documentation, and in fact it is more likely that the more documentation that you write the greater the chance of project failure. Have you ever seen a project team write a comprehensive requirements document, get it signed off by your stakeholders, only to have the developers build something else? Or the team actually builds to spec, only to have your stakeholders say that’s not really what they wanted? Or the team delivers late or over budget, even though everything looked good most of the way through the project? Have you ever seen a team create a comprehensive architecture model, have it reviewed and accepted by really smart people, only to see the architecture fail in practice anyway? Or the developers simply ignore the model and then go off and build it the way that they want to? Have you seen all this happen under the guise of management oversight, without management realizing what was happening until long after it occurred?”
From what I’ve seen the 2 main factors needed for writing a good specification are Experience and Motivation.
How much Experience is needed? I guess it varies with each person, but I've observed that generally at least 20 years.
What kind of Motivation is needed? I talk more about this in the ‘Motivation’ section below, but in short, I’ve found that the highest motivator is when the failure of a software project directly affects your own wallet, although there are other ways that analysts can be motivated, such as demonstrated by successful large software companies.
Poorly written specifications have discredited the usefulness of specifications, and it’s common to see programmers that don’t believe that they are needed. According to http://www.agilemodeling.com/essays/agileDocumentation.htm “One of the greatest misunderstandings people have about the concept of traveling light is that it means you don’t create any documentation. The reality is that nothing could be further from the truth. What traveling light does mean, at least in the context of AM, is that you create just enough models and just enough documentation to get by.”
A common mistake is to underestimate the complexity and risks of a software project. Software development can seem deceptively simple at the beginning of a project, it's easy to quickly put together a couple of screens and write some code to provide basic functionality. But as the project progresses, the problems due to lack of planning start becoming more evident. The team starts wondering if its a good idea to go forward. But they can't go back either because they already have too much invested. At this point the words 'quagmire' and 'Vietnam' may come to mind.
According to http://goldpractice.thedacs.com/practices/frm/ : “Rather than meeting risks head on, however, and despite increased efforts to promote sound risk management processes, the software industry, as a whole, tends to be in denial about whether risks exist on their programs and, if they do, how they should go about addressing them.”
For a humorous look at this, search in google for “real programmers don’t write specs”
As important as good specs are to ensure the success of a software application, I’ve noticed that an even greater risk is writing a software application that, even if successfully built, cannot be sold, because the market doesn’t need it as much as we thought, or because there are competitors with a better business model and a better business strategy.
During the dot-com boom and subsequent bust in 2000 (see http://en.wikipedia.org/wiki/Dot-com_bubble ), it became evident that many companies built software applications without first having a strong business model to support it. I know because my company Trade-direct was one of them.
Therefore before writing a spec it’s a good idea to make sure that we have made an analysis that answers the following questions:
- Do we have good business model?
- Do we have a good business plan that includes a careful business risk analysis?
- Do we have a good marketing plan, tightly coupled with the technology plan?
Analysis of technical alternatives
When writing a spec, before we get into the details of use cases and class diagrams, it’s a good idea to analyze what are the technical alternatives, and try to answer the following questions:
- To provide the solution, should we Buy or Build? Consider that each line of code that we write will have a future maintenance cost, so we should provide the solution by writing the least amount of code.
- For the ‘buy’ option, have we considered all technology options, including high quality and free open source solutions (such as Drupal, Moodle, Mediawiki).
- Are we reinventing the wheel?
- Are we using proven, stable, and scalable technologies?
- Have we broken up the complexity as much as possible? Remember that the bigger and more complex an application is, the higher is the risk of failure. Could we instead break it up into loosely-coupled smaller modules that communicate via web services (SOA)?
- Are we unnecessarily creating a data center when we could instead simply and inexpensively lease servers over the cloud using services such as Amazon EC2?
We can hire the smartest people, use the best methodologies, apply the best project management techniques, but if the people don’t have a high level of motivation, then the project probably won’t be successful.
How to motivate programmers is a question that even some of the best software companies struggle with, including Yahoo, RIM, and Microsoft.
According to http://informationr.net/ir/7-3/paper129.html : “Software development methodologies attempt to reduce risk by gathering information and using structured processes. The implicit assumption is that by following a good methodology and identifying risk factors, software risk is reduced enough to avoid failure. However, a continuous stream of software failures may be a hint that there are risks that cannot be overcome by traditional approaches to software development. One key factor is the behaviour of decision makers using any methodology. Markus (1983) showed the importance of power and politics on software success, demonstrating how an individual’s motivation can have a dramatic impact on the success of a systems implementation. Introducing a better software development methodology into such a situation would not likely have change the results. By contrast, changes in personnel motivation had on overwhelming impact on success.”
“Much research in software development has focused on risk management identifying risk factors and developing methodologies to prevent these factors from resulting in software project failures. However, despite the many advances in software development methodologies, software failures still occur and may even have increased. One issue not addressed in the information systems literature very much is that people often insist that they want to be their own risk managers and thus balance their individual risks and rewards. Motivations and self-interest may also contribute to software project failures. Thus, modern software development methodologies by themselves do not guarantee project success.”
The size of the company is an important factor. Even though companies like Facebook and Apple have demonstrated that you can be a large company and at the same time be nimble, I’ve noticed with my own company that it was much easier when we had 10 people than when we had 30. The strongest motivator that has forced me to find a way to make software projects successful was when the failure of software projects put my company at the risk of financial insolvency, affecting my own wallet. So it’s probably no coincidence that the average size of software companies in San Francisco is only 20 employees.
However it's also possible to create high motivation in a large company, buy this blog is already getting too long to get into this.