"Better" is the Enemy of "Good Enough"

Better is the enemy of good enough–This phrase is attributed to Sergey Gorshkov, the commander in chief of the Soviet Navy from 1956 to 1985, who managed it’s dramatic expansion during the Cold War. Perfectionists get this wrong, siding with “Better.” Entrepreneurs who prosper, for the most part, side with “Good Enough” and keep improving.

“Better” is the Enemy of “Good Enough”

I was reminded of this quote when I read a recent blog post “Vaporware” by Chris Crawford, who is working on new start-up called Storytron in the interactive storytelling space. I have a lot of respect for Chris Crawford, who is an innovator in the computer gaming field. I subscribed to his “Journal of Computer Game Design” and took away a number of useful insights.

In particular his 1992 article “Lessons from Patton Strikes Back” outlines several useful concepts that most early stage and niche software companies should keep firmly in mind, what follows is a lightly edited summary of his five lessons:

Start with a clear mission statement. The essence of game design is decision-making; a designer makes thousands of decisions during the course of a project. Your choice is always between options with different merits. This is one advantage of the clear mission statement: it simplifies the decision-making process. Instead of asking, “Which option is better?” you need instead ask only, “Which option better fits my mission statement?” This latter question is more precise, more specific, and therefore easier to answer. More important, it is faster to answer. The bulk of a game designer’s important work is making decisions about what to include and what to pass up; anything that makes this difficult process faster and more reliable is worthwhile.
Plan then code at a program level, code then plan at a feature level. Hacked code is so brittle that, over the long run, it takes more time to debug and maintain than properly structured code. [Planned, well structured code] can be easily modified and corrected after it has been written. The early stages of a game project have us writing code that we know will change considerably later on. However, there is another time scale to consider: the short-term time scale in which we write up a single feature. Most game programming is in some way experimental; any feature that is fully understood is probably obsolete in our fast-moving industry. You can’t plan such code in advance; you just have to wade in and hack until you figure it out. The conclusion I came to is this: hack first, then recode it right.
Don’t be seduced by the cleverness of your own ideas. This was the single biggest mistake I made. I came up with a truly clever idea…and I was justifiably proud of it. But it caused too many problems. [It] turned out to be clumsy to use. Most players eschewed it. I should have had the courage to dump a clever idea that, in the final analysis, created more problems than it solved. I didn’t, and the game suffered for it.
Bake the cake first, then add the icing. Publishers sell games in the same way that bakers sell cake. The customer doesn’t taste the cake until he gets it home; all he sees in the store is the icing. So bakers don’t sell cake; they sell icing. In the same way, most publishers don’t give a damn about gameplay (cake); all they care about are the graphics and sound (icing). With Patton Strikes Back, I baked the cake before I even showed it to any publisher. I designed and developed the game first. I finished all the basic game structures, wrote and tuned the artificial intelligence, even got much of the play balance worked out. Only then did I show it to publishers. Guess what they wanted? More icing! At that point, it was easy. Having finished the cake, it was easy to pile the icing on.
Make sure there is a market for your product before you develop it. Patton Strikes Back was a “wargame for the rest of us.” It received excellent reviews. Unfortunately, it has not sold well. It would seem that “the rest of us” aren’t buying computer wargames. The aficionados certainly hated it. Without their support, the game withered…I will never make a significant income from the game. Lesson #5 is, I think, the most important lesson to learn from Patton Strikes Back.

Real candor and some valuable lessons. Two I take to heart are to stay clear on the mission and to guard against being seduced by my own “clever ideas.”

I am of Two Minds on Chris Crawford’s Storytron

It’s possible that they will make a huge breakthrough, certainly he has done several very innovative interactive games to date. His 1982 book “The Art of Computer Design” is out of print but still worth reading on-line for it’s insights into how to create engaging interactive environments, appropriate for anyone developing advanced analytics or social software. But it increasingly looks like an effort that’s suffering from “mission creep.” What follows are some selections from his “Vaporware” post, highlighting the team’s issues with traction and “making things better” (bold text in original):

Perhaps you have noticed that Storytron seems to be suffering from a bad case of the vapors. Our very first business plan called for us to publicly launch everything on January 1st, 2008. That didn’t happen. We pushed the launch date back to March 15th…and we pushed back the launch date to May 15th…once again I went back to the drawing board and came up with major changes… despite the fact that our official launch date has been pushed back repeatedly, our progress has been relentless.

It’s easy to stand on the outside and criticize, so let me just make what I hope is a constructive observation. If you have slipped four times you need to start to radically shrink the mission and focus for your first version.

The website. The Storytron website has quite a few special capabilities that require some custom programming. There’s nothing earth-shattering, to be sure, but it is not a collection of HTML pages. There’s a lot more going on underneath the hood. Louis has been doing lots of coding to make all this work properly, and Pati and Laura have been deeply involved in organizing the overall effort.

If a simple collection of HTML pages would make a “good enough” impression I would consider pushing out a dynamic website to a later version of the product/company. A basic demo has to be central to the mission, but they may be aiming much too high for their initial release.

The reference material and tutorials. This pile is huge. Worse, the technology it explains has been constantly changing. We made changes in April and May that required Pati to completely rewrite large portions of the tutorials. All in all, the content of the materials on the website adds up to about the size of a book — which Pati and Laura have generated in a matter of months.

It’s not clear what the changes were, but it doesn’t sound from the context they are keeping their focus on a simple app and demo for their first release. Again, hindsight is easier but if you find yourself re-writing the manual significantly before the product is in customers’ hands you should consider sharpening your focus and deferring features.

So how much longer will Storytron remain in vapor? How much longer will we give you promises that we later break?

If you find yourself worrying that prospects no longer believe you–and therefore no longer trust you–you need to change methods. Trust is hard to earn and too easily lost. I would think that they could sort their early users by risk tolerance and relevant technical skill levels and release the current “deficient” version to those it’s unlikely to turn off.

The board of directors discussed this matter at length at its recent meeting, and we hammered out the details of how we’re going to handle the launch. This time, though, we really want to be sure about our promises.

Again, you always want to be sure about your promises. One of Gerald Weinberg’s key observations for consultants and other change agents–and make no mistake about it, Chris and the Storytron team are trying to trigger a revolution in interactive entertainment–is that “people don’t tell you when they stop trusting you.” And once you’ve lost their trust, there is little basis for the kind of relationship that’s needed to convince early adopters to work with you.

Therefore, all we are saying at this time that the launch will NOT occur before August 18th. We are HOPEFUL that it will occur by September 1st. And that’s the best we can say at this time.

It’s better to give a “blood date” (vs. one written in pen, pencil, or crayon) and then work to beat it. It doesn’t sound like the team has a date that they are committed to hitting. This can be the death of many of promising start-up.

The Slow Death of Good Intentions

Please do not conclude that we couldn’t meet a deadline to save our lives. In every case, we have deferred the launch in order to improve the quality of our products. We could in fact have launched on January 1st, 2008, as originally planned — and the product we had ready at that time was better than what was originally planned.

This may be a slow death by good intentions. No development team ever slips a product to make it worse (in their own mind).

However, we deemed it to be unacceptable, so we pushed the deadline back.

As a rule of thumb the second time this happens you have to start to reduce the scope of your efforts and the mission you are trying to accomplish. In particular, bootstrappers have to sell what they have. Gordon Bell writes about the “Schedule Fantasy Factor” which he defines as the ratio of the time allocated to a particular task divided by the time it actually took. His belief is that a ratio above 1.2 puts a project in trouble: if it’s above 2 he believes that you are doing research, not product development.

The same thing happened in mid-March; Swat and Storyteller were better than we had expected back in January — but they still weren’t good enough. The changes we have been making have dramatically improved our technology. Yes, it’s frustrating to have to wait. You think you’re frustrated? However much you’re frustrated, I’m frustrated a lot more. But we only get one chance to show off to the venture capitalists, and we want to make this our best shot.

Normally the venture capitalist’s question is not “can you make this work?” but who wants to buy it, how much will they pay, and how many of them are there? Remember lesson 5, the real risk is not that you can’t ultimately do what you have set out to do, but that once you have a working technology you will discover that the market you anticipated for it does not exist. It’s a risk that many innovative start-ups face.

Follow Up

Update Dec-31-2008: the Vaporware blog post is still up on the Storytron blog site but none of the permalinks for the individual posts resolve correctly. To read the post go the blog and look for July of 2008 in the archives.

Update Dec-21-2015: The Storytron site now has a banner:

The Storytron is currently in a medically-induced coma while we re-design the technology. We have retained some of the tutorial and explanatory material from the old website. This will permit you to explore what is still the most advanced technology for interactive storytelling ever built.

He also has a page “What Went Wrong.” Here is an excerpt of the key section:

In 2006, I realized that Internet usage had penetrated so deeply that it could provide a basis for a new business model. I worked for three months putting together the entire plan, then set to work in January of 2007. We jumped through all the hoops of setting up a corporation that could receive venture funding, and I recruited Laura Mixon, Dave Walker, and Irene Boczek to serve on the Board of Directors, and we all set to work.

Like any startup, it was an intense effort, with long hours day after day, and no breaks or vacations. We recruited several more people to help with the programming, and they made huge improvements in the rather amateurish code that I had written until then. Kathy and I took out a big mortgage on our house, and we got some “friends and family” money, and we were actually able to pay the employees.

The crucial task was the creation of a good demo of our technology. Since we were planning the technology to be used both for entertainment and business training purposes, I decided to create a storyworld that straddled both areas. This was my first big blunder; by trying to meet two divergent sets of goals, I guaranteed that I would meet neither set of goals. Moreover, I allowed my perfectionism to screw up the schedule: the development tool, SWAT, was not ready in time. I had to work frantically on SWAT and a hundred other things that have to be done in a startup. I simply didn’t have enough time to do a good job with the demo.

Nevertheless, we published it in March of 2009. It stank, which pretty well destroyed our chances. Nevertheless, we tried to rustle up some investment money so that we could build some more demos. Our timing was execrable: we were trying to raise money in the middle of the most serious recession since the Great Depression. Venture capitalists were not exactly eager to invest in us.

So we ran out of money. I first attempted to fix up the original demo (“Balance of Power, 21st Century”). That didn’t work, because the subject matter was insufficiently dramatic. I made another attempt with a storyworld based on the Arthurian legends. That one actually got pretty far, and was pretty good, but I ran out of creative steam and set it aside. In early 2011, I had a brainstorm for how to build a storyworld more easily, and made goodly progress on that. However, in June of 2011 we set that project aside as well.

The fundamental flaw in the design was that I had been insufficiently ruthless in keeping the technology simple. Every time somebody thought of a new improvement, we threw it in. Sometimes I resisted improvements that I thought didn’t add enough. But overall, I permitted the thing to become a huge monster. Just look at the tutorials or the author’s guide elsewhere on this site; this thing makes Microsoft Word look like “painting program for children”.
Chris Crawford in “Storytron: What Went Wrong“