Build Software So That It Needs a Short Users' Manual

One way to measure the quality of a software system is to look at the size of its users' manual. The shorter the manual, the better the software. The use of well-designed software should be mostly self-evident. Unfortunately, too many software designers fashion themselves as experts in human interface design as well. The voluminous manuals that result are sufficient evidence that most interface designers are not as great as they proclaim.

Use standard interfaces. Use industry experts to design self-evident icons, commands, protocols, and user scenarios. And remember: Just because software developers "like" an interface, it doesn't mean that your customers will have any idea of how to use it. Many software developers like interfaces with built-in short-cuts. Usually, customers want simple, clean, clear interfaces - they don't want to learn tricks to enable short-cuts.


Reference:
Hoare, C.A.R., "Programming: Sorcery or Science?", IEEE Software, April 1984.

If Possible, Buy Instead of Build

Off-the-shelf software may address only some of your feature needs. But consider that building your own software may result in going over budget, being late, and still only addressing only some of your feature needs.

"As a developer, you should reuse as much software as possible. Reuse is 'buying instead of building' on a less grand scale."


Reference:
Brooks, F., "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computer, April 1987.

Change During Development Is Inevitable

Software will change during development! The changes might be refactoring code, adding new tests, changing requirements, or adding new requirements. The changes could be as simple as fixing bugs, or general improvements.

Prepare yourself for changes by making sure:

• that all software development is appropriately cross-referenced,
• Record Why Requirements Were Included
• Trace Design to Requirements
• Trace Tests to Requirements
• that change management procedures are in place, and
• Establish SCM Procedures Early*
• Give Every Intermediate Product a Name and Version*
• Rank and Schedule Change Requests*
• that budgets and schedules have enough leeway so that you are not tempted to ignore necessary changes just to meet budgets and schedules.
• Don't Set Unrealistic Deadlines*
• Avoid the Impossible*
• Avoid Standing Waves*

Reference:
Bersoff, E., V. Henderson, and S. Siegel, Software Configuration Management, Englewood Cliffs, N.J.: Prentice Hall, 1980, Section 2.2.

The More Seen, the More Needed

"The more functionality (or performance) that is provided to a user, the more functionality (or performance) that the user will want."

Which supports:

• Give Products to Customers Early
• Grow Systems Incrementally
• Software Will Continue to Change
• The System's Existence Promotes Evolution

More importantly, you must be prepared for the inevitable requests for more.

• Documentation should be organized in such a way that it is easy to update and add to.
• Establish SCM (Software Configuration Management) Procedures Early.
• Systems and processes in place to handle the users' requests.
• Design so that configuration is quick and easy.

Reference:
Curtis, B., H. Krasner, and N. Iscoe, "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, 31, 11 (November 1988), pp. 1268--1287.

Grow Systems Incrementally

Reduce risk when building a software application by growing it incrementally. Start with a small working system with only a few features. Then incrementally add new features working toward the final functionality. This helps lower risk with each build and provide the customer information about the product over time. The downside is that if an inappropriate architecture is used early on, it might be incompatible with later features and require a redesign. This risk can be reduced by building throwaway prototypes of all the major features early on.

• Build the Right Kind of Prototype
• Build the Right Features into a Prototype
• Build Throwaway Prototypes Quickly

To everyone familiar with the Agile Methodology you'll no doubt see the similarities.


Reference:
Ruskin, R., Debugging Techniques in Large Systems. Prentice Hall. Englewood Cliffs, NJ, USA, 1971.

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.