Fog Creek released a new version of FogBugz this week with something called Evidence Based Scheduling. It feeds project tasks and developer characteristics, along with historical data, into a Monte Carlo simulation then builds a probability distribution for project completion.

By coincidence, I was reading about statistical methods for project estimation several months ago. (All I was looking for was a probability distribution that a typical project would meet a set timeline, but you know how easy it is to get sidetracked on the web.) It turns out there are a number of stochastic project scheduling techniques that use Brownian motion (aka random walks), Kolmorogov extensions, and a number of other things that bring about bad flashbacks to my Applied Statistics class (hint: “Applied” in academics means “Theoretical” in the sane world).

In short, it’s the kind of stuff that makes my brain throb. So kudos to Joel Spolsky and the team at Fog Creek for pulling this off (assuming it works as advertised).

But, one of the things that I told myself when I started BreezeTree Software is that I would build to a feature list, not to a set schedule. I never wanted to feel rushed to get a new version out the door before it was feature complete.

I’m starting to realize, though, that this philosophy makes no sense. The problem with it is that the list of planned features exists in my mind. If you don’t make any commitments about a particular feature, releasing a new version without the feature wouldn’t disappoint anyone or break any promises.

As I’ve said in other posts, the road to FlowBreeze 2.0 was pretty rocky. I had “completed” version 2.0 back in early March.

Then I threw it all away.

And I feel fine.

I made the decision at the earlier juncture to pull back 2.0 and refactor the core for a variety of reasons. They were are solid reasons from both a technical and business perspective, so I don’t regret them. As the months wore on, several epiphanies sprang to light and complications like the Software Passport (Armadillo) compatibility problems arose. These pushed the schedule out again.

When I sat down to write up the 2.0 release announcement, I looked at all the features I’ve added. Many of them were completed months ago. Of those, most relied on the new core but others didn’t. So this begs the question, by not releasing the features that were already complete, was I depriving existing customers of valuable improvements just so I could feel it was “feature complete”?

Understanding Opportunity Cost

I made the mistake of telling several customers that FlowBreeze 2.0 would be released by the end of the August. I missed that target date. If I had cut a few features I could have made the target date. As I said, one of my goals was to release to a feature set instead of to a schedule, so I chose not to.

I think this is one of the toughest decisions indie software developers face. It’s easy to become emotionally attached to a feature or two and think they must make the next release. It’s also easy to always view your application as feature incomplete compared to the long term vision you have of it. Meanwhile, customers are blissfully unaware of that feature complete vision in your head.

And that’s where the concept of opportunity cost comes in. Opportunity cost is one of those basic concepts you learn in school or on the job. In a nutshell, allocating resources to one thing means you can’t allocate them to some other thing. That plus the unrealized benefits from the path not chosen are the opportunity cost.

There are probably better definitions out there, but it doesn’t matter. Because you’ll never really understand opportunity cost until you run your own business. When you work for a company or organization, those opportunity costs get absorbed elsewhere, and you usually don’t feel the consequences. When you run your own business, you feel the consequences right in your pocket.

So spending more time on development means spending less time on marketing. Likewise, having longer release cycles means less marketing bursts in the form of press releases, announcements on your blog, site submissions, or simply cool new benefits you can showcase on your product page.

If you don’t work to a schedule, you are not controlling your most valuable asset. The biggest opportunity cost decisions you face are for the allocation of time.

That Damn Monkey

So having already admitted that the cymbal-banging monkey in my brain was wrong about the “build to features” scheduling mentality, I will try (it’s hard!) to switch to a time based release mentality. Ultimately, it would be nice to build a given feature set in a given amount of time, but past history leads me to believe that I would be wrong 99% of the time.

So I will monitoring the airwaves to see what others are saying about FogBugz’ Evidence Based Scheduling. I’d especially be interested in any one or two man shops that use it. Hopefully the feedback will be positive, and it won’t take forever to build up a sufficient data bank of historical inputs.