Mencius Moldbug: “They create an incomplete model of the giant electronic brain in their own, non-giant, non-electronic brains. Of course, since the giant electronic brain is a million lines of code which is constantly changing, this is a painful, inadequate and error-prone task.”
A year ago today, FogBugz development was in disarray.
We had done this big offsite at a beach house in the Hamptons and came up with a complicated roadmap that involved splitting FogBugz into two separate products and two separate teams. We had done a lot of work on the architecture that made the product much more modular, but we had this goofy plan to do a major release containing virtually no new features, just to let the new architecture shake out, a plan which nobody was very excited about.
So, on July 31, 2008, we reset our plans. We gave up on the idea of shipping a standalone Wiki product, and merged the Wiki team with the FogBugz team. And we nailed down a new vision for FogBugz 7 that’s a lot easier to understand and a much better product: something we could ship in one year.
Then the development team shipped it. Exactly on schedule. Well, maybe a week or two early. They used Evidence Based Scheduling religiously on this large one year project and it worked amazingly well. Yes, they had to cut and trim features as they went along, but the accuracy of the estimates also gave them the confidence to add a couple of major features (like Scrum support) that you’ll love.
One of the best things we did as a development team was to write a short, concise, comprehensible vision statement that got everybody exactly on the same page about what we were going to do over the course of a year. The vision statement made it easy to prioritize. Instead of just telling us what was in the product, it also gave us a way to know what was out.
Here’s the vision statement, in its entirety, which is a pretty good description of what we are actually shipping today. Please excuse the tone of voice; remember that this was an internal document to galvanize the team.
As of August, 2008, the entire FogBugz and Weeble teams are working towards a single major new release of FogBugz that will blow away our customers (real and imaginary). When they see it they will grow weak in the knees. Competitors will shiver in fear at the monumental amount of win in this release. As customers evaluate the software, they will simply never find a reason not to use FogBugz to run their software teams. No matter what the grumpy people on their team come up with, they'll find that not only have we implemented it in FogBugz, we've done it in a FULL-ASSED way. No more HALF-ASSED features (I'm looking at you, logo customization in FogBugz 6.1).
This release has three important focus areas with friendly catchnames.
If it's NOT ON THAT LIST it's NOT IN THE PRODUCT. Get used to it.
FogBugz 7.0 will include a long list of simple improvements that will make life dramatically easier for people trying to get things done, especially when they want to do things just a wee bit differently than we do here in the Land of the Fog. Every little feature will be a delight for somebody, especially that person who keeps emailing us because he can't believe that the feature he wants which is obviously only six lines of code hasn't been implemented in FogBugz 1.0, 2.0, 3.0, 4.0, "4.5", or 6.0, and if we don't get it soon he JUST MIGHT HAVE TO GO OVER TO THE AUSTRALIANS.
Collectively, though, fruity treats will make FogBugz friggin' amazing, and they'll help us win more sales because we won't have so many showstopper reasons why people choose another so-called bug "tracker."
What's a fruity treat? It must fit these three rules to get into the 7.0 orchard:
Visit the shared filter FogBugz 7 Fruity Treats to see what's coming up.
FogBugz 7.0 will include our smashingly powerful new plug-in archicture, which, combined with the FogBugz API, will give people complete confidence that if there's anything FogBugz can't do out of the FogBox, you can write it yourself. No more will we tell customers "you get the source code, so you can modify it!" That's BS. They know perfectly well that if they modify our source code, terribobble tragedies will occur the minute we release a service pack. From now on, we can say, "there's a great plug in architecture and a whole online cornucopia of righteous plug-ins available for download."
So you can trick out your FogBugz installation like a lowrider or an off-road dune buggy. You can make it into a Cadillac or a space shuttle. It's up to you.
Thanks to the newfangled, all-electronic compilation machine ("Wasabi") that we had installed at great expense, FogBugz will be running on the CLR and Mono for greatly improved performance and compatibility. Whiz zip blip! bleep! You'll be able to run 1000s of users on one server. Long queries will finish faster. Laundry will be brighter.
Nothing else. Go fix yourself an icy lemonade.
The team got pretty excited. Having a sharp focused vision statement like that, and having the whole team working towards a single shared goal, really helped us get our house in order. We scrubbed through thousands of backlogged ideas, feature requests, and comments, and came up with a set of fruity treats that will eliminate virtually every customer objection that we hear during the sales process. We developed a comprehensive plug-in architecture that’s pretty amazing, and had interns develop a slew of slick plug-ins. And the fact that Wasabi is now a genuine .NET language made for substantial performance improvements over running on the VBScript “runtime.”
I’ll let the team give you a comprehensive look at what’s new in FogBugz 7, but here are some of the highlights:
Those are just the big-ticket items. FogBugz 7 is rife with little areas where the development team put a ridiculous amount of attention to detail. For example, the signup process, which is actually very complicated on the backend, became much simpler on the front end, due to a heroic amount of work that every user will only see once. If you do nothing else, check out the signup process to see the effort that went into making signup just a tiny bit faster. Another example: we completely replaced the entire email processing infrastructure, just because there were tiny corner case bugs that simply could not be solved with the commercial class library we had been using.
I wish I could take more credit for it, but the truth is, Fog Creek has grown. We have a very professional team with testers, program managers, and developers, and I just sort of sit here agog at what a brilliant job they’re doing. All of the credit for this fantastic new product goes to them. I’m just the Michael Scott character who wastes everybody’s time whenever I venture out of my office.
FogBugz 7 is shipping today for Windows servers and on our own, hosted infrastructure. The Mono version (for Macintosh and Linux) will be in beta soon. To try it, go to try.fogbugz.com.
If you’re currently using FogBugz on Demand, you’re already using 7.0.
Brett Kiefer describes Evidence Based Scheduling 2.0 on the FogBugz Blog: “EBS 2.0 gives you the vocabulary of strict dependencies and start dates. You can now say ‘No one can travel back in time until the Flux Capacitor is complete and the duped terror cell steals the plutonium.’”
“Every single industry was going to be turned upside down! New industries would be created! Start-ups would make people rich! Which is really nice, because it's awesome to be rich! And, bonus: It'll never be winter again!”
In this month’s Inc. column, The Day My Industry Died, I retell the first part of the Fog Creek story.
If you’ve ever heard Seth speak, you’ve had your mind blown. Which is why, on the rare occasion, when he runs a one-day seminar, he charges $1650 to attend, and it sells out in seconds.
1112 posts over 14 years. Everything I’ve ever published is right here.
There’s a software company in New York City dedicated to doing things the right way and proving that it can be done profitably and successfully.