FogBugz and Schedule Realism

I am an obdurate optimist when it comes to software schedules: It is extremely rare that anything new happens in computer science or software engineering—existing ideas just get combined in useful ways. Since it has all been done before, how long could any one thing take? A week? Two?

FogBugz, which offers free hosted accounts to one and two-person startups, has a terrific feature. Evidence-based scheduling estimates when you’ll be done based on your past performance. There’s only two catches: First, you need to add items for everything on your schedule and estimate (however optimistically) how long they will take. Second, you need to track which of those items you’re working on and for how long. A little widget, ever-present in the top right corner of FogBugz, helps you do the tracking though.

I have used FogBugz on personal coding projects in the past and its estimates are great. Tonight I poured my task list into FogBuz; my task list which had burgeoned from a couple of items to a multitude. The result is pretty sobering. FogBugz estimates that I’ll hit my next milestone sometime between March 2, 2010 and June 20, 2010.

A Survey of Flash Features

I have started a micro ISV. I’m writing some software aimed at casual game developers who use Flash. The Flash space is pretty complicated: There have been ten major versions of the Flash player over more than a decade. There are two major languages for writing Flash games: ActionScript 1-2 and ActionScript 3. Each language lets you use a different, overlapping set of features. You can author Flash files with graphical design tools or open-source command-line compilers. I need to figure out which uses of Flash I will support in “version one” of the software I’m writing.

I have decided to tackle the problem of deciding what to support by measuring what developers actually use: I played 123 SWF files that were linked from the front page of a popular Flash game site. Popular games and recent games appear on the front page of this site, which means these data are biased towards popular games and recent games. That’s OK—the software I’m writing is for successful, active Flash game developers. They should be the ones writing popular, recent games.

80% of the games are Flash version 9 or 10. Despite that only 73% (but still 73%) of the games use ActionScript 3.

Forty-eight different kinds of tags appear. Here’s a histogram the number of games which use each kind of tag (not the number of times the tag appears):

123 ShowFrame
123 End
122 SetBackgroundColor
119 FileAttributes
119 DefineSprite
109 DefineShape3
108 DefineShape2
 96 FrameLabel
 90 SymbolClass
 89 DefineBitsLossless2
 87 DoABC
 73 ScriptLimits
 64 DefineBinaryData
 59 DefineSound
 59 DefineShape
 55 DefineFontAlignZones
 55 DefineFont3
 53 DefineEditText
 52 DefineBitsJPEG2
 51 DefineText
 51 DefineShape4
 50 SoundStreamHead2
 49 CSMTextSettings
 48 PlaceObject2

 47 DefineFontName
 46 RemoveObject2
 43 DefineBitsJPEG3
 42 DefineButton2
 41 ExportAssets
 33 DoInitAction
 33 DoAction
 32 UnrecognizedTag
 31 DefineMorphShape
 30 JPEGTables
 30 DefineBits
 28 PlaceObject3
 19 DefineSceneAndFrameLabelData
 19 DefineBitsLossless
 18 DefineMorphShape2
 17 Protect
 14 Metadata
 13 DefineText2
  8 StartSound
  8 EnableDebugger2
  8 DefineScalingGrid
  7 DefineVideoStream
  7 DefineFont2
  5 DefineButtonSound

OK, everyone uses ShowFrame and End, no surprises there. Thirty-two files had tags which aren’t mentioned in the SWF file format spec. Here are the offending tag numbers, the number of files they appeared in, and the number of times they appeared:

Tag  # Files  # Times
253       9      536
255      16       16
 41      11       11
 63       6        6
 72       3        3

If you know what tags 41, 63, 72, 253 and 255 mean please post a comment!

Lastly, here’s how popular different combinations of file attributes are:

 69 ActionScript3 UseNetwork
 16 (FileAttributes tag present; nothing turned on)
 11 UseNetwork
 10 HasMetadata ActionScript3 UseNetwork
  9 ActionScript3
  2 HasMetadata ActionScript3
  1 UseGPU
  1 HasMetadata

These data are from games on one site, so I’m not going to make any firm decisions about what the software I’m writing will support just yet, but it looks like:

• Because I only have resources to support one of ActionScript 1-2 or ActionScript 3 at first, it would be better to support ActionScript 3.
• These games use 48 different kinds of tags I need to understand. (Incidentally, concentrating on ActionScript 3 doesn’t simplify things—the ActionScript 3 games use 45 different kinds of tags between them.)
• A lot of games want to use the network. There’s no easy way to tell if they work unplugged from the network too, though.

Next I need to pull apart the contents of the DoABC tags and see how much of the Flash API these games use. I also need to look at games from other popular Flash game sites.

Who Will Buy?

I’m building a micro ISV. I’m a software engineer, so I’m writing some software. I’m being conservative while I’m getting started—I haven’t quit my day job. I’m not maxing out my credit cards for financing. I have an idea, but I’m prepared to try something else if it doesn’t work out.

Many successful entrepreneurs say that it is better to burn through your bad ideas quickly so you can find an idea that sticks and focus on it. And one way you find out if your idea is bad or sticky is by asking the people you expect to buy it: “If I had this—bread that was sliced so you didn’t have to slice it yourself—would you buy it?” Do this, they say, before you spend time actually building the bread slicer. That is what they mean by Sell-Design-Build-Sell. If no one is interested in sliced bread, move on. If sliced bread has already been done, people will tell you that, too. If people are interested in sliced bread then make it happen.

The software I’m writing is aimed at casual game developers, so today I waded into a Flash programming forum. Lots of casual games are written in Flash. Things didn’t go well. First I searched for keywords related to my idea, which turned up two likely discussion areas: games, and general chit-chat. I created an account, filled out my profile, read the forum rules, and wrote a post. Forums have to win a serious battle with spam or they become worthless. Unfortunately, even though I don’t have anything to to sell, my message—would this interest you?—looks like a spammy come-on. Worse still I didn’t see the specific rules of the games section of the site, and I didn’t tag my post with the appropriate name.

Mercifully my post was approved and I received a few responses, which highlighted a couple of interesting things: Firstly, there’s a big “back catalog” of Flash games written in ActionScript 2. Some new games are written in ActionScript 3. Secondly, although there are alternatives to Flash like Unity 3D and Haxe, they’re mostly technical curiosities for Flash game developers. (Of course, I did post to a Flash developer forum, and even there there is some evidence of developers departing for other platforms like the iPhone.)

Reading between the lines, I think there is tepid interest in the software I’m developing, but it might be best to approach the Flash game development community as two different constituencies: ActionScript 2 developers, and ActionScript 3 developers.

The Web Startup Success Guide

I have preordered The Web Startup Success Guide. This is Bob Walsh’s third paperback book. Micro-ISV: From Vision to Reality is his best-known book. His second book, Clear Blogging, is good too. I hope The Web Startup Success Guide will be Micro-ISV for the Twitter age.

Sell-Driven Development

The creator of COM once told me: “software works if someone will buy it.”

Yesterday I was listening to Episode 28 of The Startup Success Podcast, and guest Sramana Mitra emphasized startups should Sell-Design-Build-Sell.

A sensible plan for a startup might look like this:

1. Think of an idea for something people might buy.
2. Design it.
3. Build it.
4. Sell it.
5. Go to step one.

There’s nothing wrong with this plan: To be successful you must complete all of these steps. But the plan is very inefficient. As engineers, we can almost subconsciously filter out things that we can’t build, but we don’t have any intuition about marketing and sales. As a result we invest a lot of energy in designing and building things that turn out to be difficult to sell, and we go back to step one not richer but poorer.

Consider this: You wouldn’t write all of your software before you test any of it. The stuff you write will turn out to be crap because it doesn’t do what you wanted it to do and you will have to rework it to get it right. If things go really badly, you may have to throw it all out and try something else. So you don’t do that. Instead, you test your software as soon as you can.

But remember, software works if someone will buy it. And you can find out if someone will buy your software very easily—pick up the phone, or open your email client, and ask them. That’s what Sell-Design-Build-Sell does:

1. Think of an idea for something people might buy.
2. Find some people willing to buy it.
   • If nobody is willing to buy it, go back to step one.
   • Otherwise go to step three.
3. Design it.
4. Build it.
5. Call the people from step two back, and sell it to them.
6. Go to step one.

I’ve also made the bitter realization that I’ve heard Sell-Design-Build-Sell somewhere before: Three years ago, listening to Greg Gianforte’s advice on bootstrapping and reading his book. Three years!

Tomorrow I’m going to outline what I’m working on. Then I’ll send this to some potential customers and ask them if they would buy it.

Slowly But Surely

I’m writing a library to read this binary file format; I’m 25 pages through a 386 page specification. Slowly but surely my code base has grown to 500 lines of code. I had no idea I wrote code this slowly. At this rate I will be able to read these files—step one—by the middle of next month.

I found the result of today’s work gratifying: I downloaded a random file and threw it at my reader. It decoded the file header and printed sensible data. Unit testing is great. Now turn to page twenty-six…

Mac Developer Network Interviews Bob Walsh

If you need a nudge over the cliff to starting a micro ISV, listen to the Mac Developer Network interview Bob Walsh, author of Micro ISV: From Vision to Reality and other books. It’s much, much worse to not try than it is try and fail. Developers have to start learning by doing, and persevere through the failures that come with the demands of learning a lot of new things at once (like doing market research; advertising; and making methodology and technology choices without typical big-company constraints.) At least you’ll learn something.

Today, pleasantly, I committed two hundred or so lines of code—my micro ISV’s first intellectual property asset!

Hello, world

Starting tonight, I’m a micro ISV. I’m a software developer by day, and I really like my job, but when I read about micro ISVs I feel like I’m missing out on something—perhaps there’s a lack of essential ramen in my diet. From what I’ve read in Founders at Work, having the idea isn’t as important as working hard enough and for long enough to try out ideas until you find the idea. Tonight I set up a source code repository for the first micro ISV idea I’m going to try. I’m not ready to share this idea with you yet: First I’m going to do some research to see if the idea is technically feasible, and whether anyone has done it. But I will blog about what I find.