“Better” is the Enemy of “Good Enough”

Written by Sean Murphy. Posted in Customer Development, Rules of Thumb, skmurphy, Startups

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.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 about Chris Crawford’s Storytron effort. 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.

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.

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.

Trackback from your site.

Comments (3)

  • Terry Frazier

    |

    Excellent post. I would rank Chris’ fifth point – validate your market – as No. 1 or at least No. 2. There’s little point in doing anything at all without being sure that you:
    a) have a clearly defined and reachable market, and
    b) can get money out of that market

    This is different than saying that 63 million video games are sold each year to 28 million buyers who spend $5.6 billion dollars and if we can get one-tenth of one-percent market share we’ll be rich.

    It means figuring out if you’re really capable of connecting, and having a conversation, with the people who want/need your product but don’t know who you are. If you can’t do this then planning and coding and mission statements have little real effect.

    If you are a big company, or developing your product within the umbrella of a big company, then there is likely an existing channel or proven mechanism for this connection. It’s not a problem. But if you are a startup you need to answer this question before you do much of anything else.

    Reply

  • Chris Crawford

    |

    Excellent criticisms of our effort; thank you. I have urged everybody on the board of directors to read your comments. One of my own conclusions from all this is that Storytron desperately needs a real CEO. I’m playing programmer, technical writer, demo designer, team leader, and a number of lesser roles — and I’m stretched so thin that I’m doing a lousy job on all of them. I remain confident that Storytron will be successful (oh yes, the software will be ready Real Soon Now!), but I think that our story will be “Incompetent fools screw up just about everything but somehow bumble through to success out of pure cussedness.”

    Reply

Leave a comment

Quick Links

Bootstrappers Breakfast Link Find related content Startup Stages Clients In the News