Last year I did a North American speaking tour of user groups and small conferences, talking about New Relic. I liked the way the talk turned out and had intended to turn it into a series of blog posts, but then I got sidetracked by designing and coding our PHP agent. Thousands of lines and many months later, we've released the agent, so I have a little time to write about my favorite engineer...

My favorite engineer of all time is Dr. Paul MacCready.

In 1977, in the pre-history before the web, Dr. MacCready and his team designed, built, and flew the Gossamer Condor, the first successful human powered aircraft (HPA). The MacCready team wasn't the only team trying to win the $100,000 Kremer prize — the decade was a hotbed of human-powered attempts — so why did the come-from-behind MacCready team succeed?

They succeeded because they could iterate faster than anybody else. They were agile before agile was popular: they realized that because they didn't know how to build an human-powered aircraft, the key to success was to try something (usually a control system modification), crash, learn from that mistake, and then try again as fast as possible. They designed their airplane to be light, of course, but even more so to be easy to modify and repair. Where the other teams were building light-weight full-complexity wings with ribs and spars and stringers made from very carefully carved balsa, carved to the absolute minimum weight and strength, the MacCready team was building with carved foam, mylar, and spun carbon fiber spars.

Accidents were common; in fact, to save weight, they didn't include a door: they just sealed the pilot in. Thus at the end of the flight, the pilot had to step through the side of the fuselage to exit, thereby damaging the plane even when he flew perfectly!

Because the MacCready team designed for rapid iteration, they were able to fly/experiment twice a day (early morning when the wind was calm and early evening when the wind was calm again). Their closest competitors took months to rebuild after a crash (a.k.a. a deployment) and thus could only fly/experiment a few times a year. MacCready's agile team was 200-300 times more productive than everyone else and THAT, more than anything else, is why they won.

I want to be that much more productive than my competitors. I know I can win if I can release features to my customers 200-300 times more often than they can.

To do that, I need my team's build-test-deploy cycle to be shorter than "the standard" by orders of magnitude: annual releases are just too slow; even quarterly releases are too slow. We need to be doing Frequent or Continuous Deployment (Frequent is between on the order of a few times a week; Continuous is many times per day). And we are:

In my next installment, I'll talk about how we do Frequent Deployments in our push to be Team MacCready-level Agile...