Where Einstein Meets Edison

Steady Wins The Race, And Other Unintentional Lessons From MIT

Steady Wins The Race, And Other Unintentional Lessons From MIT

Aug 27, 2010

Several years ago, I wrote a tongue-in-cheek essay on lessons I unintentionally learned as an MIT student, as practiced in my career as a software engineer. Recently, the MIT Entrepreneur Review suggested I try a variation with the lessons applied to, naturally, entrepreneurs. These lessons perhaps still tilt toward software startups, but I hope they’re generally applicable. Here is my Part I of the lessons, with Part II to follow soon.

If At All Possible, Work Alone

My software engineering course, 6.170 (MIT classes are known by number rather than name), consisted of successively more complex projects, starting with small modules with well-defined interfaces and culminating in three-person projects where we would partition the application into modules assigned among us and then put everything together for a demo and our final grade.

Our project that year was a Reversi game – my teammates worked on the user interface display and keyboard input, while I worked on the actual game engine. I thought that would be a breeze, since I’d written a Reversi game in high school (and after this course, I would write a multiprocessor version for my bachelor’s thesis). But my teammates alternated between sending me cheery but pointless talk messages in the lab (for you youngsters out there, the forerunner of instant messaging), complaining about my absence when I wasn’t in the lab, and then covered their own asses when our program displayed an obviously incorrect board in the demo (“See, the user interface is working, his game engine must be the problem”).

  • If at all possible, work alone.

That’s what I’m doing now – I have a one-person LLC consulting for some companies and developing games on my own, so I don’t need to hire anyone. If I need help, I can contract the services of my other friends who are running their own “boutique” firms offering graphics, audio, and programming services. And when business is down, I don’t need to fire anyone.

But certainly that’s not enough for everyone. For some, part of the fun is in building a team, sometimes personnel growth is inherent in the business plan, and let’s face it, the business shelf at Barnes and Nobles is not filled with profiles of one-person companies. So I suggest this more general lesson:

  • Don’t hire more people than you need.

Too often, personnel growth is a gratuitous metric of success. I was in one mobile internet startup that hired three or four secretaries after receiving their first round of venture funding, out of twenty employees, total. And then we ran out of money for office furniture.

Increased headcount can be not just an expense, but an impediment to getting work done. Brooks’ law of software development that bloating the team will delay the project applies to everything. Every time I see corporate team-building exercises, I wonder don’t they already have a team-building exercise – the project they’re supposed to be working on? Actually, that’s a good sign you have some dead weight. I managed to squeak out of some off-site “sensitivity-training” sessions, and those were marvelously productive and peaceful days. I would have worked for free.

Of course, if all goes well, there’s natural growth in a startup, but I’ll warn you, things change. When you have only ten people, everyone’s in it together, but invariably once you get to twenty, they’re worrying about their titles and positions in the org chart. The garage days are over.

Keep it Simple

As the final project of my electronics lab course, 6.111, my partner and I wanted to build a computer. My partner wanted to build a Lisp machine – the Lisp machines of the time involved a lot of memory and software, typically selling for $100,000, so I persuaded him to scale our ambitions down to a Forth machine.

But then our teaching assistant looked at our design proposal and felt it wasn’t complex enough and required us to double our chip count. After sleepless nights burning programmable logic arrays, finding/returning/replacing faulty chips, we had a wiry mess of lights that occasionally blinked out a correct computation.

Much time was lost due to the old men staffing the lab parts department who would give the best, i.e. working, parts to the pretty girls (“she has better parts”, one of them replied when asked why he gave atypically good service and components to one of the female students), and recycle the burnt out chips among everyone else. So, the first lesson:

  • Establish a good relationship with your suppliers.

But the real lesson:

  • Don’t complicate things unnecessarily.

It happens in every project, but I’ll just mention one example. I consulted with one group of entrepreneurs who rented Comdex space, a manufacturing facility, tried to target several different markets and attempted to design software, hardware and set up a distribution channel and content deals all at the same time, with many part-timers involved. I thought they should have stuck with their first target market, hired a contractor to prototype a demo system running on a laptop (I estimated a month), and then shop it around. Instead, they spent a lot of money on a product they never built.

Keep It Working

I did build a functioning computer in the undergraduate computer architecture course (possibly my favorite), 6.115. The course progressed through the construction of a computer from scratch – and I mean really from scratch, building the processor and clock, wiring the data pathways, and writing microcode.

The end of the project featured optional entry in a performance contest – if your computer is the fastest, you get to keep it (worth a couple hundred bucks). The hardware guys could add optimizations like caching – I restricted myself to the many obvious optimizations available in the microcode. But even with software changes, there was a long turnaround interval in getting them burned on the PAL’s. In the end, I was unable to enter because my changes were buggy and I didn’t have time to debug-fix-burn-test.

My hardware engineer friends might say I should have left the software alone and worked with hardware, but the fact is, only a few people entered the contest with working kits, and only the winner had achieved a significant performance improvement, so if I’d entered anything that just worked, I could have placed second. And if I’d just added one or two optimizations, I had a decent chance of winning the whole thing.

  • Always have something in working condition.

This is vital for your company’s product. Much of this is a matter of paying attention to boring IT details. I’ve seen several small companies, and even a large government contractor, lose months of work because they didn’t verify their backup systems worked or even that they were backing up the correct drives. And regular clean builds of your code base from scratch (preferably automated) might seem like an obtuse request from your engineers, until a company interested in partnering with or acquiring your company asks you to demonstrate a clean build as part of their due diligence. I’ve heard of one startup acquisition scuttled because of this.

Keep it working should also be part of your product strategy. Much has been written about how companies are too reluctant to cannibalize their existing products. But more often, I’ve seen companies put all their hopes in their next big thing and let their old product accumulate bit rot. It’s more interesting for engineers to build something from scratch and not debug code someone else wrote, marketing would rather tout the fantastic features of the upcoming product instead of flogging the current one (and they love coming up with new product names), and it’s a big ego trip for management. But I think in most cases you can look back and realize – we could have upgraded the old product to the new features instead of starting from the beginning.

In the worst case, you get out of your depth in the new product and have to go crawling back to the old one. I worked on a 3.0 product that was designed and written from scratch and intended to supplant a 2.0 version that was allegedly written by idiots. After two years and ten engineers and design personally supervised by the president, we released the 3.0 version, the company president decided he didn’t like it, and ordered the staff to resuscitate the 2.0 version and call it 2.5 (the first and only time I’ve worked on a product that had a decreasing version number). I guess we were the idiots.

Steady Wins the Race

I was a crunch-time student (which, ironically, has prepared me for common industry worst practices). It seems in hazy retrospect that I stayed up every night cramming. The result was academic probation my second year followed by mediocre grade points the rest of the way.

I noticed the students who had perfect grade points weren’t the whiz-bang smartest – they were the ones who kept regular schedules and maintained discipline, closing their dorm room doors to study, eating regular meals and going to sleep at midnight.

  • I don’t know if slow and steady wins the race, but steady is important.

Crunch time is a notorious problem in the game industry, and prevalent elsewhere. It’s hard to eradicate because it’s exciting. Management can have their Captain Kirk (or Picard, depending on your age) moments, calling all hands to battle stations. In Star Trek, the engineer always finds a solution in the last fifteen minutes of the episode. In real life, more often than not, the product is delayed or goes out with bugs, fingers are pointed, and your more talented employees say never again and send out their resumes. It’s even worse if you muddle through – then no lessons are learned. I once complained to a manager about a recent crunch, and she said, “well, everything turned out OK, didn’t it?”

Out of all the crunches I’ve been involved in, I can only think of one that was unavoidable and not a result of bad planning, bad promises, featuritis, and just plain bad risk management. Would you board a plane if you knew there were last minute design changes, and the service mechanics had pulled an all-nighter and were walking around wobbly on caffeine? There aren’t many managers praised for getting a product got released without drama and with everyone working nine-to-five and well-rested, but there should be.