Plan to Throw One Away

A highly critical factor in the success of a project is whether the project is entirely new. New software treads in new territory and rarely works on the first try.

In 1970, Winston Royce said one should plan for the first fully deployed system to be the second one created. The first is a prototype that flushes out the critical design issues and proves the concept. You should expect to spend 25% of your time and effort in making the prototype. Fred Brooks reiterates Royce's advice in the Mythical Man Month saying, "Plan to throw one away; you will anyway."

When developing a new software application:

• Plan to build a series of throwaway prototypes before starting the final product.
• Build the Right Kind of Prototype
• Build the Right Features into a Prototype
• Build Throwaway Prototypes Quickly
• Expect a software application to be modifiable for a certain period of years, after which it will need to be fully replaced.
• Software Will Continue to Change*
• Software's Entropy Increases*
• Fix Problems, Not Symptoms*
• The System's Existence Promotes Evolution*
• You can only fiddle with an application just so much before it becomes unstable and must be replaced.
• Software's Entropy Increases*
• The Older a Program, the More Difficult It Is to Maintain*
• Maintenance Causes More Errors Than Development*
• Belief That a Change Is Easy Makes It Likely It Will Be Made Incorrectly*

Align Incentives for Developer and Customer

Align developer and customer goals for project success. To align everyone's goals:

1. Prioritize requirements.
2. Reward the developer based on the relative priorities.
3. Define reasonable penalties for late delivery.

Give Products to Customers Early

The most effective way to learn users' needs is to give them a prototype and gather feedback from the experience. This goes perfectly with the Agile Methodology to always deliver after each sprint. Which allows for faster feedback and the product continuously moving toward the customer's desired product.


Reference:
H. Gomaa and D. Scott. 1981. "Prototyping as a Tool in the Specification of User Requirements". Fifth International Conference on Software Engineering. IEEE Computer Society Press., Washington, DC, USA.

Poor Reliability Is Worse Than Poor Efficiency

Poor Reliability

Poor Efficiency

Poor reliability may not be readily apparent and it may be inconsistent. The difficulty in detecting poor reliability contributes to the difficulty in finding a fix for the problem. Efficiency, on the other hand, is usually consistent and easier to isolate. Making a redesign or refactor of the code for better efficiency easier than fixing poor reliability. Which "needle" do you think is harder to find?


Reference:
I. Sommerville. 1992. Software Engineering, Section 20.0. Addison-Wesley., Reading, MA, USA.

Don't Try to Retrofit Quality

It is difficult enough to build quality software from the start of a project. It is much harder to take an existing application and improve it's quality (reliability, testability, adaptability, etc).

This additional difficulty to add quality after the fact is why you must not try to convert a throwaway prototype into a product. Make sure you Build the Right Kind of Prototype.

High-Quality Software is Possible

"Large-scale software systems can be built with very high quality, but for a steep price tag".

Developers, to achieve high quality, follow proven techniques to increase quality. These include:

• Involving the customer.
• Communicate with Customers / Users
• Prototyping to verify requirements prior to full-scale development.
• Build the Right Kind of Prototype
• Build the Right Features into a Prototype
• Build Throwaway Prototypes Quickly
• Keeping the design simple.
• Keep It Simple
• Code reviews and static code analysis.
• Inspect Code
• Hiring the best people.
• Understand the Customers' Priorities
• People Are the Key to Success

Customers (Product Managers), demand excellence but be aware of the high costs involved.

Great Designs Come From Great Designers

The difference between a poor design and a good design may be the result of a sound design method, superior training, better education, or other factors. However, a really great design is the brainchild of a really great designer. Great designs are clean, simple, elegant, fast, maintainable, and easy to implement. They are the result of inspiration and insight, not just hard work or following a step-by-step design method. Invest heavily in your best designers. They are your future.


The Design of Everyday Things

Understand the Customer's Priorities

It is quite possible that the customers would rather have 90% of the system's functionality late if they could just have 10% of it on time. This corollary of software principle, Communicate with Customers / Users, is quite a bit more shocking, but it could very well be the case. Find out!

If you are communicating with your customers, you should be sure you know their priorities. These can easily be recorded in the requirements specification (see Prioritize Requirements), but the real challenge is to understand the customers' interpretation of "essential," "desirable," and "optional." Will they really be happy with a system that satisfies none of the desirable and optional requirements?

Prioritize Requirements

Not all requirements are equal.

One way to prioritize requirements is to suffix every requirement in the specification with an M, D, or O to connote mandatory, desirable, and optional requirements. You may find it helpful to further rate the importance of the requirements by using a scale from 0 to 9. For example, while a M1 task is mandatory, it is not as high a priority as a M9 task.

Inspect Code

Inspection of software detailed design and code was first proposed by Michael Fagan in his paper entitled "Design and Code Inspections to Reduce Errors in Program Development". It can account for as many as 82% of all errors found in software. Inspection is much better than testing for finding errors. Define criteria for completing an inspection. Keep track of the types of errors found through inspection. Fagan's inspections consume approximately 15% of development resources with a net reduction in total development cost of 25 to 30%.

Your original project schedule should account for the time to inspect and correct every component. You might think that your project cannot tolerate such "luxuries." However, you should not consider inspection a luxury. Data has shown that you can even reduce the time to test by 50 to 90%. If that's not incentive, I don't know what could be. By the way, there is a wealth of support data and tips on how to do inspections well in Key Lessons in Achieving Widespread Inspection Use.