of quality in the code. Read the descriptive comments for each element and the indication of where the proper types can be found, as in the case of pmd_cputype being from enum pmc_cputtype.

One final comment on this file. Note that the programmer is writing objects in C. Operating-system kernels and other low-level bits of code are still written in C, and though there are plenty of examples now of people trying to think differently in this respect (such as Apple’s Mac OS X drivers being written in C++), low-level code will continue to be written in C. That does not mean programmers should stop using the lessons they learned about data encapsulation, but rather that it is important to do the right thing when possible. The structure listed here is an object. It has data and methods to act upon it. The BSD kernels have used this methodology for 20-plus years at this point, and it’s a lesson that should be learned and remembered by others.

These are just a few examples from this code, but in file after file I have found the same level of quality, the same beautiful code. If you’re truly interested in seeing what good code looks like, then I recommend you read the code yourself. If any place is a “happy place,” it is in code such as this.

Dear Atypical,

What do you mean by “formerly known as trial and error”!?! Are you telling me that this fad has died? As far as I can tell, it’s alive and well, though perhaps many of its practitioners don’t actually know their intellectual parentage. Actually, I suspect most of its practitioners can’t spell intellectual parentage.

Alas, it is often the case that a piece of good advice is
taken too far and becomes, for a time, a mantra. Any-
thing repeated often enough seems to become truth.
Mr. Brooks’s advice, as I’m sure you know, was meant
to overcome the “it must be perfect” mantra that is all
too prevalent in computer science. The idea that you
can know everything in the design stage is a fallacy that
I think started with the mathematicians, who were the
world’s first programmers. If you spend your days looking
at symbols on paper, and then only occasionally have
to build those symbols into working systems, you rarely
come to appreciate what happens when the beauty of
your system meets the ugly reality that is hardware.
From that starting point, it’s easy to see how program-
mers of the 1950s and 1960s would want to write every-
thing down first. The problem is that a piece of paper
is a very poor substitute for a computer. Paper doesn’t
KV have odd delays introduced by the speed of electrons
in copper, the length of wires, or the speed of the drum
(now disk, soon to be flash). Thus, it made perfect sense
at the time to admonish people just to build the damned
thing, no matter what it was, and then to take the lessons
learned from the prototype and integrate them into the
real system.

The increasing speeds of computers since that advice was first given have allowed people to build bigger, faster, and certainly more prototypes in the same amount of time that they could have built a single system in the past. The sufferers of prototypitis are really just chicken. Not putting a line in the sand is a sign of cowardice on the part of the engineer or team. “This is just a prototype” is too often used as an excuse to avoid looking at the hard problems in a system’s design. In a way, such prototyping has become the exact opposite of what Mr. Brooks was trying to do. The point of a prototype is to find out where the hard problems are, and once they are identified, to make it possible to finish the whole system. It is not to give the marketing department something pretty to show potential customers—that’s what paper napkins and lots of whiskey are for.

P.S. Complete code cross-references for many operating-system kernels, including FreeBSD, can be found at http://fxr.watson.org/, and the code you’re looking for can be found at http://fxr.watson.org/fxr/source/dev/ hwpmc/. A similar set of cross-references can be found on the codespelunking site: http://www.codespelunking. org/freebsd-current/htags/.

Dear KV,

In his book The Mythical Man-Month, Frederick P. Brooks admonishes us with grandfatherly patience to plan to build a prototype—and to throw it away. You will, anyway.

At one point this resulted in a fad-of-the-year called prototyping (the programming methodology formerly known as trial and error), demonstrating that too little and too much are equally as bad.

What is your view of creating prototypes, and, particularly, how faithful does a prototype need to be to resolve the really tricky details, as opposed to just enabling the marketing department to get screen shots so they can strut the stuff?

Signed,

An (A)typical Engineer