Gadzooks, we've been busier than ever here at Fog Creek World HQ. For some reason I thought it would be a good idea to sell Mike Gunderloy's (excellent) FogBugz book alongside FogBugz itself, but since we've never shipped any physical products before, that meant a whole lot of new code in the online store for package tracking, shipping addresses, choose a shipping method, inventory stuff, etc. etc., and I'm now spending too much time trying to figure out shipping and debugging the packing slip code... the joke is on us, because the reason we wrote our own store code in the first place was because all of the off-the-shelf ecommerce packages were too focused on physical delivery and didn't have any kind of mechanism for selling downloads and licenses.
It's ok. I complain a lot but what I love about a software startup is that when you're bored writing code, you can fool around with stuff like the USPS web site and ordering padded envelopes.
Watch this site for a new five-part series on the process of creating FogBugz 4.0, coming soon!
On the right, the result of yesterday's snowstorm as seen from my living room.
But first: if you're going the O'Reilly Emerging Technology Conference in San Diego, I'll be there on March 16th giving a speech. Now, the official topic of the speech is something about building communities with software, which is a good topic, but it's not going to be the actual topic of the speech. I am gaining something of a reputation for giving speeches which are not precisely on topic. Oh well. The actual topic of the speech is too hard to pin down. We'll look at pictures, I'll tell some jokes, and if the A/V works right there will be music too.
Next, if Southwest Airlines manages to actually deliver me on time, on March 17th I'll be in Silicon Valley at Software Development West where Software Development Editor in Chief Alexandra Weber Morales will interview me in a "fireside chat" format. I don't know if they are actually going to have a fireplace; we might have to burn twigs and promotional literature on stage. If you want to attend the fireside chat all you have to do is register for an "Expo Pass" which is free online until 3/10; onsite or after 3/10 it's $50.
And last but not least, Apress will host a pizza and beer reception on March 18th from 6:00 to 7:30 pm in Berkeley, at the Studio Rasa Gallery, 933 Parker Street.
I was quoted in an eWeek story about the VB6 petition today: “And this is how Microsoft will lose their desktop monopoly: because some bright bulb at Microsoft thought Boolean operations should really short-circuit, no matter what millions of BASIC developers had been doing since the 1960s.”
Correction! This is a bad example, since the boolean operators I was thinking of (And and Or) were not changed to short circuit in VB.Net. I have no idea why I've been thinking that they were for so long. There are other, real examples of incompatibilities between VB and VB.NET, but short circuiting was not one of them.
Apparently, the reason I was misinformed about And and Or shortcircuiting is that it was changed during the beta after a lot of people screamed.
A better example would have been the elimination of Set and default properties.
Understand, please, that it's not that people mind the changes.
Change is good.
Nobody thinks the Set statement was a good thing.
I once spent a whole day in Mark Igra's office (in 1992 Mark was the program manager for Object Basic which became VBA) begging him to get rid of default properties and the Set statement, kicking and screaming and using every rhetorical device at my disposal, but the Basic team absolutely refused to do anything that would break working code, and in those days, there was a tiny amount of working code from Access 1.0 that already used default properties and the Set statement, and it could not be broken. Mark was right and I was wrong and Set remained. By the way, I'm pretty sure default properties were Adam Bosworth's fault; I'll have to ask him this week at the O'Reilly conference. Adam was the designer of Access 1.0. They wanted to be able to say recordset("fieldname") to get the value out of a column, not recordset("fieldname").value.
But here's the thing. If you have a million line code base that's mission critical, as many companies do, and VB suddenly changes, as it did, you have a choice: keep using VB 6 or spend a lot of time (=money) upgrading to VB.NET. If you keep using VB 6, eventually new things will come out that will not be supported from VB 6, and you'll be stuck using the yucky old VB 6 IDE until the end of time. Already most of the big component vendors are doing all the new components as .NET components, not OCXes.
If you spend the money to upgrade to VB.NET, well, you just spent a lot of money to stand still. And companies don't like to spend a lot of money to stand still, so while you're spending the money, it probably makes sense to consider the alternatives that you can port to that won't put you at the mercy of a single vendor and won't be as likely to change arbitrarily in the future. So as soon as people with large code bases start hearing that they're going to have to work to port their apps from VB to VB.NET with WinForms, and then they start hearing that WinForms isn't really the future, the future is really this Avalon thing nobody has yet, they start wondering whether it isn't time to find another development platform.
I'm heading off to California now. Remember, pizza and beer reception on March 18th from 6:00 to 7:30 pm in Berkeley, at the Studio Rasa Gallery, 933 Parker Street.
First of all, congratulations to the whole FogBugz team on winning the Jolt Award in the category of Defect Tracking Tools for FogBugz 3.1.
Also I'm honored that my book Joel on Software won the Productivity Award.
A few people who heard my talk at O'Reilly Etech wrote reviews:
If you're in the bay area don't miss the pizza/beer reception tonight at Apress 6:00 to 7:30 pm in Berkeley, at Apress, 2560 Ninth St., Ste. 219.
Until now we've been hiring rarely and quietly, but lately our sales are so strong we can't quite keep up.
My old theory of hiring was to post a job listing on Monster or Craigslist and then sort through the massive pile of unqualified applicants in hopes of finding the needle in the haystack.
That hasn't worked so well. In the future I'm going to try putting up semi-permanent job listings for all the kinds of people we might hire on the Fog Creek website and see if that gets us a slower trickle of more qualified job applicants.
We are looking for a talented filmmaker, student or experienced, to make a documentary about the software development process this summer. If you think you're interested, read on for more details!
This week, I'm going to be running a five-part behind-the-scenes look at the development of FogBugz 4.0. Each morning I'll post a new installment.
Today, in The Road To FogBugz 4.0 Part I, I'll talk about a couple of major features we added after listening to customer feedback, and why our mantra is to listen to our customers and ignore our competitors.
We use FogBugz extensively internally to handle company email, and the process of using FogBugz ourselves ("eating our own dogfood") motivated us to add Bayesian spam filtering, and a "snippets" feature to make it easy to enter common phrases and even entire messages in replies to frequently-asked questions.
In today's installment of The Road to FogBugz 4.0, a look at two new features that came out of dogfooding.
To make FogBugz work on Unix as well as Windows, we needed a PHP version. Rather than do a one-time port, we built a compiler that automatically generates a PHP version from the ASP source code. Read all about it in today's part III of The Road to FogBugz 4.0.
Part Four: Out of every 100 calories expended by the Fog Creek team, just 2 calories are spent on actually writing new lines of code that ship to a customer.
1111 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.