It's a bird, it's a plane, it's

Everything here is my opinion. I do not speak for your employer.
April 2006
May 2006

2006-04-26 »

R.E.

The core of any design, whether it's a painting, a building, a computer program, or a company, is its "Raison d'Etre" - its Reason for Being, or, with conveniently the same initials as the French version, its Reason to Exist. Its RE.

Your skill as a designer depends on your ability to clearly imagine an implementation for your RE. And the degree to which the different implementers of a design understand its RE - or else, the level of control you give you people who don't understand the RE - strongly affects the overall coherency of the result.

Let's say the RE of your software project is the customer requirements or functional spec (they're different things, but since one leads directly to the other and they both come earlier in the pipeline, you could think of either one as the RE of the software). For some software, this isn't the case; some software, like Plan 9 or Scheme, exists for some other kind of RE that allows it to attain beauty while sacrificing usefulness. But in general, software with customer needs at its core is the kind that makes money, and it still has the potential to be beautiful. And as we all repeatedly learn, software which is beautiful can easily still fail to make money. The two attributes are really independent. But the kind of software I really like, the kind that makes money and is beautiful, works because it's consistent with its RE (ie. it's beautiful), and its RE is a well-defined set of customer needs (ie. it's useful).

A company's design works similarly, but there's a problem: as you progress through the technology lifecycle, the way you service the market needs to change, so if your RE was based on a particular way of acting - for example, doing heavy research for the early market - it obsoletes itself. The result is a strangely rotten core around which you've built a highly consistent implementation; you remember the beauty that existed before, but now that the core is different, the beauty is gone, even though the implementation is exactly the same. And trust me, although no person is to blame, the designer finds all this to be rather a PITA. People who enjoyed building something beautiful don't want to continue working on the implementation if they know the result won't be appreciated anymore.

Imagine you're writing a love letter to someone, and it's coming out really well, and suddenly you realize that person actually has really bad breath and glowy red eyes and you don't love her after all so you break up. As soon as this happens, the work you've done so far will go sour. Strangely, people who don't yet understand the newly-discovered flaw can still see the beauty of the work you've done so far, because they imagine a RE that is still there. But you, the artist, will never be able to honestly finish the work. Since beautiful work comes from an honest implementation of the RE, once you know the RE is gone, you will find that everything you do just makes it worse. If you're famous enough, it's better to just leave the unfinished work in a museum so a curator can dust it off occasionally and sell retouched reprints at huge profits. At least then people can continue to admire the beauty that once was. Don't ruin it by trying to keep building a fake implementation around a RE that has been lost.

Meanwhile, just as a work of art is meaningless without a RE, so is an artist, and a good artist won't take long before finding a new RE. If he's lucky, it will be one that's as compatible as possible with the old implementation; even the old implementers.

It's time to fall in love again. And we've got a half-written love letter that we can recycle. I'll show you how.

I'm CEO at Tailscale, where we make network problems disappear.

Why would you follow me on twitter? Use RSS.

apenwarr on gmail.com