Sunday, February 24, 2008

How To Dodge Corporate Monkeys

Many, many programmers have had or will have the experience of seeing somebody with more corporate-political power making a decision which is obviously wrong - where the obviousness is apparent only to anyone with any in-depth knowledge of technology.

For instance, you need to compete in a space where established best practices are agile, lightweight, swift, and battle-proven, with many successful examples - and instead of using the proven open-source solution with the proven agile strategy, management opts to build or buy something expensive, crappy, and stupid.

The easy solution in a situation like this: quit your job.

Easy solutions are great for Twitter, but this is a blog. Easy solutions are also great for teenagers, but this is for grownups, and grownups face tradeoffs. You could have a sick spouse, and need the health insurance; you could be in a small town, and face limited local options. You could even be otherwise very, very happy at your company, but faced with this one infuriating challenge.

The answer to your dillemma is very, very simple, but we're going to take the long way there.

First, we'll look at Google. Next, we'll look at Ruby on Rails. Then we'll look at Propellerhead Reason. All three of these highly successful technology projects have something in common.

After that, we're going to visit Ayn Rand, the L. Ron Hubbard of Libertarians, for some surprisingly useful advice.


There's a lot to learn from Google - for instance, the Google guys go to Burning Man.

The Google guys are smart.

If you google Google for a while, you'll find a lot about simplicity. From its very early days, Google made simplicity a guiding principle. Google's sparse home page initially happened because neither Brin nor Page knew much HTML, but over the years it became a matter of pride, as well as a competitive advantage over busy, noisy, useless sites like Yahoo! and MSN.

In Google's early years, the company acquired a snooty, stand-offish reputation in the Valley, because companies that partnered with every one of Google's competitors to deliver content usually left Google's offices without a deal. Often they didn't even get a meeting. Google disdained these partner companies because they decided paying for third-party horoscopes and games was irrelevant to their goals as a company. Instead, Google targeted low-hanging fruit with superior technology. Today, they dominate their market.

Ruby on Rails

Ruby on Rails made simplicity a guiding principle as well - and not just a guiding principle but a war cry. David Hansson marketed Rails to the developer community with presentations mocking Java's complexity.

Hansson is also notorious for telling users to code something if they want Rails to have it, and to fuck off if they irritate him.

When people requested new features for Rails, Rails often refused to provide them. Rails is unusual in that one of the first things it did after it went 1.0 was remove unnecessary features.

As the Rails user base exploded, many people came to Rails, drawn by its phenomenal growth curve, with ideas of how it could be bigger and better; how it could become one size fits all. Other people came to Rails criticizing it, attacking it as inadequate for various enterprisey problems. Both sets of people got the same response: "Rails is intended for a particular problem space. You are free to use it in any way you like, but its design targets a simple, quality-intensive, small-business use case, and will remain optimized for that use case." (paraphrased.) Rails targeted low-hanging fruit with superior technology, and by doing so changed the world of Web development.

Propellerhead Reason

Propellerhead Reason is a "prosumer" virtual studio application for producing music. Depending who you ask, Reason is either a toy - according to many amateur Cubase and Logic users - or a professional tool - according to professionals like Eminem, Prodigy, London Elektricity, DJ Fresh, Hank Shocklee, and Luke Vibert. If a toy, Reason competes with Fruity Loops, now called FL Studio to diminish the toy-like name; if a pro app, it competes with Cubase, Logic, Reaktor, and Ableton Live.

I read a rumor somewhere that Reason has four times the user base of Logic or Fruity Loops. I haven't been able to substantiate it, but it is definitely a very successful product. Like Rails and Google, Reason disdained popular features thought to be "necessary" in its space when it first launched, and still does so to this day. Where most virtual studio software supported a variety of compatibility architectures designed to accomodate inter-device and inter-software collaboration - MIDI, VST, and at least one other format now lost to the mists of time - Reason initially skipped the entire concept of compatibility. Likewise they skipped, and still skip to this day, the entire concept of recording audio. Instead, they chose a simple design metaphor, and they stuck to it. Recording audio and VST plugins are both out because they don't fit the virtual studio metaphor Reason uses, or its corresponding concept of control voltage, or its unusual corresponding model for MIDI. Reason made simplicity a guiding principle.

Similarly, while most virtual studios "dumbed down" their pro suites for prosumer users - with aggressive condescension, in the case of Digidesign Pro Tools - Reason instead built something which made the consumers immensely happy and then built upwards to the pros. Instead of struggling against Logic, they dropped an atom bomb on Fruity Loops. Reason targeted the low-hanging fruit with superior technology, and produced a marvellous product that still powers a successful business to this day.

The Theme

You may have noticed a theme.

1. Make simplicity a guiding principle
2. Target low-hanging fruit with superior technology

I personally believe that these are essential elements in any and all successful technology projects. I can't prove it; however I can state with confidence that Paul Graham's Viaweb startup matches the pattern as well. This isn't a blog about math, so I'll let someone else figure out the formal proofs. Whether this pattern holds true for all successful technology projects or merely many successful technology projects isn't such an interesting question. Either way, it holds true for successful technology projects. Therefore, if you want a successful technology project, follow these rules.

But what about the monkeys? What about the guys who don't know a damn thing about technology, but their dads own country club memberships? Why is it so much in the world of technology comes down to the fundamental dynamics of an 80s movie? What can we do about it?

The simple, teenage answer is that if you create a successful technology project, the Biffs and the Chips will have to get out of your way. But sometimes it doesn't work that way, or it doesn't work that way fast enough. This is where we get to Ayn Rand.

Ayn Rand

I called her the Libertarian L. Ron Hubbard because both wrote "novels" primarily to sell worldviews. There are certainly differences, but there is that one similarity, and it's an interesting similarity.

She said something brilliant in Atlas Shrugged, and fortunately I do not have a copy of the book here, nor do I have the ability to quote the passage from memory. But I do recall the fundamental idea very clearly: if you want to destroy a system based on lies, just comply with the system, but add nothing of your own.

I've used this against a wide range of irritating people, all to great effect. I've also failed to use it against liars, and when I didn't use it, the liars defeated me. I don't remember why it works, but it works, and I think Rand explains it somewhere in the dense logic problems of her philosophy. Basically, all you do is go along with the BS, but don't waste any energy pretending the BS isn't BS. I'm not saying be a dick about it; just that tolerating bad leadership and copying other people's mistakes are separate things. Tolerate the bad leadership without copying their mistakes.

This simple distinction can serve any programmer very, very well, because, unfortunately, most corporations that programmers work for in any capacity contain systems based on lies. The lie is usually, "you're a programmer, I'm an executive, I know what I'm doing." Actually, the first two parts of that are true; the last part is the lie. That lie gets a lot of corporations into a lot of trouble, and often costs a lot of money.

So on the one hand we have a surefire pair of principles for creating successful technology projects, and on the other we have a nice, simple rule for destroying systems based on lies. And in the hypothetical situation this post opened with, we were tasked with creating successful technology projects in the context of bad corporate strategy - which we have shown is a system based on a lie.

If you've studied the proofs in Euclid's Elements, you know what's coming next:


When you see an executive in your company making some foolish decision, seek to dissuade them; but if they feed you the lie, you know what to do. Comply with their ruling, while adding nothing of your own, and the system of lies will collapse under its own weight. In the meantime, make simplicity a guiding principle, and target the low-hanging fruit with superior technology. Your projects will succeed, and the wasteful corporate foolishness will reveal its true nature soon enough. Don't bother fighting a giant that is going to shoot itself in the foot anyway.

For example, say you've got a corporate decision to build some overspecified monstrosity, when a popular open-source alternative does the job better, more cheaply, more maintainably, with infinitely better documentation in the form of blog posts and support forums all over the world, and therefore with much less overhead. Tolerate the overspecified monstrosity - but use the popular open-source alternative anyway. Say you've got a corporate decision to buy a complex enterprisey package, when you've got developers who can code the core functionality themselves in a few afternoons. Tolerate the complex enterprisey package - but don't actually use it. That would be stupid. Find some useful purpose for the nimble, powerful code, and put it to use. Just do it quietly, without pissing off the VP of Being A Monkey.

Large corporate situations always include low-hanging fruit. Let the overspecified monstrosities fall apart as they are destined to. Let the VP of Being A Monkey spend his gazillions on a one-size-fits-all third-party enterprise app that doesn't do anyone any good. You can't stop them from wasting their time or their money, but you can stop them from wasting your time, and you can always get out of integrating your code with any kind of budget-sucking enterprise money pit if that code targets a sufficiently small, insignificant use case. Don't take on Logic; annihilate Fruity Loops, because then you own the territory completely. Then you have a solid base on which to build, and a small, streamlined project with rock-solid foundations can always pwn an enterprise behemoth that nobody knows how to use.

Quod erat demonstrandum.