Skip Navigation Links > Process > Rationale

Rationale


The return on investment (ROI) from many software projects is often too low to justify the cost and grim statistics regarding failed software projects become more public every year. Almost every second project is considered a failure in one form or another and those that do go into production are often full of bugs and fail to meet the customer's expectations. If a failed project goes to court, the cost of litigation often exceeds the cost of the development. Why is the situation so bad?

The answer is complex, however it doesn't help that most software projects proceed without a clear understanding of the business imperatives and that analysis and architecture models do not exist in a usable form to guide the construction phase.

Without a process strategy to coordinate work activities a development team has no choice but to operate in an event-driven environment where coding and debugging are the dominate activities and conscious design work is largely omitted. The end result is usually an amorphous design that is either deficient or incomplete since it was achieved in a piecemeal fashion. Also, when design blueprints are not available, programmers end up "coding themselves into a box", meaning they write code unaware of the structure they are creating. Then, one day they attempt to add one more feature only to discover that the structure they have created prohibits this. Software developed in this manner has the following properties:

  • Changes are difficult to make without causing unpleasant side-effects.
  • Defect density remains high despite concentrated debugging efforts.
  • Writing unit-tests is difficult and time consuming. Sometimes even impossible.
  • Low life-expectancy due to the high cost of ownership.

For a new project what often happens is that block, flowchart, network, etc, diagrams are created with a general purpose drawing tool. These diagrams are elaborated with lots of text and tables and the result is organized into a thick requirements/design document and then developers in the role of a programmer are asked to translate the text into working software before some real or arbitrary deadline. Sometimes, thanks to the heroic programming efforts of key individuals and the willingness of management to pay for overtime, these (generally small) projects are built and successfully deployed. However, this is not a sustainable process in the long run, especially if one of the heroes leaves the company or burns out.

On the subject of blueprints, imagine asking a building contractor to construct a house or a factory given only internal and external views of the envisioned building plus some textual requirements describing the type of floor, wall, roof, and ceiling materials. Such information is useful for producing a vision document or perhaps marketing brochures, but they are not certainly not engineering blueprints and no contractor would accept a job without them. Why? Because the chance of success without blueprints for a complex project is very low and failure is bad for business.

Despite all the logic and reasoning against implementing code without blueprints, it is a generally accepted practice in the software development world and we see the results: cost and schedule overruns, poor quality, un-maintainable and fragile code, unhappy customers, stressed out development teams, and sometimes even lawyers must be called in to sort out the mess.

Many of us have observed software development projects where most everyone appeared to be working furiously, but despite all the activity the project itself was making little progress. The following factors are usually part of the problem:

  • Analysis paralysis: Trying to understand everything about the problem before proceeding with design and implementation can absorb all the project resources up front, and leave you with nothing concrete to show for all the effort and expense.
  • Obsession with design: Trying to create the perfect design before committing to code is OK if you're a financially-independent purist or an academic publishing technical papers. However, in real-world projects the customer (i.e. the one paying the bills) will never see the application enter production if the design team is obsessed with finding the perfect abstractions.
  • Hacking code: If you are not working from an architectural design and are trying to figure out what you are suppose to be building as you are writing the code then by definition you are hacking. In the rush to get a product out the door many organizations feel they don't have time to architect or don't believe that architecting provides them with any real value. The resulting headlong rush to code usually leads to a software meltdown and is always disastrous in the long run if you factor in the cost of maintenance.
  • No time to test: Without a formal testing framework and a process to enable and ensure sufficient test coverage, software testing is normally left to the end. The result: low-quality, buggy software.

Ironically, a problem for companies that employ people to develop software is the fact that programming is fun. This partly explains why most developers begin coding before they know what it is they are supposed to be building.

Many developers are accustomed to the "shoot from the hip" approach where discovery, invention, construction, and deployment activities are all performed simultaneously - at the code level. When confronted with a process that specifies an engineering approach, many developers resist because they view this as bureaucratic interference.

So how do you convince developers to accept and use a process they believe will constrain their creativity and hinder their progress? The answer is to walk them through a mini-project that shows that the process and tool chain will make them more productive. In short, a developer cannot be convincing with a PowerPoint presentation. This type of individual will only sit up and take notice when a live demonstration of sufficient complexity is seen to produce positive results at the code level.

There is no shortage of books and articles on the subject of modeling and software development processes, however, if this theory is to be useful it must be possible to apply it to complex projects. It is the purpose of this website to bridge the gap between theory and practice by describing and demonstrating such a process - step by step.

Summary

 

Begin QuoteReturn on investment from most software projects is too low.

 

Begin QuoteStructure and behavior models are necessary to guide the construction phase.

 

Begin QuoteFurious activity is no substitute for understanding.

 

Begin QuoteKnow what you are trying to accomplish before you begin.

 

Begin QuoteFailed projects can result in huge losses in terms of money, reputation, and business.

 

Begin QuoteThe development process must empower developers - not demotivate them.

 

Begin QuoteOnly a live demonstration of the process will achieve buy-in from stakeholders, especially developers.

 

Begin QuoteRelying on heroic programmers to save the day is not a sustainable process.

 

Begin QuoteIf you are trying to figure out what you are building while coding, then by definition, you are hacking.

 

Begin QuoteProducing a good design is hard work. Programming on the other hand is fun.

Top-of-page | Rationale | Principals | Phases | Workflow | Graph