Or, “The Tortoise, the Hare, and the Unicorn”.

I spend a lot of my waking hours trying to create nice things with software. I care about my efficiency, both in the short run and the long run. It’s my time I’m burning, after all… it’s finite. And so the topic of creative efficiency has been on my mind lately.  I think it’s a vital topic in the creation of many different sorts of things — design, software, food, movies, and books, for starters — but I’ll stick to my knitting here and write just about software.

There seem to be two different schools of thought in software development: let’s call them “Pay as you go” and “Buy now, with no money down!”. (Yes, with an exclamation mark.)

Tech industry rags like TechCrunch like to publish stories in the “Buy now, with no money down!” category. They tend to run something like this:

I was sitting around the other day inventing awesome ideas like I do. As usual I came up with some exceptional stuff, and this time I chose one of my particularly outstanding ideas and decided to go for it. Since I am already doing an 80-hour a week job at Amazing-Company.com I figured it was no big deal to do a little more on the side. I asked three of my favorite genius buddies to go in on it with me. We got all stoked up on <favorite energy drink>, busted out <latest shiny hipster technology> and started working all-nighters and weekends. A couple of weeks later, bingo! Out popped our killer app. We knew it would be awesome, but damn if it isn’t even more more awesome than we planned! We’ve already sold 3 million copies on <App Store | Android Market> and the traffic from TechCrunch and Hacker News brought our site to its knees. And that’s just the MVP, yo. We took a 2-hour break yesterday and now we’re working on version 2.

Horseshit.

Stories like this probably drive a lot of ad revenue, but they are misleading, at best, and damaging, at worst, for people who actually want to create something good. Here’s why:

Unicorns are rare: First off, we would all love to work with geniuses who consistently churn out large amounts of production-quality code in short amounts of time. I’ve had the pleasure of working with a few people like this. They do exist. Alas, they are only slightly less rare than unicorns. And they tend to be quite selective about what they want to work on. So while you should certainly seek smart people to work with, don’t peg your business plan on hooking up with a bunch of geniuses, ‘cuz it probably ain’t gonna happen. (Dear reader, if you are a genius-unicorn-type-person, please stop reading now and email me as I’d love to work with you on my next awesome idea. Seriously.)

Hero-working sucks: Secondly, the “hero” work method is painful and usually long-term-bad, for reasons I outline below. For every company that succeeds working this way there must be hundreds who fail. Popular media tends to skip over those failures and glorify / whitewash the successes.

Here’s the classic “Buy now, with no money down!” storyline, as commonly found in popular press: Round up some unicorns geniuses. Incent them to work as many hours as humanly possible. Fuel them with food, drinks, money, candy, bacon, apples, hay… whatever motivates them. Set hardcore release dates and explain repeatedly and heatedly how vital it is that the dates are met. Ship. Repeat. Massive success!

So exciting!

Unicorns! Hardcore release dates! Bacon!

And here’s how it normally plays out in reality: due to a curious shortage of unicorns geniuses, management reluctantly hires merely-smart people, wishing out loud they were smarter. Managers amp up the reality distortion field and succeed in convincing everyone to work a lot. Perhaps they are lucky and the initial product release gets out the door quickly. And if they’re really lucky the product will work for a while. But they eventually discover that under the intense pressure and grueling work conditions they’ve created, employees have…

1. Made more mistakes.
2. Cut corners on quality. Most commonly, by testing only manually, instead of writing automated tests. Or by pushing half-finished code under the carpet, hoping it won’t be found until much later.
3. Hacked and flailed at the code until it works, instead of building it to last.
4. Lost motivation.
5. Gone emotionally flat. (Burn-out = numbness.)
6. Disengaged with the job/team/workplace.

This is why I call it, “Buy now, with no money down!”. It’s equivalent to taking out a high interest loan, in that there’s never a convenient time to pay it back, you must eventually pay, and the payback really hurts.

So what does payback look like? More time to fix bugs, fill in the gaps, and rewrite shitty code when you want to upgrade and extend the system. More time to rehabilitate, re-recruit, or replace burnt-out and demoralized employees. And more cost scrambling to retain pissed-off customers and acquire new ones.

I’m not making this stuff up. For real-world examples, read the Steve Jobs bio. Steve worked exactly this way.

The two exceptions I can think of where you don’t have to pay off the loan are toy apps, i.e. software that is trivially simple, and throwaway code, i.e. code you will use for only a very short amount of time and then archive or sell to a naive buyer.

So what’s an alternative, you ask?

• Hire good people. They don’t have to be geniuses, but they do have to be smart. You should be able to find people who are instinctively driven to get the right thing done, have great potential, and have passion for the work itself.
• Invest continually in good, simple design. One should always strive for this, but it takes time, money, and skill (hard to find). This makes it tempting to underinvest in design and just skip straight to writing code, especially if you yourself know how to code. That’s usually a mistake. Story for another day.
• Build atop existing successes. In software, this means things like (a) making smart choices in platforms and tools; (b) avoiding Not Invented Here syndrome; (c) copying/cloning, existing successful patterns, which can be very effective, but doesn’t obviate you from the need to differentiate your product.
• Bake in quality up front, when you build it, instead of deferring problems to be fixed later. A big part of this is testing the product, both manually and with an automated test suite. Features aren’t “done” until you’ve built repeatable automated tests.
• Take the time and care needed to keep things simple as the project grows. This means reusing and refactoring code you’ve already built, cleaning up messes you make along the way, fixing performance bottlenecks as they come up, and so on. It’s like weeding a garden.
• Work at a sustainable pace. When you must, burn the midnight oil, but only as a band-aid for emergencies, i.e. urgent unplanned work. Don’t do this as part of your normal plan.
• Use historical data to predict what your future velocity will be

I call this approach “Pay as you go”. I’ve found it to be a more humane and efficient way to work, both in the short term and long term. I aspire to work this way. I am getting to be OK at it.

Some people will scoff at this and call it too idealistic or unrealistic. “By the time you get your v1 out, your competitor will already have locked up all the customers”. Investors and execs may ask, “why aren’t we moving as fast as Competitor X? Are you guys just being lazy?”. It does require more trust: you have to place faith in the product team, trust their estimates, and trust that they are working as hard as they can to build a great product, even when you don’t see them sweating bullets. Or building a pile of empty Red Bull cans on their desk. Or punching in 12-hour days, 7 days a week.

But it can yield great benefits. You’ll probably build a better quality product, for starters…  a product customers will be more likely to love. You accrue less technical debt in the codebase.* You can ramp up new employees quickly because your system is clean and simple. Your employees aren’t burnt out, and they like the work. You can predict with honesty and higher precision when you’ll actually ship something new that you’re committing to, because nobody is lying about dates, or lying about quality, or about to quit. And your test suite enables you to add new features with fairly high confidence that you aren’t breaking existing stuff. Long term, you come out ahead.

There’s more; these are just the highlights.

Pay as you go may not be as glamorous as “Buy now, with no money down!”, and it may not get you written up in TechCrunch. But it’s achievable, and affordable too.

*  I’m not necessarily saying to shoot for zero technical debt… zero technical debt is often a silly and suboptimal goal. But carrying only a low amount of debt is good, because it enables you to move forward at consistent speed instead of being forced to stop for a month or two to fix bugs.