FAW #25: Joel Spolsky of Fog Creek Software
Fog Creek’s precipitious beginnings
Inspired by ArsDigita, Joel Spolsky founded Fog Creek Software with a friend in 2000 seeking to create a company that shared the same values of ArsDigita in being programmer-centric and a place where they themselves would want to work. They had zero idea of what they were going to provide; they started on a hypothesis that, “if those less-qualified jokesters can get $100MM valuations, we can surely be at least as successful.” Spolsky had spent the summer writing articles on his personal site and had established a popular software development blog called Joel on Software that commanded a significant readership. This generated the companies first consulting gigs. Unfortunately their timing was inopportune- they founded the company in September of 2000 on the cusp of the dotcom implosion. By November of 2000 their client consulting business had evaporated.
Spolsky explains why the industry-wide collapse of the consulting market was so immediate: “The consulting market is the derivative of every other market. When a company is growing, they will hire a few consultants to help them grow a little bit more rapidly. When they’re shrinking, they’ll instantly fire all consultants. If the market is even going down by 0.002 percent instead of growing - which it did, because there was a sort of dot-com nuclear winter - then the first people to go will be the consultants. So the consulting business completely collapsed, and every company in that space more or less collapsed.” With zero clients to pay bills Fog Creek shifted its focus to productizing an internal bug tracking app they had created. They polished it up and posted it and sure enough people began buying it; Fog Bugz became their first product.
They shipped Fog Bugz and saw a small yet steadily-growing sales each month. Their original plan to was to build a consulting business like ArsDigita had and from it would emerge a software product company. What they found instead was that the consulting biz disappeared and they had to become strictly a product company. Fortunately they had not amassed a huge stable of consultants on salary like the other companies (ArsDigita, Scient, Razorfish, iXL, MarchFirst) so while the others were hemorrhaging money while they were realizing the consulting market was gone permanently, Fog Creek was sustainable under sales of their bug tracking product.
Like ArsDigita, their strategy was keenly focused on creating the optimal work environment for programmers so they could attract the best talent. They observed the cube farms and poor treatment of programmers in traditional consulting agencies and swore they would do things differently. Spolsky says, “Things that to us are basic: Aeron chairs; private offices with doors that close for every programmer; letting programmers report to other programmers so that your boss will understand you. We had 4 weeks of vacation and another week of holidays, which you can move I think. For the consulting business, we had a rule that you fly first class and that you never be away from home on a weekend.” These amenities helped them attract some bright minds early on and since smart people always want to work with other smart people, they established a virtuous cycle that delivered quality talent to fuel their growth.
Maturing through the sales gimmicks
The Fog Creek co-founders both had programming backgrounds and feared they didn’t have the business experience to actually sell their product. The sought to structure a reseller arrangement like Lotus had done with Iris where they would do a 50/50 revenue share with the company that distributed their software. This idea fell flat with no takers. They tried offering a finder’s fee on the site for people that brought in sales and that too flopped. They dabbled with creating an affiliate program to pay a percentage commission on sales generated through in-bound links from other sites and, after a negligible amount of sales generated from that program, they canceled it out of annoyance from sending $19 commission checks. They tried timed coupon giveaways that expired within 72hrs and this too produced only marginal results. Spolsky says, “The one thing we learned over five years is that nothing works better than just improving your product. Every minute, every developer hour we spent on any one of these crazy things - although they had some marginal return on the work that we put into them - was nothing compared to just making a better version of the product and releasing it. If we had taken all the effort we put into these crazy schemes and put it into moving our software development schedule ahead by the equivalent amount, it would have paid off much more.”
This is valuable advice for us at JumpBox as we face a similar situation in terms of our team composition: we all have programming backgrounds with minimal actual business experience in doing deals. This realization was one of the driving factors in why we shifted from our original vision of tackling the enterprise tool set for ISV’s to be able to produce appliances themselves. Given the novelty of the technology and the massive pain it solves, at a $50 average price point, the JumpBox apps in their current form should sell themselves and require no direct sales force. They should also require minimal marketing budget relative to an enterprise offering in that they are noteworthy and remarkable enough to the folks with the current pains that they will likely talk about them as this guy did this morning. Rather than direct any energy at affiliate programs or other incentive gimmicks, we’re staying focused on rapid releases containing user-requested improvements and devoting our energy into improving the product itself and keeping a strong connection via our blog, support forums and usage surveys.
Where I disagree with Joel
Joel has a huge, loyal readership on his “Joel on Software” blog. I was fortunate to see him speak in Bethesda, MD at a CFUNITED conference in 2005. I respectfully disagree with a handful of core things he advocates, however.
All that being said, Joel is a smart guy and he’s clearly done a lot of things right. Those are just the four philosophical principles that I would argue they have completely backwards. Fog Creek continues as a privately-held profitable company selling their popular Fog Bugz and Co-Pilot software today.
May 28th, 2007 at 10:03 pm
I agree with most of your counter-points.
Do you (or one of your readers) know what the approximate revenues of Fog Creek are?
Would be interesting to know how big they have gotten and if the absence of any investment put some constraint on their growth.
May 28th, 2007 at 10:24 pm
I like Joel’s writing and respect his business, but I’ve always had similar reservations. I find his use of the “Joel Test” on the Joel on Software job board especially galling (you can only score a “perfect” 12/12 with a spec and “daily builds”, which means you (1) aren’t agile and (2) are probably using the wrong language). Thanks for having the guts to put your doubts in writing.
May 28th, 2007 at 11:58 pm
[…] Good article: Spolsky explains why the industry-wide collapse of the consulting market was so immediate: “The consulting market is the derivative of every other market. When a company is growing, they will hire a few consultants to help them grow a little bit more rapidly. When they’re shrinking, they’ll instantly fire all consultants. […]
May 29th, 2007 at 5:57 am
If you are not isolated from other team members how do you play games and surf for porn? And without that, how do you stay productive? HMmmmmmmmmmmm?
May 29th, 2007 at 6:37 am
Joel’s idea on offices is not as radical as you see it, programmers can still communicate, and if you take a look a his articles you see he suppors pair programming and having developers work together. Having 5 persons in the same table calls out for interruptions of every kind, from a person sneezing to someone asking you a eveyr kind of stuff instead while he could look it by himself.
Maybe I am too extreme about this, but it’s hard for me to program while someone is asking me stuff, I need to totally focus and move outside to another planet when I’m in front of my IDE.
On the Microsoft-centric side, yes, Joel might be a bit MS-sided, but remember Copilot has a Linux version and Copilot has a Mac OSX port too, so I don’t think it’s that bad either.
May 29th, 2007 at 8:57 am
100% agree. Although there is no way I can call myself a supporter of “Agile” development, his “big design comes first” approach is clearly weird.
As far as agile way of doing things, most of the time (IMO) eventually it leads to a giant pile of code spaghetti without any central “spine”. Which, I guess, is fine for consulting business that does not have to maintain systems they build.
Back to Joel. There are two other quite strange thing about him that got apparent in several of his posts:
- Premature Emphasis on performance
- He hates exceptions (in any language)
The wrong of 1st issue is obvious. Premature optimization is simply B-A-D. He dismisses Ruby as a good choice for production systems, claiming that even their bug tracker requires “faster language”. And his misunderstanding of exceptions I simply have no explanation for.
Well, enough bashing :-) After all, his blog is the only I have been *always* reading. Other bloggers come and go, Joel stays, even though he hasn’t written anything about software in a last half year or so.
May 29th, 2007 at 9:22 am
Unfortunately the benefits of programmer isolation vary by programmer. Some programmers, like myself, find it difficult to concentrate in loud, open areas. My performance suffers as a result. At my previous company we had private offices and I was considered one of the “star” programmers, now in “the big room” I’m just average (though I *do* know a lot more about my coworkers’ weekend plans, personal relationships, and medical problems.)
Many of my more effective coworkers have a kind of tunnel vision that makes it difficult to get their attention even when you wave your hand in front of their face. When I really need to concentrate, I have to work at home.
I feel my company is throwing away money on me, but they don’t seem to mind. I’d tell them this when I leave, except I don’t think it’d make a difference. They’ve already decided that the romper room way is the one, true way.
May 29th, 2007 at 10:37 am
I completely agree with Peter’s post. In my first 9 years as a professional programmer, I had my own private office and was considered a star(-ish) programmer. When my employer moved to a new building where the rank-and-file sat in cubicles, my productivity halved. I assume the savings provided by the new building made up for the loss in programmer productivity, or they would not have made this choice. The company continued to highly regard me as a programmer, likely because everyone else’s productivity also seemed more paltry.
Since then, I’ve worked in cubicles or romper rooms. My productivity has never quite recovered. I work from home when I need to solve a difficult problem, research, or design.
That being said, I like common areas where programmers can sit and work together. But I also need an area to which I can escape and have total silence and no interruptions.
As for BDUF, I think it depends on the kinds of projects you are working on. For a very UI-centric component (which includes most software these days), it makes more sense to design this iteratively. For some bits of software (like complex, multi-threaded internal operating systems components, or complex back-end components), BDUF can be critical. Even with BDUF, you need to assume that things will change.
May 29th, 2007 at 12:13 pm
These are some great points. While I’m generally a big fan of Spolsky, you’ve outlined the exact points where I tend to disagree with him.
Mod +1 Peter and Bruce’s comments though.
I’ll have to check out Agile Software Development by Alistair Cockburn to see what they say about programming environments and productivity.
Have you read Peopleware? They provide some pretty conclusive evidence about the effects of giving developers a distraction-free, noise-free environment for doing hardcore development work.
Getting together in common rooms, etc. for a few hours a day doesn’t sound like a bad idea either. But it usually drives me crazy to be stuffed into a room or cubicle farm for 8-10 hours a day; headphones only go so far, then again I have Spidey-sense hearing.
At startups, once you’ve proven your worth (after 2-3 months or so), it seems they are usually small & cool enough to have much more flexible work environments, schedules, etc.
At bigger companies, they almost always have the wrong reasons for stuffing people in a room / cube farm:
a) belief workers will “goof off” if not in some kind of environment where they can be “monitored” (if you fear this, your company is screwed anyway and should probably just clean house)
b) potentially false belief that it will aid in cost savings. Peopleware does a pretty good job crunching the numbers — if devs are 200% more productive in a quiet environment, are you really saving money stuffing em in a cube farm or big common room?
May 29th, 2007 at 6:20 pm
“People that use MS stuff tend to think that Microsoft = computers in the way that people that first used AOL to connect to the Internet thought that AOL = Internet.”
Typical Mac/Linux fan boy view of the world. The FACT to the matter is us MS developers just don’t give a damn about the tool that we use. Windows, Mac or Linux are tool. A mean to the end. We use it to make money or get the job done. who else beside Mac/Linux fanboys keep spewing these kind of FUDs. Hey, i got a dedicated FreeBSD server that i used to run share hosting and i also have a Windows2003 for sharepoint. why the hell do i care about Windows, Mac or Linux? Would i get a cut of MS’s cash if i act like Apple fan boy? Is Steve Job = Jesus or something?
May 29th, 2007 at 6:24 pm
I thought CityDesk was supposed to be their big commercial success.
May 29th, 2007 at 9:13 pm
Jack: Hi.
I’ve seen this argument before: “Windows is a tool. Linux is a tool. Mac is a tool. Use the right tool for the right job.”
I agree. I totally agree. And yet, I totally disagree.
To draw an analogy: “Chicago is a place. Tokyo is a place. San Francisco is a place. Denver is a place. All of these places are more-or-less equivalent, except for certain parameters.” And that’s true.
But it’s completely wrong.
I find that being in Denver or San Francisco or Tokyo excites my creativity. Being in Chicago does not.
Different places feel different. They make you feel different. Downtown Chicago *feels* like stuffy corporate types in business suits. But I find that San Francisco or Tokyo or Denver *feel* inspiring. Places for new ideas. New York City *feels* like the melting pot of America. To me, NYC *feels* like this concept called America (as in, the US of A).
There’s a million little details that make a person like or dislike a place.
For me, a huge factor is something that may seem rather trivial: Chicago is built on a grid. All the roads are at right angles to each other. I can’t stand this. Really: I truly don’t want to live in Chicago simply because all the roads are at right angles to each other.
Contrast this with Denver or San Francisco: both of those cities have collisions between a N-S/E-W system of roads and a NE-SW/NW-NE system of roads. San Francisco has multiple such collisions. (Tokyo seems as though someone threw some spaghetti on the ground and said, “that’s the map”.)
This may seem like such a trivial thing, but I have no real desire to live in Chicago for this reason. I like to explore strange, new places, but every intersection in Chicago feels identical to the last.
By analogy, I think that there are a million little “peronality” reasons why people love Linux or Mac or Ruby or Python or whatever. I don’t live my life to be just a cog in the economic machine. I love technology and I want it to mean something to me. So the tools I use reflect upon my personality.
Good luck getting the next Google to start up in Chicago using C++ code running on Windows servers: Ain’t gonna happen.
May 29th, 2007 at 9:27 pm
@Mark
you seem to forgot a little Web 2.0 company called 37singals in Chicago. you know that little small creative team spawn Basecamp and other little web tools using RoR and as the matter of fact. The creator of RoR is on that team!
again, it shouldn’t matter where you are or what tool you use. if the tool that you use limited your creativity then simply use another tool. BTW, Microsoft does have some goods like .Net, Xbox360, Silverlight look promising, Office2007’s ribbon GUI and dare i say Windows. yes, Windows. It work fine for me since Win2000 and i have Vista Business on my desktop and laptop and Vista work just fine. Vista did what it suppose to do. i fail to see why i should care about tool.
i don’t get all these Mac/Linux fan boys worship their tools like the second coming of Jesus. Maybe Steve Job is the savior of the world or whatever.
May 30th, 2007 at 1:46 am
Let each programmer be given the flexibility to work as he or she deems fit. Interfere only when things get a bit out of hand or when the dates start slipping.
May 30th, 2007 at 4:31 am
I am all for private offices. There’s always the conflict - not all programmers are created equal.
Joel’s writings do make a lot of sense to me. Even though I dont agree 100% with him, the issues he comes up with are worthy of discussion - especially about the software startup ecosystem, and baiting his former employer M$.
On programming I think his record is a bit mixed.
Software is a field that does not impose physical limits on imagination, ideas and implementations of our concepts. In other words, dare to think different, or dare to stretch the envelope. Yet most companies/office-environments spend most of their time crimping this ability.
May 30th, 2007 at 10:19 am
Agile programming is for those who don’t know how to conduct analysis and design (99% of all developers). The specs didn’t change because the users were “fickle”; they “changed” because you never pinned them down in the first place.
June 1st, 2007 at 12:20 am
Shanti, +1 for Peopleware. For me at least, the advice to avoid music when working on hard problems is sound. I do think the music lulls part of my brain.