Plan to Throw One Away
A story about Ruby.
This year, 2017, Cooper is celebrating its 25th anniversary. We’re planning a party, everyone is remembering stories from the early days, and we’re recalling the lessons we learned from them. Here is a tale from an even earlier time, but the lesson remains just as valid.
Back in the day, the mentality was the more code you could ship the more money you could make. But one of the most important new lessons of the digital era was that code could be a liability as much as an asset.
But human nature being what it is — wrong most of the time — people want to see results. They want to see forward motion, even though this is just an illusion.
In our business environment so dependent on innovation and creativity, we need to bring an appropriate mindset to the problem. Sometimes creativity looks a lot like people wasting time, playing games, daydreaming, or just standing in the shower staring off into space. It usually looks stupid. People want to see concrete poured and bridges built. They want to see visible progress and measurable increases.
Really, these are just cries for help. They may claim that great success demands lots of work while they conveniently forget that people worked just as hard on humungous disasters. They ignore the downside and see only the benefits. In the words of digital pioneer Frederick Brooks, “One can often get something for nothing, if one has previously bought nothing for something.”
Frederick Brooks wrote one of the very first books that reflected philosophically on the practice of software development. In 1975, he published a brilliant collection of essays entitled, “The Mythical Man-Month.” If you buy two copies of the book, you can read it twice as fast.
One of his chapters was entitled, “Plan to Throw One Away,” where he made the revolutionary claim that the value of writing code was what you learned from the exercise, not the code in and of itself. In the late 80s I had the unique opportunity to prove the truth of Brooks’ assertion in a high stakes game of software development.
In 1988 when I was in the business of inventing cool software and selling it to publishers, I wrote a visual programming language I called Ruby (no connection to the programming language invented a decade later). When I showed it to Bill Gates, it blew his mind. He bought it on the spot, claiming that it would influence their entire product line. It was finally released to the public as Visual Basic, and did indeed affect most Microsoft products.
But in the beginning, all I had was a prototype. It was about 15,000 lines of ugly C code. Based on that, I wrote a detailed specification document describing the product, and then I threw the Ruby prototype away.
Bill Gates wanted Ruby to ship with the upcoming Windows 3.0 release, so he turned management of Ruby over to Russ, who was in charge of 3.0. Russ was a young and brash senior executive, empowered but scared. I used to joke that Microsoft gave newly-hired executives a computer, a desk, and enough rope to hang themselves. Russ was good, and release 3.0 would eventually be regarded as the first successful version of Windows.
But when Russ found out I had discarded Ruby, he freaked out. He started shouting at me, saying that I would miss our deadlines, I would derail the entire project, and that I would delay the shipment of the whole 3.0 product.
Having presented him with a fait accompli, there was little he could do except predict failure, but I knew that Brooks was right, and starting over from scratch would speed things up, not slow them down.
Eventually, I delivered the final master to Russ right on time, while his part of the project ended up shipping eight months late. Even though it’s counterintuitive, tossing out code can be faster and more efficient than trying to turn an experimental prototype into a shipping product.
By definition, creating innovative stuff demands doing things that haven’t been done before. So building an innovative product half way, then throwing it out and building it a second time to completion will not only take less time than building it once, but will result in a far better product, both from an engineering standpoint and from the user’s perspective.
