There are two approaches to building a quality product: build it in from the beginning, or beat it in afterward. The former approach requires a lot of discipline and effort from the engineering team. The latter requires a lot of testing and, again, effort from the engineering team.

I take it as a given that any product should be a high-quality product. Why bother making it otherwise? This seems like a straightforward goal, but the technology industry has had a hell of a time figuring out how to build quality software. There’s a joke that’s been around for at least a decade:

There’s word in business circles that the computer industry likes to measure itself against the Big Three auto-makers. The comparison goes this way: If automotive technology had kept pace with Silicon Valley, motorists could buy a V-32 engine that goes 10,000 m.p.h. or a 30-pound car that gets 1,000 miles to the gallon—either one at a sticker price of less than $50. Detroit’s response: “OK. But who would want a car that crashes twice a day?”

Any good joke has an element of truth to it—this one especially so. Auto makers can build cars that’ll drive hundreds of thousands of miles, but Windows 95 would crash after 49.7 days of continuous operation—a bug that took four years to discover 1 because other bugs would crash Windows 95 long before 49.7 days could pass.

Portrait of my grandmother. I don't consider myself a portrait artist but I do get lucky once in a while. On-site lighting was two flashes bounced off the ceiling. Photo toned to black-and-white using Exposure 2 and vignetted with Bokeh.

These days, there’s a lot more layers involved. Taking the “simple” example of C++, the layers could look like this:

In this example, the physical machine is a x86, 64 bit. The machine’s architecture has various ramifications, for example a 64 bit machine can allow a single process to address much more memory than a 32 bit machine. The operating system has numerous implications; any “system call” like accessing a file goes through the operating system. Then there’s the libraries, for example the C standard library which provides functions like printf() for formatted output. Then there’s the programming language itself.

In college you likely focused on one “do it all” language like Java. There’s nothing wrong with Java, in fact it’s a great language. The problem is the “do it all” part—no language does it all, at least not well. You simply cannot be productive and versatile without knowing a couple programming languages.

Programmers are pessimistic and sarcastic lot. The vast majority will tell you about a hundred things that suck for every one thing that doesn’t. The highest praise a programmer will give a product is, “it doesn’t suck.”

Pessimist programmers are in good company. I’ve read various reports saying the vast majority of projects fail. 80 or 90 percent. Adding insult to injury, it’s not the good 10 or 20 percent that succeed, it’s some hodgepodge of good and bad. It almost seems that bland to downright crappy products are more successful, on average, than really good ones. When a programmer says such-and-such sucks, chances are he’s right.

Executives and managers like to think they’ve got it all together. Walk with some swagger, put on the game face, don’t show weakness. Just as you learned about your parents, your management doesn’t always know as much as they say they do. I’m a manager, I’d know.

So let’s take a tour of myths you’ll probably hear in the corporate world. When you hear these, make a mental note: this guy is a bozo.

Now that we’ve got the foundation of stack frames and the debugger for exploring them, we can use the stack for more than just local variables. The stack is also used for passing and receiving parameters to functions.

Let’s say I’ve got this very-nearly-useless function:

int sum3(int a, int b, int c)
{
    return a + b + c;
}

int main()
{
    sum3(1, 2, 3);
    return 0;
}

Once you have some concept of registers and the stack, it’s time to play. Take our original example and save this as stack.c:

int main()
{
    int i = 0x11223344;
    char s[4];
    s[0] = 'f';
    s[1] = 'o';
    s[2] = 'o';
    s[3] = '\0';
    return 0;
}

• All variables declared on the stack.

• Parameters to function calls.

• The pointer to the calling function’s stack base.

Let’s look at an example. Say my C code defined some variables on the stack like so:

int i = 0x11223344;
char s[4];
s[0] = 'f';
s[1] = 'o';
s[2] = 'o';
s[3] = '\0';

I will focus on the 32-bit i386 instruction set because:

• i386 32-bit instructions will work on both 32-bit and 64-bit x86 processors.

• Most of the existing documentation, on the web and in books, covers i386.

• If you don’t have an i386-compatible machine, you can buy one cheap, cheap, cheap and run a free operating system on it.

I will use the GCC compiler and GDB debugger for my examples. You can get this free for most any operating system; for Windows I would recommend running GCC under cygwin.

Expert programmers have all had “ah-ha” moments where, all the sudden, several concepts that were all unclear crystalize into one revelation and become clear. An expert mechanical engineer described this concept as going “above the clouds;” one moment you were lost in the soup, the next moment you break through the clouds and you can see clearly where you are and where you’re going.

Person and Perspective

The reason so many code reviews go bad is because the programmer makes a connection between the his code’s worth and his self worth. When reviewers point out problems in the code, the programmer takes insult, gets defensive, and things go downhill quickly.

• “When will it be done?” The rest of the company is waiting for the product to ship. They’ve got a rollout plan, a marketing blitz, perhaps manufacturing… all kinds of stuff that hinges on when the product will be done. So are we there yet?