Give Software Tools To Good Engineers

Users of software tools become more productive. However, a tool cannot convert a poor software engineer (one that produces code that is unreliable, incomplete, and so on) into a good one. Thus, you want to give tools only to good engineers. The last thing you want to do is to provide tools to the poor engineers: You want them to produce less, not more, poor-quality software.

Use Tools, But Be Realistic

Software tools can make their users more efficient and should be used. Remember that the hard work (the thinking) is not done by the tool. Use tools but be realistic concerning the effect on productivity.


Reference:
Kemerer, C., "How the Learning Curve Affects Tool Adoption," IEEE Software, May 1992.

Technique Before Tools

"An undisciplined software engineer with a tool becomes a dangerous undisciplined software engineer."

A software engineer must first understand and be able to follow an appropriate software technique. Next, must know how to use the tool before using a new tool.

Software engineers should first attempt any new software techniques by hand to convince their self and their management that the technique before investing time and money in tools to automate the technique. If the technique doesn't work without automation, it won't work with automation.


Reference:
Kemerer, C., "How the Learning Curve Affects Tool Adoption," IEEE Software, May 1992.

Different Languages For Different Phases

"The industry's eternal thirst for simple solutions to complex problems (Every Complex Problem Has a Solution) drives many to declare that the best software development method would use the same notations for software representation throughout the entire development life cycle. Since this is not the case in any other engineering discipline, why should it be in software engineering?"

"Notations provide us with models that can be manipulated in our minds. The more notations and the richer and more diverse the representations used, the better we can visualize the product under construction."

For requirements engineering, select a set of optimal techniques and languages:

• Use the Right Techniques
• Use Multiple Views of Requirements

For design, select a set of optimal techniques and languages:

• Evaluate Alternatives
• Design Is Multidimensional

For coding, select an optimal language:

• Use Appropriate Languages
• Programming Language Is Not an Excuse

"Transitions between phases are difficult. Using the same language doesn't help. On the other hand, if a language is optimal for certain aspects of two phases, by all means use it."


Reference:
Matsubara, T., "Bringing up Software Designers," American Programmer, July-August 1990.

Record Your Assumptions

"We make approximately one assumption every 10 lines of code, or even if I'm off by a factor of 2 or 3, one assumption every 20 to 30 lines of code." - Manny Lehman

These assumptions about very complex software systems and environments result in unexpected behavior.

Keep track of all your assumptions throughout requirements planning, design, coding, and testing. Also, record the implications of each assumption - where in the product does the assumption manifest itself? Isolate such implications by encapsulating each assumption.


Reference:
Lehman, M., "Software Engineering, the Software Process and Their Support," Software Engineering Journal, September 1991.

Every Complex Problem Has a Solution

"To every complex problem, there is a simple solution... and it is wrong!" - Wlad Turski

Be highly suspicious of anyone who offers you something like, "Just follow these 10 simple steps and your software quality problems will disappear." Or, "Subscribe to our software services and all your monitoring, logging, debugging, etc problems will be solved."

For your interest, Turski's quote is a simplification of the following quote by H. L. Mencken.

Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong.

• "The Divine Afflatus" in New York Evening Mail (16 November 1917)

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.