Provide All The Information The User Needs And Nothing More

A key part of the design process is the precise definition of each and every software component in the system. This specification will become the "public" part of the component. It must include everything a user needs, such as its purpose, its name, its method of invocation, and details of how it communicates with its environment. Anything that the user does not need should be specifically excluded. In most cases, the algorithms and internal data structures used should be excluded. For if these were "visible," users might utilize this information. Subsequent enhancement or modification then becomes profoundly more difficult because any change to the component has a cascading effect on all components that use it (related to encapsulation).


Reference:
Parnas, D., "A Technique for Software Module Specification with Examples," CACM (May 1972).

Use Efficient Algorithms

Knowledge of the theory of algorithm complexity is an absolute prerequisite for being a good designer. Given any specific problem, you could specify an infinite number of alternative algorithms to solve it. The theory of "analysis of algorithms" provides us with the knowledge of how to differentiate between algorithms that will be inherently slow (regardless of how well they are coded) and those that will be orders of magnitude faster. Dozens of excellent books exist on this subject. Every good undergraduate computer science program will offer a course on it.


Reference:
Horowitz, E. and Sahni, S., Fundamentals of Computer Algorithms, Potomac, MD: Computer Science Press, 1978.

Howl's Moving Castle

Howl's Moving Castle by Diana Wynne Jones
My rating: 5 of 5 stars

Just as another reviewer said the movie made me want to read the book. The catch is either I don't remember the movie or the book is different enough that I can't link them in my mind. Doesn't really matter. I enjoyed the book. I think Calcifer was my favorite character. I'd like to know why he fell.

View all my reviews

Gather 'Round the Sound

Gather 'Round the Sound by Paulo Coelho
My rating: 3 of 5 stars

Good short stories that fit the season. Be warned the first story, "12345," is a bit of a tear jerker.

View all my reviews

Light Falls: Space, Time, and an Obsession of Einstein

Light Falls: Space, Time, and an Obsession of Einstein by Brian Greene
My rating: 5 of 5 stars

Exciting and revealing. Provides insight into the passion that drove Einstein while working on a theory of general relativity.

View all my reviews

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.