Trying stuff

Google is one of the few large companies that gets one fundamental rule of the Internet: Trying stuff is cheaper than deciding whether to try it.

Monte Carlo. It's a car. It’s a song. It's a casino. It's a city in Monaco (near France, somewhere). It’s also a method of statistical simulation that is used to better understand the probabilistic distribution of known set of data. Great. So what?

I recently attended the Atlanta session of the FogBugz World Tour to hear from Joel Spolsky about the latest version of his bug tracking software, FogBugz 6.0. Joel Spolsky has been writing about software development, management, business, and the Internet at joelonsoftware.com since 2000. Three books have sprung from content on his site: User Interface Design for Programmers, Joel on Software, and Smart and Gets Things Done. They are good reads for software developers and business folks alike; smart, funny, and focused on the human face of software development.

Before starting his company, Joel was a Program Manager at Microsoft on the Excel team to provide programmability to Excel.

The new release of FogBugz has quite a few nice features to make bug tracking much easier, but I was most intrigued by the new capability called Evidence-Based Scheduling, or EBS for short. This new capability uses a Monte Carlo simulation approach to determine probabilities associated with the expected “ship dates” of the software release project.

The core premise behind this capability is that unlike in the financial realm, in the software world, future results can accurately be based on past performance. FogBugz remembers the original estimate and the actuals for each task for each developer, and for all the projects they've been assigned to. Here's where it gets interesting. Based on this information, FogBugz runs a series of Monte Carlo scenarios where it randomly generates different plausible results for each member of the development team. It then assembles the results to create a distribution for probability of completion for each developer—and more importantly, for the entire project. The result of this analysis is a "Ship Date" probability curve that shows potential ship dates on the X-axis and probabilities of achieving those dates on the Y-axis. Ship Date depends not only on estimates for remaining components, but also on the probability that the individual developers will be able to individually meet their commitments. A steeper curve means the developer estimates are more confident and a flatter curve means estimates are less confident.

The classic software development process involves balancing three things: time, money, and features. Most projects of reasonable duration are not going to be able to effectively add staff mid-stream—at least not to accelerate delivery timeframes. If you assume the primary factor in determining "money" is tied to people, time and features are your only real variables. FogBugz 6.0 lets you experiment with changing these two factors. This is a useful tool. Consider a scenario where the business people come to the development lead because they need a project to be complete by a specific date. This tool gives the project lead enough information to understand the probability of making a specific date. Additionally, it lets you test out what will happen if you remove a particular feature. With this new information, the development lead has the visibility to provide back additional guidance to the project sponsor about the probability of making the requested date, as well as the effect that changing release date and scope have on the probability of on-time delivery.

So how does it know? The ship dates are based on each developer's history of estimation accuracy supported by developer time sheets. Yes, that’s right. I said time sheets—the bane of all developers. But stick with me, it's not as bad as you might think. Each developer (or responsible team lead) can turn on a timer that automatically tracks time spent on each of their cases.

Fogbugz plots a linear fit through the data points for each developer and then uses the calculated R² value to determine how consistent the developer’s estimates have historically been. Based on this calculation, probability distributions for remaining tasks for each team member are determined, which leads the ship date probabilities. It’s then easy to see the long pole in the project (Milton Ritchie in this example). This doesn’t necessarily mean the most work, but only reflects the probability of on-time completion—and correspondingly, the most risk to the project.

Anyone who has followed Joel's writings knows that he is keen on the idea of improving the process of software development. And, we all know that estimating an accurate time to completion, or “ship date,” for any software project is a pain in the rear even after all these years of "practice." The unique approach that Fog Creek takes is not to predict the specific completion time, but rather to predict the probability of completing the project across a range of dates.

So, project estimating will likely never be a simple turn and churn process. But with this release of FogBugz, Fog Creek Software has shown great outside-the-box-thinking that could significantly improve how we deliver software projects.

Google Analytics has been rebuilt and the result redefines the frontiers of doing analytics on the web. Avinash Kaushik has the definitive early review.

I had the privilege of attending the launch and playing with the early release. Here are a few things I noticed.

• Speak my language: Google has put a lot of effort into replacing specialized terms with everyday ones. This makes the application usable by a broad base of people and is one way to fight GUI Jock-itis.
• Speed kills: The interface is easily reconfigurable and fast. I've long argued that interface speed is a substitute for configuration options. I'm curious to play with the tool and get a better sense if this is true.
• Flex rules: Much of the componentry for viewing data in Google Analytics is built in Adobe Flex. This is similar to Google Finance, and not at all like GMail or Google Reader, which use the GWT. We believe this has profound implications for analytical tools on the web and will dig into this in later posts.

Last week I challenged the you to reproduce this alternative to pie charts in Excel. I promised a screencast to show how it's done.

Eighteen people answered the call with nearly three dozen different solutions. Click here to watch the screencast showing how to accomplish the two most popular solutions; filling cells with conditional formatting and pushing the column chart to extremes.

If you want to look at the source,Clint Ivy produced an excellent version of the cell filling approach.

square_pie_clint_ivy.xls

Dermot Balson submitted an terrific version of the column chart approach.

square_pie_dermot_balson.xls

Thank you to everyone who submitted a solution.

To paraphrase from Really Bad Metaphors:

"Presentations can be as lame as a duck. Not the metaphorical lame duck,

either, but a real duck that was actually lame, maybe from stepping

on a land mine or something."

Here are a few ideas to create spicier presentations:

1. Get thematic. Chose a theme that drives home a general concept in your presentation, then sprinkle it throughout your presentation. For one client, we presented an analysis that ended with a movie. Throughout the presentation we offered subtle hints in anticipation of our grand finale. Avoid themes that could also be used for a high school prom (e.g. A Winter Wonderland, Magical Memories).

2. Change of pace. Break up the action with picture-only slides (see Beyond Bullets, Presentation Zen) or multimedia (i.e. audio or video clip). A little fun in the middle of a bunch of dry slides can help wake up the audience.

3. Use a human voice. Surprise your audience by departing from the traditional business-speak. Try writing slides that don't over-qualify the message or attempt to be comprehensive in the descriptions. Lawyers need to cover all their bases with that kind of language; you need to convey a simple message that will stick.

Instead of "IT organization has little understanding of business units’ long term strategic direction and impact on technology needs", say "IT and business aren't on the same page."

Instead of "Disparate and redundant technology solutions leads to increased operating costs", say "Technology tangle is taxing."

4. Just the answer. Present your conclusion, then ask the audience if they they need to know more detail. If not, meeting over. I haven't tried this, but surely a five minute presentation with a simple take-away will be as memorable as the typical presentation death-march.

5. Something to remember. Provide a simple, memorable acronym or metaphor so they will at least walk away with your key point. For example: Good presentation = f(S,E,C) where S = coherent Story; E = credible Evidence; C = Creatively told.

6. "And one more thing." Steve Jobs is well-known for delivering one final surprise at the end of his presentation. Is there one last blinding insight that you'd want your audience to walk away with?

7. A new format. Consider stepping out of the traditional slide presentation format. Maybe you can convey your results with a science-fair type poster or with a web page or in a short book (check out self-publishing with Lulu). How about with charades or a Broadway tune? Too much?

8. Give them a souvenir. Provide your audience with something to take away that summarizes your key messages. For example, you might hand out a laminated one-pager with your most important framework and results. A colorful summary that begs to be thumbtacked to an office wall is better than a 40-page black-and-white deck that begs to be thrown out.

Bonus post: 4 Ideas from Microsoft for Presentations with More Zing (But Are More Distracting Than Useful)

1. Animation. Animation can be useful (e.g. "building" the content of a complex slide) but is overrated for livening up a presentation. The first slide animation is novel; the second is overdone.

2. Fancy template. Microsoft has been kind enough to provide a variety of dazzling slide templates—almost all of which distract from the content.

3. Clipart. A while back, we railed against Screenbeans, the little ant-like people that visually depict activities or moods. Those little buggers continue to be a bad idea.

4. Fonts. Especially Comic Sans. Won't you join the Ban Comic Sans movement with me?