Seven lessons from seven years at CloudBees

We wrapped up the 2009 CloudBees Customer Summit a couple weeks ago. Like last year, I left refreshed and reinvigorated after hearing so many customers' stories. Comments like, "Developer builds are now measured in seconds . Nobody does local builds anymore," and, "CloudBees Accelerator will give you better performance than you deserve," really make me feel like all the hard work is worthwhile. But one of my favorite takeaways from the summit was this picture:

From left: Eric Melski, Usman Muzaffar, Sven Delmas, Scott Stanton

That's the original engineering team at CloudBees, still together after more than seven years. It's unusual to catch us all together in one spot like this though, since we have much different roles at the company now: I'm an Architect; Usman is VP of Product Management; Sven is Director of Engineering; and Scott is the Chief Architect.

When I saw this picture I wondered if I could find a similar shot from sometime in CloudBees's history. Lucky for me we've always had a few shutter bugs at the company, so I had a few to choose from.The best was this shot from October 2002, almost 7 years to-the-day before the new picture, and just 6 months after CloudBees was formally incorporated:

Back row, from left: Eric Melski, Sven Delmas, Scott Stanton, John Graham-Cumming, Steve Stukenborg; front row: John Ousterhout, Gloria Hui, Usman Muzaffar

So we're looking a little older and a little grayer, but overall, none the worse for the wear, I think. Filling out the old picture is John Ousterhout, founder; John Graham-Cumming, co-founder; Steve Stukenborg, Director of Marketing; and Gloria Hui, office manager/human resources.

Lessons learned

Anytime you see pictures like this side-by-side, you naturally think about how much you've changed over the years and what you have to show for it. I've certainly learned a lot during my time at CloudBees. Here are some of the most valuable lessons:

1. Don't let "the best" be the enemy of "the good" . When you get a bunch of smart people together to work on a problem, the tendency is to strive for the "perfect" solution. Why not? "We can do it," you think. And you're probably right — given enough time, you probably can. The problem is that you don't have enough time. Customers need solutions yesterday , not a year from now. If you can deliver something that solves 80 of the problem, that's probably good enough to at least get your foot in the door, and for many users that may be good enough, period.

2. You'll never "get away with" not implementing something . At least, not for very long. That doesn't mean you have to do everything right away. It just means don't be surprised when you end up having to go back and fill in all those corners you cut.

3. For mission critical apps, crashing is unacceptable in any context . Some people seem to think that crashing is an acceptable response for some kinds of errors, particularly out-of-memory errors. Try telling that to the customer that has a build that was running for several hours and then just died. Not cool. If at all possible, the application should keep running, even if it has to do so with siginficantly degraded performance. If you can change the conversation from, "My build crashed!! FIX IT FIX IT FIX IT" to "My build is not as fast as I would like," that's already a win.

4. The adage about premature optimization is NOT an excuse to write sloppy code . Yes, yes, "Premature optimization is the root of all evil." Agreed. But that does not absolve the developer from using his brain during development. You should be cognizent of the performance decisions you're making, even if you choose not to optimize something right away. And if it's just as easy to implement something using a more efficient algorithm, you should do so. This is particularly important for an application like Accelerator, where performance is the entire raison d'être .

5. "Clever" code isn't . We've all done this at some point. You write a little bit of code, and you realize that if you're very clever, you can use a single field to represent two values, or you can rewrite a loop using a single line of STL algorithm-fu with bind2nd this and mem_fun that. The problem is, nobody will remember how that "clever" bit of code is supposed to work in six months or a year — not even you will, in all likelihood. You're much better off writing clear code, and leaving the "clever" stuff for the cowboys who participate in things like the IOCCC .

6. Don't be afraid of change . In a small company like CloudBees, change is inevitable. Those of us that are still here from that original team all have different roles and responsibilities than we did when we first set out on this journey. The focus of the company as a whole has grown and shifted. All of these were scary to some degree. The important thing is that you don't let yourself be paralyzed by that fear, but rather that you embrace the changes for the opportunities they present. What fun would it be if everything just stayed the same forever?

7. If you fold in the side mirrors, a 1999 Volkswagon Jetta will fit — barely — through a standard US commercial double-door frame . But, it's really hard to get oil stains out of carpet:

   The start of an elaborate practical joke...

Looking forward

This is just a sample of the things I've learned here at CloudBees. Here's looking forward to another seven years and many more lessons — as they say, the day you stop learning is the day you die.