Compensation for Company Founders

At last! A salary survey I can use! Of course, this is for U.S. companies, unclear about the funding stage or business area or exact area of the U.S., and so on.

Users and Drugs

(No, this is not another posting about pphaneuf being on crack.)

Jimmy Guterman points out that the only industries that call their customers "users" are drugs and high tech. This seems true enough to me.

Given that, let's take a moment to admire the strange coindence in the fact that at NITI, we independently invented the term Release Pusher to refer to the people who manage the release schedule and are responsible for getting the release out on time. "What, a Pusher? It sounds like you're selling drugs!" the naysayers naysaid.

Apparently this fits the metaphor nicely, I say.

Too bad I didn't do it on purpose. It would have been very clever.

21st Century English

In the last few years, we've seen the introduction of some terminology you may not be familiar with. Here's a start:

Democracy: n. Whatever they're doing to Iraq. Sounds painful, seems the people there don't like it much. Probably worth avoiding.

Reality-style: adj. In the style of "Reality TV," that is, a fun game in which the participants get to vote on what they would like the outcome to be. As in reality, the participants somehow always fail to notice that the power lies not with the people voting, but with the people deciding who you get to vote for.

Zen, motorcycles, etc

lukasz: the more you learn, the more you realize how little you know. But that doesn't mean you're not making progress.

At least, I sure hope so. Because I get that feeling more and more every day.

When good design goes bad

Avid readers of this journal (should there be any) may recall my earlier rather positive review of the Pontiac Pursuit. Last year I even bought one.

Well, I have bad news: today I needed to rent a car to get from one place to another, and they gave me a new 2007 Pontiac G5 to drive. As of 2007, G5 is the new name for the Pursuit. That's because it now sucks. And thus begins my occasionally backwards story.

[...one year earlier...]

The 2006 Pursuit was known as the "Pontiac G5 Pursuit." That's the one I own; in fact, I got the GT model, which ends up with the lame combined name of "Pontiac G5 Pursuit GT."

It wasn't always like this. Back in 2005, the car was introduced as simply the "Pontiac Pursuit." Mine would have been the "Pontiac Pursuit GT." That would have been a fine name; just the right number of G's to make it sound fast but respectable.

People who know about cars tease me about my Pursuit. They think it's an American car, and therefore sucks by default. They think it's a Pontiac, and therefore has an interior designed by spaceworms from Planet Xorax. The people who think these things have not actually been in my car, which is in fact awesome. The designers must have pored over every detail; everything works the way it should, with a minimum of user interaction, pushbuttons, twirly things, random guessing, or annoyance. The engine actually runs properly; the stereo is tuned for the car's acoustics; cruise control uses only three buttons, two of them optional; the doors close with a satisfying, low-tolerance whoomp instead of a clunk (a factor I first observed with dcoombs while in Germany). And yes, it was cheap. Of course it was cheap! Just as any respectable American car should be.

The Pursuit's origins are mysterious. When I went to look for it back in early 2006, it didn't exist on the General Motors web site; only GM Canada listed it. It was obviously intended to fill a low-end price point missed by their similar-looking G6, but it had an airy-sounding name instead of a randomly-selected combination of alphanumerics. And, unlike the G6, it obviously wasn't designed by morons. In fact, I joked to a few people that the design seemed to have been contracted out to someone from Japan. I don't actually know if the person was from Japan. But knowing what I know about design, I'm almost sure there was in fact a person. Someone cared about this car - a lot. It could never have been designed at GM otherwise.

So anyway, when later in 2006 it was renamed to "Pontiac G5 Pursuit" - an even stupider name than its companion, the G6 - I knew something was up. There was a person behind the Pursuit - and that person wouldn't have let people get away with something so dumb. My theory was that the designer had either been overruled or had moved on. But since the car seemed to still be the same despite the name, I bought it anyway.

Which brings us to 2007; my theory has been all but confirmed. While the "G5 Pursuit" was just a marketing transition and my car is fine, the G5 is just not the same thing as the Pursuit. The G5 is a piece of garbage worthy of the modern Pontiac name. They've replaced the stereo with a newer one that has fewer features and a worse UI; the console has been randomly rearranged to make it uglier and less user friendly; the interior feels cheaper due to some sort of change in materials; the doors clunk instead of whoomp; and I'm sorry, but the bloody side mirror adjustments just don't work at all. (Using them, you can only point the mirrors in various directions where you can't see anything. To fix it, you roll open your window and push the mirror by hand.) I get the distinct impression that pieces will be falling off, both inside and outside, within a couple of years of owning it. Oh, and the brakes were squeaky. The car had only 6800km on it.

Oh yes: to top it all off, because of the higher-than-expected sales and excellent quality record of the 2005-2006 Pursuit line, Pontiac decided to raise their prices for the 2007 model.

I'd like to meet the designer of the original Pursuit. I think I feel like him sometimes.

Cheesy observation

It takes a special kind of courage to make French Onion soup using cheddar cheese.

Today and tomorrow: some musings I wrote in my notebook during my earlier trip to Spain.

Science vs. Religion

The debate between science and religion (no hyperlink; as if you need one!) is not so much unresolvable as just plain unfair. It's like arguing about which is "right", art or chemistry. Religion in general lacks the tools to mount convincing logical arguments, because that's not what it's about. Science, on the other hand, is about accepting that the answer is uncertain, then assembling the evidence on both sides of a question, then believing one side or the other based on the evidence because it "sounds more right so far."

Religion, or at least Western religion, has been passed on in the form of a playground bully: "Do it my way or I'll pound my way into you." This was rather convincing for awhile, but modern society frowns on such methods (for scientific or other reasons) and now the religious establishment, with its threats of eternal damnation and so on, are left looking a little old-fashioned, chauvinistic, and silly.

But that doesn't mean they're wrong. I learned some time ago that I'm quite capable of winning most arguments (whether through eloquence, cleverness, or simple exhaustion of the opponent) whether I'm right in the end or not.

So here's my advice: we've learned already to be careful of any "advice" phrased as a threat, and discount it accordingly. But don't forget to also discount advice that sounds too convincing. That doesn't make it right either.

Pay attention to the people who don't know how to argue. They might still have a point, but it's up to you to find it for them.

Feynman on actual Quality "Assurance"

I just read Richard Feynman's analysis of the space shuttle Challenger explosion from 1987. I was surprised, first because it was completely readable and understandable, and second because he has such an englightening way of looking at what went wrong - namely NASA's quality control processes at the time.

The article is well worth reading for yourself, but two insights in particular stood out for me. First, his analysis of the turbine design and testing processes, which nowadays we in software would call "big bang integration" testing. Design, build, and assemble all the parts, then test the completed unit. When it fails, try to guess what went wrong and work around it. At that late phase, you're testing the entire engine. Just the testing is expensive, and changes that would have been easier before (like redesigning the engine cavity for a different propeller shape) are so expensive and slow as to be impossible. So the solutions implemented so late are necessarily band-aid solutions that may or may not fix the root cause - sound familiar?

Then, as the schedule slips and slips, quality requirements are slowly relaxed out of desperation. His proposed solution is to thoroughly test each component repeatedly, early on, in order to reduce the cost of finding and fixing the bugs. That reduces the number of bugs found in the later integration testing phase... sound familiar?

He contrasts this with the way the software group did their testing. Essentially they were doing unit testing, pair programming, and rapid iterations - in 1987! at NASA! - but that's not the interesting part. What's interesting to me is the way they arranged their QA team.

Books like Peopleware talk about organizing your QA team as a group of adversaries to your development team. Their job is to cause trouble by breaking the developers' software. So far, so normal, but here's the problem: I've seen people try that, and I tried it myself. It doesn't really work. It gives the developers an excuse for bugs that don't get caught. So as you start off, the developers get lazier and lazier, test their work less, and just leave the bugs for QA to find. As it gets more adversarial, you just get more arguments as to what is and isn't a "bug." If you add cash incentives (eg. a bounty for each new bug found, and another for each bug fixed), you just get people cooperating to cheat the system by deliberately leaving easy bugs to be found and then fixed - for more bounty on both sides. As a bonus, management's metrics all improve: look how many more bugs we're finding now!

So that's how it normally gets tried and fails. But hopefully you knew that already. What's interesting is how it didn't fail at NASA.

The idea was actually very simple: the expected number of bugs found by QA should be zero. That's because developers should bloody well be capable of testing the code for themselves.

The QA department was just supposed to assure quality (hence the name!) - quality already present before it got anywhere near their department. A bug found at that phase is very serious, because it means the development processes aren't working right.

Their QA process is a test of the development process, not of the software itself. This is a really revolutionary idea - at least to me. Maybe it's supposed to be obvious. The obviousness of it was apparently lost to software developers sometime between 1987 and now.

In reality, NASA at that time had apparently documented six - six, in the history of the whole project - times that QA had found a bug. Those times were investigated and documented in detail, because each time was regarded as a critical failure of their development processes. Critical process failure warrants detailed involvement from very high-level people. Policies get changed, people get promoted, demoted, or fired. Each of those bugs resulted in changes to the development process so nothing like it would ever be able to happen again.

Is that what your QA team is like?