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.

Keep It Simple

A simple architecture or a simple algorithm goes a long way toward achieving high maintainability. Remember KISS. Also, as you decompose software into subcomponents, remember that people have difficulty comprehending more than seven (plus or minus two) things at once. C.A.R. Hoare has said:

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.

Build Throwaway Prototypes Quickly

When building a throwaway prototype, build it as quickly as possible. Don't worry about quality, design, documentation, programming language, or maintainability. Just make it functional and into the hands of your customer fast so you can get feedback as soon as possible.

Build the Right Features into a Prototype

"When constructing a throwaway prototype, build only features that are poorly understood."

You can think of it like this - you have started development on a big project and thought you understood all the features. Unfortunately, when you start on feature X you realize that you need more feedback from the customer and you need to provide them a prototype to use to frame the problem.

1. Make a branch from Master.
2. Build feature X in the new branch; we'll call it branch X.
3. Share it with your customer and gather feedback.
4. If the customer is happy with what you did then merge to Master and stop following this list.
   More likely, you continue on along this list.
5. Make another branch from Master; we'll call it branch XY.
6. Build feature X in branch XY using the feedback that was gathered. Pulling in code from branch X where possible.
7. Make sure that the customer is happy then merge to Master.
8. Finally, throwaway that branch X prototype.

By the way, until you are finished with the project, the code you have in your Master branch is really an evolutionary prototype. You want to build the features that are best understood and merge them to Master once you have customer approval. The thing to note is to never merge a feature to Master before it is well understood and approved. Anyone could make a branch from that bad code and you risk it being merged back into Master after you correct the mistake.

Build the Right Kind of Prototype

There are 2 types of prototype:

1. Throwaway
• Quick and dirty. Given to the customer for feedback then thrown away once the information has been gathered.
• Used when critical features are poorly understood.
2. Evolutionary
• Quality. Given to the customer for feedback then modified once the information has been gathered. This process is repeated until the product is completed.
• Used when critical features are well understood but how to combine or present them needs customer feedback. Also used for feedback on minor features.

Communicate with Customers / Users

"Never lose sight of why software is being developed: to satisfy real needs, to solve real problems. The only way to solve real needs is to communicate with those who have the needs. The customer or user is the most important person involved with your project."

It may feel like it is easier to develop in the sweet silence of a vacuum but will the finished software be something that the customer likes or even finds useful? If your customer or product manager is not easily accessible then designate some people on your team to be advocates for your customer. Ask them to imagine being the customer and get their feedback. If possible, have them use the software as if they were the customer and document the good and bad points.

Productivity and Quality are Inseparable

Productivity and quality have a clear relationship in software development.

• Demand for increased productivity will decrease quality (i.e. increase the number of bugs).
• Demand for increased quality (i.e. fewer bugs) will decrease productivity.

This is not a bad thing. Accept it and plan for it. Do not agree to deadlines that are unreasonable and will result in poor quality.

Quality is in the Eyes of the Beholder

It needs to be realized that quality is not the same for all parties. A developer might think it is high performance code or an elegant design. A user might think it is a lot of features. A manager might think it is low development cost. These three examples could be described as speed, features, and cost. Optimizing one might detriment another. Because of this, a project must decide on its priorities and articulate them to all parties.