Older blog entries for apenwarr (starting at number 174)

2006-07-12: Stubbornness is a Virtue - Sometimes; Trust and Respect; Good to Great

A few loosely correlated comments this time.

Stubbornness is a Virtue - Sometimes

I've been thinking a lot lately about what makes someone a good high-level leader. There are lots of things to consider, of course, but here's one of the things that has struck me most in the last little while: the best leaders are stubborn and also good listeners.

What, it's possible to be both?

Yes. People who are stubborn persist in a particular way of thinking despite encountering huge resistance. If you're trying to convince someone about a revolutionary new idea that will solve their problems, stubbornness is critical. Meanwhile, people who are good listeners adapt their thinking when someone convinces them that they've made a mistake or were missing some information. If you're wrong - which is frequently, if you have a lot of revolutionary ideas - you have to be a good listener in order to correct your mistakes fast.

The proper combination, though, is important. The best leader will persist in thinking something until someone properly convinces them otherwise. Once they've been convinced, then they change their mind and they're stubborn in the new way. That's not flip flopping; that's just a smart way to learn from your mistakes.

If you're missing one of those two traits, you'll fail in one of two very common ways: you'll persist in believing something stupid even it's been made totally clear and obvious to everyone else that it's wrong. Or else you'll never settle on a single direction, constantly changing your mind whenever anyone raises an objection.

Some people take it a step further and switch back and forth between being too stubborn and being not stubborn enough. One example I've seen a few times is a stubborn belief that "the investors are always right." So whatever it is that the investors want, you'll give them... even if they change their mind day after day. So you're left spinning in circles because of your persistent belief in someone else's idea. Other popular variations of this are "the customer is always right" and, most annoyingly for me at the moment, "the CEO is always right."

So my suggestion: believe in yourself. And then don't be afraid to let other people try to change your mind.

Trust and Respect

On another note, I was thinking about what would be the ideal company culture. This goes back to my earlier notes on membership control for working in a group.

I think a culture based on two primary concepts would be nice: trust and respect. It works like this:

First, you need to trust that people will be honest and upstanding (if you're paranoid, you can check their backgrounds before you admit them to the group). Since you trust them, you don't need annoying controls to make sure they're not trying to screw you, because you're not worried about that. If anyone ever gives evidence that they can't be trusted, remove them immediately; there's nothing more deadly to a social environment than a person who can't be trusted.

Second, you only admit people to the group whom you respect. That is, if you don't think they can do a good job or think clearly or impress customers or whatever, then you don't want them in your group. (In his book Blink, Malcolm Gladwell discusses a researcher who has discovered the #1 indicator of marriage breakups: a spouse who obviously looks down on the other.)

These two factors work together to produce interesting results. For example, if you respect someone, you will automatically become more trustworthy; would you screw over someone that you respect? Would you slack off at work, if it would let them down or hurt the project they're working on? Probably not. And that means they can trust you even more.

Meanwhile, because you respect them and so they trust you, you're actually working harder and producing more. That makes it easier for other people to respect you. And since they do, they won't want to screw you over, so they'll be more trustworthy and work harder. And so on.

This system covers most of the other factors in building a group as special cases. For example, if you're not a good listener, you obviously aren't giving the people the respect they deserve when they talk to you. And if you're not stubborn - if you just keep changing direction randomly - then eventually people will realize that you can't be trusted, because your opinion is based on whichever way the wind is blowing at the moment.

And about that Smart and Gets Things Done rule? Well, if you're not smart, that's going to show up pretty fast, nobody will respect you, and you're out. If you don't get things done, then you can't be trusted in an emergency, and you're out.

This system even deals with interpersonal compatibility in an interesting way: different people respect other people for different reasons. For example, a group of musicians might highly respect someone with a lot of musical talent, regardless of their table manners; a group of aristocrats probably wouldn't. (They can buy musicians for a dime a dozen, but it takes money to become an aristocrat!) This is interesting because the groups are probably fundamentally incompatible. If each group selects its members based on the trust/respect rule, things should rapidly work themselves out into two separate groups.

And so on. I like this rule because it makes the "membership control" system easy. I wouldn't feel the least bit guilty about kicking someone out of my company if I don't respect their abilities or if they can't be trusted. And yet those two things cover all the other important things.

Good to Great

I just finished reading the book Good to Great. It's interesting and makes many believable points, but it does scare me a bit with its selection bias. They tried really hard to avoid sampling errors, but didn't quite make it: the problem is that highly risky behaviours are correlated with both huge success and huge failure, while highly unrisky behaviours are correlated with mediocrity. So when you compare a set of "great" companies with a set of "merely good" companies, you will definitely find some statistically significant differences. Those differences might very well be absolutely critical to becoming great. However, they might also greatly increase your chances of killing yourself.

To name just a couple of examples, the "Level 5 leadership" concept makes perfect sense in terms of growing a company for the long term. But if you're "almost" a level 5 leader, then maybe you're just a quiet person with a vision and nobody really listens to you and so your company goes in random directions. Or the "hedgehog concept" - do one thing, and do it well. This is great, as long as it's the right thing. The book even gives some good advice on how to choose the right thing. But what if it's not quite the right thing? Then you're screwed. Massive diversification may prevent greatness, but at least you can hedge your bets.

Beware of advice that seems too good to be true.

Syndicated 2006-07-12 22:38:26 from apenwarr's log

2006-07-06: Dynamic Equilibrium; Footnote

I wrote before about precious instability, the idea that I design my life in an "unstable" fashion, then carefully control it, in order to make it more manoeuverable. For people who know me, some recent events might have put that into a bit more context.

But one thing I realized since then is that this concept is much more widely applicable than just me and my idiosyncratic ways. Modern high-tech business requires this kind of instability, but only when it's in the right places.

Put simply, there are two fundamental ways to manage any project: creatively (ie. a prototype) or using a well-defined process. Well-defined processes are efficient and scalable; creative solutions are resilient and flexible. (I wrote about efficiency vs. resilience before too.) An obvious way to balance the two is what I've been trying to do lately: do it (whatever "it" is, even if it's a business activity) the first time as a creative prototype, then try to generalize what you did into a repeatable process. As with software, making a mostly-right generalized design is usually possible, for a good designer, after you've done it about twice creatively.

But once your process is well-defined, then what? I've experimented with the "hand it off entirely to process-driven people" technique, but that often doesn't work very well, because if your process isn't perfect at the start, process-driven people aren't very good at fixing it. Meanwhile, trying to find some middle ground ("we'll follow the process, but bend the rules whenever necessary") is a disaster, because it's not a combined solution, it's a compromise, and it ends up being neither very efficient nor very creative. Gross.

I don't exactly have a tried-and-true solution to this, but here's what I'm thinking. Joel Spolsky has written about The Development Abstraction Layer, which is a partly-right variant of what I'm going to suggest. What he wants is a programmer's ideal world: the programmer just builds what he wants, which is assumed to be the right thing, and the rest of the company is an "abstraction layer" that gets all the annoying repetitive cruft out of the way. In terms of creativity vs. processes, that means the "developers" are creative, and the rest of the company delivers things based on defined processes (or at least inter-group communication follows defined processes).

The part where I disagree with Joel is the part where I've already specifically screwed up so I figure I can serve as a warning to everyone: developers shouldn't be the ones running the show. Not quite. Smart people who get stuff done (another Joelism) need to be running the show, but it's not about programming and designs and version control and operating systems and XML. It's about business and customer relations and good communication and... being smart, and getting stuff done. It just turns out that Joel's kind of programmer is exactly the right personality type... if they're deliberately caring about the right things, which is more than just the software.

So how about this. Classify your people into two categories: the creative solutions people and the process-driven people. Don't separate them physically or logistically; they have to work together. The creative solutions people design and update business processes. The process-driven people execute those processes - maybe only after the first prototype - and give rapid feedback on results. Don't worry, Joel, both groups should be smart and get stuff done. But they're two different kinds of people. Some very smart people really have a great time fixing bugs and optimizing failure rates and avoiding creativity at all costs. (Seriously, there are lots of people like this!) These aren't my favourite people to work with, but they're extremely useful because they like doing exactly the kind of stuff that I don't.

At the same time, process-driven people risk falling into dangerously stable ruts and getting blindsided when changes become necessary, because they enjoy their stability and will try to retain it at all costs.

So as a business designer, you need to set up the incentives of the creative and process people correctly. My suggestion? Don't let the process people define their own processes. Make them responsible for executing defined processes efficiently and make creative people responsible for changing the processes to make them efficient.

I call this "dynamic equilibrium," after the term from high school science class. It looks pretty stable, because the majority of people are sitting around executing repeatable processes. It's just that it's not really stable, because exceptions will come up, and when they do, weird stuff happens automatically to re-stabilize the system.

Disclaimer: I haven't tried out this advice yet, but it sounds like fun.

Footnote

Crap, I really wanted to work in my example about airlines losing my baggage, but it didn't fit... so here it is anyway.

Airlines process absurd amounts of baggage every day very efficiently, and lose a vanishingly small percentage of it. That's an efficient business process.

But every now and then they lose a bag, and they don't know what to do, because if they knew what to do, it wouldn't be lost, sort of by definition.

You need business process people around to deal with the majority of cases, where the bags aren't lost. And you need creative people around to handle the exceptions, learn from them, and fix the processes so even fewer bags get lost.

Syndicated 2006-07-06 17:01:28 from apenwarr's log

This evening I got a "customer satisfaction survey" call from Fido. She assured me that the call wasn't going to use any of my cell phone minutes, and then asked a simple leading question:

"On a scale of 1 to 10, how would you rank your current satisfaction with Fido?"

"Current? As in, not historically?"

"Right. How do you feel about the service you're getting right now?"

"Well, about a 6."

"Err... well, that's pretty low. Can I ask you why?"

So I got it all off my chest. The ever-increasing fees (increasing? What kind of technology is this?). The annoying people who phone me when I'm a few days late on a payment because I've been travelling and haven't picked up my bill. (I mean, charge me a late fee if you must, but *phoning* me for being three days behind? Yeesh.) The lately incessant calls to sign onto a multi-year contract, which shows they no longer care about "real" customer loyalty (I've been a customer for about 10 years, no contract required). The way their ads aren't so innocent anymore: they used to be just cute dogs while everybody else would use salamanders (what?) or cute girls; now they're cute dogs with cute girls, and it's only a matter of time until the dogs won't even get equal billing. And of course, my actual problem, which is that I'm out of town so much lately that I pay long distance charges for almost every incoming call minute.

In short, I used to recommend Fido to all my friends because of its awesomeness compared to other cell phone companies. But since Rogers bought them, they've been in steady decline. The lady on the phone rightly pointed out that they're still "better and less expensive than all the other companies!" Well, fine. It's not like I'm saying I'm planning to switch because I found a better deal elsewhere, because I didn't. I just don't care about you anymore. So if I did find a better deal elsewhere, then I suppose I'd probably switch.

And this is where the whole conversation got kind of weird, because she was totally horrified by this attitude. She asked if she could put me on hold to check with everyone else to see if there's a plan I could be on to fix my long distance problems (there wasn't). She checked to see if signing onto a multi-year contract would help me somehow (it wouldn't). She checked all over to see if I could adjust anything to save money given my admittedly weird calling and travel patterns (there wasn't). She discovered that I was currently entitled to a free new handset (I don't need one).

But here's the thing. She kept me on the phone for 20+ minutes as she went through everything she could think of to try to solve my problems, even after I assured her I wasn't planning to switch or cancel my service. That can't have been part of her job description. She was taking her "customer satisfaction" job really personally, to the point where she thought of it as a personal failure if I wasn't happy with my Fido service.

Which is silly, of course, because it's not her fault Fido's recent policy changes suck. It's Rogers' fault, and perhaps the fault of the almighty dollar (rumour has it that Fido was losing money at the time they were bought; I don't know if that's true).

It seems to me I've talked to this particular lady before when I've called Fido support. I think she might have been working for Fido almost as long as I've been a customer. That means that she's been through the days of rave reviews, successful word of mouth marketing, and sensible management. The management was indeed sensible to hire all those great, loyal, dedicated people in customer service. Strangely, those loyal people are still there, and still really care just as much as they used to. They just don't have the power to make the customers happy anymore.

I didn't really make her cry. Only almost. But I think she will if I ever cancel.

"I need to attract more customers so I can get promoted or at least demoted so I don't have to wear this squid anymore. It's a long story."

Final score: Novelling:1, My sanity:0

Schedulator is the software project management system we originally developed at NITI to solve a simple problem: I'm a programmer, and I ended up as a manager, and I didn't want to spend all my time doing management.

It's essentially a fancy automated implementation of Joel Spolsky's Painless Software Schedules, where each developer can manage his/her own schedule. By combining the results generated that way, you can produce an accurate schedule for the whole team.

Schedulator isn't very many lines of code, but it's the result of years of tweaking of the Schedulation process, which actually works pretty well, and has a lot of advantages over "normal" software scheduling. As part of my new job, I've been redoing major portions of the Schedulator to make it more flexible: it now supports bug tracking systems other than FogBugz, for example (although that one's still my favourite :)), and no longer requires GracefulTavi (as much as I like wikis, doing it that way led to a pretty inflexible design).

The new Schedulator isn't packaged up nicely, and may never be because it has a pretty limited audience. But it should be much easier to get up and running with the new version than the old one, because it has far fewer prerequisites (and the parts that have prerequisites are now optional plug-ins).

I did, however, write some extensive documents explaining the theory and practice of Schedulation. My favourite is the first one, Schedulator Philosophy. Read it, and maybe find out if Schedulator is right for you.

The Google Factor

Not long ago, pcolijn wrote about Google's development process and compared it with Schedulator. I generally agree with his analysis. The problem is that most of the problems Peter identified were not problems with Schedulator, per se: they were problems with the general team atmosphere and management. (I'm allowed to say that, because I was one of the managers.) Schedulator is very compatible with the "Agile development style" done at places like Google. Okay, so Schedulator doesn't come with any index cards included, but it does do a lot of the grunt work of arranging those index cards - particularly when there are hundreds of them in your bug tracking system and they all seem important - for you.

As much as Google is indeed awesome, hires a lot of great people, produces a lot of great things, and makes an awful lot of money in the process, I sometimes caution people against taking their experiences at Google too seriously. People in highly successful companies are prone to an attribution bias, much like people are in unsuccessful companies. That is to say, no matter what your team does at Google, Google is still going to be making billions of dollars. And no matter what your team does at some unsuccessful or dying company, you probably can't pull it out of the toilet. In both places, the consequences of your actions are disconnected from reality. (Bill Gates called this the honeymoon phase.) At Google, raises and bonuses for everyone. At the unsuccessful company, even great people get laid off sometimes because there's no money to keep paying them.

For example, the article that Peter was responding to had this very important paragraph:

Another incentive is that every quarter, without fail, they have a long all-hands in which they show every single project that launched to everyone, and put up the names and faces of the teams (always small) who launched each one, and everyone applauds. Gives me a tingle just to think about it. Google takes launching very seriously, and I think that being recognized for launching something cool might be the strongest incentive across the company. At least it feels that way to me.

Sure, this is a great incentive for people to work harder, and Google's very wise to do it. But do the math: every single project that launched? Always small teams? But Google employs thousands and thousands of programmers! They can't all be on the big screen. In fact, most of them can't. But Google's still successful.

Which kind of team are you on? How can you tell? Statistically speaking, you're probably on the unsuccessful kind. And beware of logic that sounds like, "my team did this, and we weren't too late" or "their company did it this way, and went three years overtime." There's a correlation there, but there could easily be no causality. Super-ultra-smart people could do their project plan on stone tablets and still get their projects done an order of magnitude faster than complete boneheads.

That said, I used (and still use) Schedulator, and it works great for me :)

As a programmer, there are two main ways to make yourself irreplaceable. One is to write code that nobody else can possibly understand, so they can't figure out how to get rid of you. One is to write code so great that nobody could ever want to get rid of you.

The best way to be replaceable is to be somewhere in between.

apm linked to a series of "six word short stories" by famous people in Wired Magazine. Many are quite excellent.

I'm not famous, but this sounded like fun, so here I go:

Who's that bioengineered lapdog eating *now*?

(This is a work of pure fiction. Any resemblance to real CorporateDogs is purely coincidental.)

Woo hoo! Only 49,994 words left!

Hmm, it seems the expected flamewar is flaming even better than expected. hub chimes in to say that power management has been working just fine on Linux since 1999, thank you very much. Um, yes, well... sit back and relax, because I have a story to tell. Like all my favourite stories, it involves a lot of stupid people doing stupid things. It doesn't have a happy ending. If you're easily depressed, you should stop reading right now. That means you, Pierre.

Once upon a time there was APM, or "Advanced Power Management." As with most fancy-named specifications, its name certainly doesn't imply that there was an earlier "Totally Simple Power Management" that it replaced. The way APM worked was it used a kind of "super supervisor mode" in the x86-series CPUs to actually run some BIOS code above the operating system layer in an invisible way so the kernel couldn't detect it (except for the bad BIOS coding that would result in lost clock ticks and random interrupt latency). This BIOS code would do things like detect presses of the laptop's suspend button and forcibly suspend the system whether the operating system liked it or not. If your operating system supported APM, which was by no means necessary in order for suspend/resume to work, it could get a notification from the BIOS that it was about to suspend. In later APM specifications, they added a way for your software to reject the suspend operation in progress. However, because of BIOS bugs, this didn't really work so well. Also, if you took too long to service the notification, the BIOS would just give up on you and suspend anyway. Ah, those were the days.

Oh, also, because the BIOS writers for a laptop always knew exactly which hardware devices were in the particular laptop, the APM BIOS could always know exactly how to suspend and resume all the devices in your laptop transparently to the kernel. And yes, it actually worked just fine. Even the video mode was saved and restored correctly on most systems, all behind the scenes.

But that was a long time ago. To give you an idea of how obsolete APM is, my apmd page seems to be the fourth hit in a Google search for APM - and it's the first one about power management. And let me tell you, that's not because I'm such a popular guy.

There were two perceived problems with APM. First of all, it was highly x86-specific, which annoyed the people at Intel who were trying to make and sell a non-Intel-compatible processor. (Remember that failed experiment? Me neither.) Secondly, operating systems programmers correctly noted that all BIOS programmers are crackheaded morons who can't implement an API correctly to save their lives. The way things tended to work was this: Windows didn't come with native APM support at the time, and the BIOS programmers would screw up the APM implementation horribly, but that was okay! Because every motherboard had to include a special APM driver for Windows anyway, and this APM driver would just implement the broken APM calls that the BIOS required, and so nobody would know the difference. Sure enough, nobody (er, well, no Windows users) did, and the world of power management was a fine place. For Windows users.

Linux users had a bit of trouble because they had to independently discover all the stupid BIOS bugs in various laptop APM implementations. But they mostly sorted this out eventually. In any case, one popular way to make your problems go away and have suspend/resume work mostly right was to simply disable the Linux APM altogether and just have your BIOS do it transparently.

So anyway, back to those people who wanted to fix what wasn't particularly broken. They invented ACPI, and I want to kill them. Oops, I'm getting ahead of myself.

ACPI stands for Advanced Control and Power Interface. Now, I have two things to say about that. First of all, there was no "Delightfully Simple and Straightforward Control and Power Interface," although ACPI actually makes APM seem that way in retrospect. And secondly, ACPI has nothing at all to do with APIC, the Advanced Programmable Interrupt Controller. The only comparable thing between the two is that they both have Linux kernel boot-time options to disable them because they both have buggy Linux drivers that cause your computer to crash a lot.

Now where was I? Oh, right, ACPI. So, the idea of ACPI was to get the BIOS developers out of the way on a normally-running system by turning around the power interface: instead of the BIOS running things and just occasionally notifying the kernel when something happened, the kernel would run things and just ask the BIOS to do stuff occasionally, like power down various hardware and blink the lights and so on. That would mean BIOS bugs wouldn't be so harmful. Oh! And while we're here, because we're insane, why not implement the whole thing using Forth-like bytecode instead of real assembly language, so it can also run on that new (doomed) 64-bit processor we've been working on? Forth-like bytecode is super simple and can be implemented in a couple of kbytes, so it won't cause much overhead, and suddenly everything will be portable. It'll be great!

Because I like foreshadowing, I'll give you the quick version of what I'm about to say. To my total amazement, they managed to fail totally on all counts. How's that for consistency?

First of all, ACPI completely and utterly fails to remove the BIOS from the picture: in fact, you're calling back and forth to it far more than you ever did with APM. And because you're calling it from your context instead of it having its well-known super-supervisor context, it's more likely to get confused by the funny way you do your stack or registers or memory protection modes. And there are so many ways to call into ACPI, because they broke it into tiny pieces so your kernel can control exactly what it wants to when it wants to... except that the BIOS manufacturers didn't actually test what happens when you call their stuff in random order, so actually you have to reverse engineer exactly what order is safe to call things in, or your system crashes horribly.

Oh, also, the bytecode thing went awry somewhere, because the Linux ACPI implementation runs to hundreds of kbytes and is filled with all kinds of weird and very complicated special case drivers for obviously totally dissimilar APIs like fans (it goes fast! it goes slow!) and CPUs (it goes fast! it goes slow!) and LCD backlights (it gets bright! it gets dark!). And naturally, ACPI, being a big horrible pile of crap, was never adopted on any non-x86 platforms, so its CPU independence doesn't help.

(Around the time all this garbage was being invented, people were trying to make non-x86 platforms run PCI video cards, which was tough because the video card initialization code was written in x86 assembly. The XFree86 group and other groups solved this problem unilaterally in a less elegant-sounding but actually working way. To this day, video BIOSes are still in x86 machine code, not bytecode.)

But that's not all!

Remember, the OS developers wanted to get the BIOS developers out of the picture, because BIOS developers are indeed crackheaded morons - I think we can all agree on that. Unfortunately, while they completely failed to do this - and in fact, ACPI makes things much worse - they also made it so the BIOS developers can happily just disclaim any responsibility for whatever parts of power management they don't want. Once upon a time, in the golden age of APM, the BIOS had to support all your devices because it was the BIOS whose @#$! responsibility it was to suspend and resume everything. Now, however, the OS is expected to pick up wherever the BIOS leaves off - which is almost everywhere. That means most ACPI BIOS implementations don't actually handle any parts of the suspend/resume process properly, often including even the CPU speed. Certainly they're not smart enough to suspend your ethernet chip. And heaven help you if you want your video mode to be restored! My now-stolen last laptop, a Sony Vaio, actually had an ACPI interface to control the LCD backlight... but it didn't do anything. There was a totally different non-ACPI backlight control elsewhere in the system, and the BIOS developers simply didn't bother to take out the ACPI one leftover from a previous laptop model. The OS has to know this, based on the laptop model number, and deal with it.

But that's okay! Because the Windows driver programmers, sitting right next to the BIOS programmers or maybe the hardware designers, can simply compensate for all this stuff. The CD that comes with every laptop contains modified drivers for all the broken stuff the hardware and BIOS designers did wrong when building your system in the first place, so everything is fine! For Windows users.

Now, Linux certainly didn't have it all easy in the days of APM, but things had a pretty good chance of working because they were relatively simple. With ACPI, everything is just a total disaster. You have to implement suspend-to-disk all by yourself, and it's doomed to suck because the stupid BIOS does its time-consuming and useless initialization before you're even allowed to start. You have to implement power saving features in every single driver, where with APM you didn't have to do it in any driver. Linux developers are notoriously bad at handling exception conditions, which power management is, so the power management code for most drivers is almost-untested barely working garbage. And of course, you do still have to call into the mostly-but-unfortunately-not-totally-useless ACPI BIOS, which for some reason takes hundreds of kbytes of source code to do and requires talking to a horrendously buggy BIOS. That means you need an exception table listing every laptop anyway to tell the kernel which bugs you need to work around at which time.

And if you do all that stuff correctly, your laptop will suspend and resume properly!

And you know what? Even then, it'll still suck, because that's just what you have to do to make it barely work at all. If you want to, say, bypass the stupid BIOS POST phase to make it boot faster, or do what Apple does and actually save to disk and memory at suspend time, then resume from memory whenever possible, or have the system suspend to memory and then suspend to disk if you stay suspended for a long time, or any of that other complicated stuff: that's all extra. Meanwhile, most hardware developers are a bunch of slackers and even when you do suspend the bloody thing properly, the battery dies in a few hours anyhow.

So kudos to the Linux developers for making it almost work. I'm sure that was really hard. Yay team.

Compared to that, Apple cheated like crazy. But I still like my Mac, because it actually works.

(And I have Ubuntu running constantly in a virtual machine because I mostly hate Darwin, but that's another story.)

Far be it from me to get into any sort of flamewar-causing religious-type discussion (ha ha), but pcolijn asked how any sensible developer could use a Mac for their work, given a few of its flaws. In order, and without any actual reference to the questions:

• I don't watch movies while computing, because I can only do one thing at a time. I know, I'm an inferior life form. Sorry.

• I don't play movies on my computer at all, actually, because computers are stupid. (It took me years to find the root cause of my endless video-playing problems on every operating system, but that's definitely it.)

• I prefer to listen to my CDs rather than looking at them.

And last but certainly not least...

• I use ion for my window management, of course! It's just as excellent as ever, plus power management works. Actually I had to upgrade to ion2 (I was probably the last person in the universe to do so) in order for it to make sense. In ion1 the results when you press F9 are hilarious (all the frames are separate windows and swoosh to random locations) but rather useless. Anyone who wants a copy of my ion2 config files, just ask.

Also, because you didn't ask, I have no patience for the actual OS X "imitation Linux" crap (any OS released post-y2k where just typing "find" doesn't list all your files is stupid, plus "ps axr" doesn't work, and fink seems to mostly consist of non-working packages) and installed Ubuntu in a virtual machine. So I'm "remote displaying" on my MacOS X Xserver from my virtual machine. It's a bit silly, but due the magic of modern virtualization and disturbingly fast CPUs, it works fine.

(How fine? Well, pphaneuf asked me to time how long it takes to compile Quadra on native OSX vs. my virtual Ubuntu, but unfortunately I'm not smart enough to compile it on either one successfully. Anyway, it's fast enough for me.)

Delirium 3: Specs and Constraints

So let's say you managed to assemble a team of obsessive, maniacal geniuses who are all "signed up" and ready to get the job done. Great! So, uh... what job, exactly?

There's more than one reason people don't run teams like this too often. The most basic reason is obvious enough: the rules are so strange, undocumented, counterintuitive, and completely opposite from normal (successful!) engineering practice that people just don't try to assemble the "right" conditions very often. But if, after takeoff, the results tended to work out spectacularly... well, people would get over all that other stuff, right? ... Right? ... Actually, yes, I think so.

But life isn't so simple. There's a much more serious problem with the "obsessive genius" technique. The problem is that the results are entirely out of control. You'll almost certainly get something cool - probably more cool stuff than you know what to do with. But you won't know in advance exactly what it'll be. And that, my friends, makes it hard to run a business.

Some companies do it anyway. They start a "research lab" or "skunkworks," put the wheels of obsession in motion, and pray like crazy that something good comes out.

Well, research labs aren't for me. I'm not going to beg "the establishment" for their precious resources, with nothing more to offer than a random splash from my really, really big shiny innovation firehose. When all I have to choose from is total randomness in large quantities or total determinism in disappointing quantities, I'm in a classic compromise situation. The non-compromise condition is massive, sustainable, directed ingenious output. And my theory is that it's a lot easier to direct output that's already massive, sustainable, and ingenious than it is to take small deterministic output and make it bigger and more ingenious. It's easier to learn to aim a big firehose than to put out a big fire with a really accurate squirt gun. Mind you, no matter how well you aim, some tangential stuff is still going to get a little wet. But it'll dry off eventually.

Which all finally brings us around to my point. It is possible to direct the output of a team of obsessives - sort of. You just have to be careful about what exactly you direct.

Determinists love specs - clear descriptions of the ins and outs, which must be captured exactly. Then you leave your geniuses to do any design they want, as long as it implements the spec precisely.

I tried that method. I really did. I sliced and diced specs vs. designs in every way I could think of. UI design isn't specification, it's design!, I declared once.

But with each and every attempt at this technique, I failed in one of two ways. Either the spec was too dumb and restrictive - or the result was too crazy and random. Either the product was overspecified or it was underspecified. And now I realize that it always will be. Trying to "right-size" your spec is just a tradeoff - a compromise. The right answer doesn't even lie on that axis.

But even though I've never really managed to separate the spec from the design (for management purposes at least - it works for post-documentation, or what we sometimes call a "retrospec"), I have successfully produced non-random, ingenious results - and I've worked with other teams, like NVS and GourD, that produced them. What's the secret?

The secret is "end-to-end." The problem with our spec-design separation is actually very simple: it draws a line between the real, deterministic world - the spec - and the world of genius - the design. But that's nonsense. How can your product be ingenious if its workings were defined by someone deterministic? How can it be useful if the workings are defined by someone crazy? The spec, too, must be written by someone in genius mode. Those were the real successes I've seen - where the spec, the design, and the product were all done in genius mode, "proper processes" be darned. And I've been fooled like everyone else: GourD had a Requirements doc, then a Spec, then a Design, then an implementation. Deterministic, right? The model of good engineering!

Yeah, sure. The author of all those parts was the same person, and while they were written down in sequence - which is a very fair, respectable, methodical approach applicable to geniuses as well as anyone else - I know for sure that the documents were "non-causal." The contents of the design changed the requirements long before anyone wrote down the design. I was there. You can't fool me. Just try to tell me the requirements would have been exactly the same if Mediawiki hadn't existed as a model. It was all a good exercise in in thinking clearly. But it wasn't a "deterministic engineering process." It was a sham. It was an ingenious bunch of work that couldn't help but come out because all the right pieces, including the right people with the right motivations, were in place.

So the question is, then, how did it get to be the right product? Where did the genius stop and the real world begin?

The answer to that question is the key to everything.