Write Programs For People First

In the early days of computing, computers were relatively slow. Almost anything that could be done to shave off a few instructions was worth the effort. The most efficient use of any of the resources on the very expensive computer system was the major goal. Things have changed. The most valuable resources is now people: people to develop the software, people to maintain the software, and people to enhance capability. With few application exceptions, programmers should think first of the people who will later attempt to understand and adapt the software. Anything that can be done to assist them should be done.¹ Efficiency is also important,² but they are not mutually exclusive. If you need efficiency, that's fine but upgrade the readability of your program so that you don't lose the humans in the process.

1. Avoid Tricks
   Avoid Global Variables
   Write To Read Top-Down
   Avoid Side-Effects
   Use Meaningful Names
2. Evaluate Alternatives
   Use Efficient Algorithms
   Get It Right Before You Make It Faster

Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Use Meaningful Names

Some programmers insist on naming variables with names like nflt or nFlight. The usual argument is that it makes programmers more productive because of reduced key presses. Good programmers should spend a very small percentage of their time typing (maybe 10 to 15 percent); most time should be spent thinking. So how much time is really being saved?

A better argument is that overly shortened names actually decrease productivity. There are two reasons:

1. Testing and maintenance costs rise because people spend time trying to decode names, and
2. more time is spent typing comments to explain the shortened names!

Reference:

Ledgard, H., Programming Proverbs, Rochelle Park, NJ: Hayden Book Company, 1975.

Avoid Side-Effects

A side-effect of a procedure is something the procedure does that is not its main purpose and that is visible (or whose results are perceivable) from outside the procedure. Side-effects are the sources of many subtle errors in software, that is, the ones that are the most latent and the ones that are most difficult to discover once their symptoms manifest themselves.


Reference:
Ledgard, H., Programming Proverbs, Rochelle Park, NJ: Hayden Book Company, 1975.

The Whole Art of Detection

The Whole Art of Detection: Lost Mysteries of Sherlock Holmes by Lyndsay Faye
My rating: 4 of 5 stars

I enjoyed Lyndsay Faye's style. She makes Sherlock Holmes into a little bit more of a gentleman, which is pretty cool.

This book follows a journal format and skips back and forth with regard to time and sometimes point-of-view. I imagine that in the print version there is whitespace that indicates a context switch. However, in the audiobook, there really isn't much of a warning.

Overall, a good book. I want more Sherlock Holmes!

View all my reviews

Write To Read Top-Down

People generally read a program from top to bottom. Write your programs to help others understand them. Among the implications of this principle are:

1. Include a detailed external specification up front to clearly define the program purpose and use.
2. Specify externally accessed routines, variables, and algorithms up front.
3. Use the "structured" programming constructs, which are inherently easier to follow.

Reference:

Kernigham, B., and Plauger, P., The Elements of Programming Style, New York: McGraw-Hill, 1978.

Avoid Global Variables

Global variables make it convenient to write programs; after all, if you need to access or change x, you just do it. Unfortunately, if x is ever accessed and found to have an inappropriate value, it is difficult to determine which software component is at fault. "Global" implies that anybody could have altered its value incorrectly.

As an alternative, encapsulate important data in its own module, so that anybody who wants to change it or access it must do so by means of that routine. Alternatively, explicitly pass parameters to routines that need specific data. If you find an excessive number of parameters, perhaps your design needs to be reworked.


Reference:
Ledgard, H., Programming Practice, Vol II, Reading, MA: Addison-Wesley, 1987.

Avoid Tricks

Many programmers love to create programs with tricks. These are constructs that perform a function correctly, but in a particularly obscure manner. Typically, they use a side-effect of a function to implement a primary function. Programmers see these as "clever," but, as Allen Macro points out, they "are often merely the stupid use of high intelligence."
    There are many ways to explain why tricks are used so often:

1. Programmers are extremely intelligent and want to demonstrate that intelligence.
2. Maintainers, when they finally figure out how the trick works, will not only recognize how smart the original programmer was, but also will realize how smart they themselves are.
3. Job security.

Bottom line: Show the world how smart you are by avoiding tricky code!

Reference:

Macro, A., Software Engineering: Concepts and Management, Englewood Cliffs, NJ: Prentice-Hall International, 1990.

Software Reliability Can Be Achieved Through Redundancy

In hardware systems, high reliability or availability (Specify Reliability Specifically) is often achieved through redundancy. Thus, if a system component is expected to exhibit a mean-time-between-failures of x, we can manufacture two or three such components and run them in either:

1. Parallel. For example, they all do all the work and, when their responses differ, one is turned off with no impact on overall system functionality.
2. Or cold standby. A backup computer might be powered on only when a hardware failure is detected in the operational computer.

Manufacturing cost is slightly more than doubled. Design cost increases slightly. Reliability increases exponentially.

    In software systems, we cannot use the same approach. If we make two copies of the same software, no increase in reliability will be achieved. In one fails, the other will as well. What can be done, however, is to design (using two different design teams) two versions of the software from the same requirements specification, and deploy them in parallel. Development cost doubles. Reliability increases exponentially. Notice that, in the case of hardware, design increases in cost only slightly, whereas software design cost (the primary cost of software) doubles. Ultrahigh reliability in software is very expensive (High Quality Software Is Possible).

Reference:

Musa, J., et al., Software Reliability, New York: McGraw Hill, 1987.

"Garbage In, Garbage Out" Is Incorrect

Many people quote the expression "garbage in, garbage out" as if it were acceptable for software to behave like this. It is not. If a user provides invalid input data, the program should respond with an intelligent message that describes why the input was invalid. If a software component receives invalid data, it should not process it, but instead should return an error code back to the component that transmitted the invalid data. This mindset helps diminish the domino effect caused by software faults and makes it easier to determine error causes by 1) catching the fault early and 2) preventing subsequent data corruption.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Imposter Syndrome

All fields have some amount of imposter syndrome. It happens in Software Engineering a lot. Constantly changing technologies and changing projects can catch a person off-guard and overwhelm them. Often the problem is only in your head. You actually are doing fine, or would be if you gave yourself a chance. Peter J. Denning wrote an excellent article about this called The Beginner's Creed. The creed is all about learning to be expert beginners so new technologies and projects don't overwhelm us.