[A picture of private offices at Fog Creek Software] Alert! This ancient trifle retrieved from the Joel on Software archive is well-past its expiration date. Proceed with care.

Joel on Software

Ask Joel

by Joel Spolsky
Wednesday, August 22, 2001

... in which I respond to some interesting email I've gotten lately. All the incoming email has been edited for brevity.

Charles Lin writes:

I teach a C++ computer science course here at University of Maryland at College Park....

Presume you are the czar of University of Maryland Computer Science (you've just dreamed about this, haven't you?), and say "things need to be changed -- we need to teach computer science the right way", what would you do? What do you think are the important things students need to learn if they are to become good C++ programmers.

Off of the top of my head, some of these topics are:

  1. the relational model and modern DBMSs
  2. user interface design and usability
  3. techniques for coding on large teams
  4. software design and writing functional specifications
  5. debugging
  6. Windows and COM programming
  7. sockets programming and common Internet protocols
  8. database-backed web site development
  9. writing! Because great programmers are great communicators.

Dan Green writes:

I read sometime back that you were going shared sourced (for want of a better term) with FogBUGZ. I'm going to be wanting to do similar on a product of mine but I'm not sure how best to word the license. Would you mind sharing the FogBugz license, so that I can learn from it?

Sure. It's here. I suggest you get a lawyer, though, to review your license. (If you have Errors and Omissions insurance, whatever the heck that is, you are probably required to do so).

Paul Wolpe writes:

I graduated from Carnegie Mellon in May and was happily planning on working for Loudcloud in New York City this fall. It seemed like the best of both worlds; I could work for a tech company and I wouldn't need to live in the suburbs. Well, due to "unfavorable market conditions" I am now without a job and faced with what appears to be two options: go work for Microsoft in Redmond or work for some financial company in New York City. I have to choose between a great job in a not so great location or a great location with a not so great job. I am not asking for a job (but I would gladly accept if you are offering!). I want to find out if there are any interesting tech companies in New York (and even better if they are hiring). So far, I have found a total of maybe 3 companies, and that includes Fog Creek.

Oooo. Uh-oh. I have two pieces of bad news for ya. No, wait, three pieces. Number one: there aren't that many technology companies where you can do R&D in New York City. Every local programmer I know complains all the time about how hard it is to get interesting software jobs that aren't at a bank. That's one of the reasons I created Fog Creek. Which brings us to bad news number two: Fog Creek is not hiring, because we can't afford to right now, which is caused by the dot-com crash, which is bad news number three: there's a bit of a recession going on right now, especially in the tech sector... which means that almost nobody is hiring.

But there is good news, which is that every programmer I know has some job. Maybe it's not their dream job, but it pays the rent.

The good thing about working for Microsoft is that Microsoft is one company that really knows how to make software, and you'll learn a lot that will help you wherever you go. And the good thing about living in New York City is, well, OK, I don't have to explain that. I think in your place I would come to the city and spend some time hopping around, waiting for something interesting to show up. (Pay your dues at the banks and media companies like the rest of us!) Oh, and email me your resume anyway, you never know what might come up.

Gabriel Krupa writes:

I have been a fan of yours for a while and would very much like to start my own company, modeled after Fog Creek (on the other side of the country). Given the business climate lately, I'm hesitant to leave "subsistence programming" (and give it a go with my own savings) until I plan, scheme and "strategize" myself into a false sense of security. I understand the importance of leveraging work to generate money, lest I spend the rest of my life running a consulting firm. Unfortunately, it's not easy to pay someone else's salary from my margins unless they're generating part of that revenue for the company-- at least with my hourly rate. Thus, I'm still a company of one with less time than I'd like to devote to building the company.

This is where I get to the point. I've read your admissions of how much it takes to run Fog Creek on a monthly basis and that you're making most of that through consulting. I'd like to find out about Fog Creek's shrink-wrap strategy and results to date. If you'd rather not share this information, I understand.

For instance, I'd like to know:

  • how much revenue you generate from FogBugz and expect from CityDesk

    FogBUGZ is not yet at the point where it's paying anybody's salary, but it does cover virtually all of our non-salary expenses (rent, T1, etc) and then some. Which is nice. Yesterday we sold $5700 worth in one day. Whoo hoo! Your mileage may vary.

    We expect CityDesk to have a much wider potential audience than FogBUGZ, so we're hoping that once CityDesk hits its stride we won't need any consulting revenue to support ourselves.

  • what sort of growth you've seen and expect(ed) in sales

    It's probably too early to see a pattern, but there has been slow but steady growth as the word spreads. We are not doing any active marketing on FogBUGZ at this point, mainly because we want to conserve any marketing dollars we have for CityDesk.

    Even without funding, we hope to be able to get to the point where we can demonstrate that (a) we're profitable and secure and (b) x dollars spent on marketing results in x times y dollars in revenue. At this point, if y > 1, we can make a strong argument to raise money for marketing without giving up very much equity... or we can go slowly and simply reinvest internally.

  • how you choose your product lines (e.g., why you chose to make FogBugz and CityDesk instead of other products (user demand and market conditions being roughly equal))

    FogBUGZ was something we had, so it was a no-brainer to ship it: both to get some cash and to get some practice selling software. (And to get the people off our backs who kept asking us if they could buy it.) It has more than paid for its own R&D costs, so now it feels like one of those mystical things you hear about on late-night TV that you set up and get a nice check every month in exchange for doing nothing. (We do still plan several more major releases of FogBUGZ so it's not exactly nothing but you get the idea).

    CityDesk will fill a very major vacuum in the desktop software marketplace, it's a great product, and everybody who's seen it has said "I gotta get me one of those." So we're working day and night trying to get the beta out the door.

  • if you feel your reputation and product quality are enough to gain market share in non-virgin markets (i.e., defect tracking) or what Fog Creek's strategy is

    There are about 1000 bug tracking packages on the market (from companies who are probably selling it for the same reason as we are -- because they have it.) So we didn't know if we would sell any copies of FogBUGZ. As it turns out, the FogBUGZ philosophy of painless bug tracking has hit a nerve and the product has exceeded our expectations and then some. People are also happy because we're a small company that provides fanatical customer service... when you find a bug and call our toll-free number, you'll speak to a programmer and probably get a bug fix shipped to you that day.

  • whether or not you're presently concentrating on non-consulting revenue

    We're trying to avoid taking new clients for a while, since we don't actually need the money and would rather have CityDesk done right now. But this is something we reevaluate constantly.

Ted Graham Writes:

Since you are an ex-microsoftie, I have a question for you: does Microsoft use VSS for their projects? I can't see how they would, it doesn't seem to have the features needed to support multiple versions. I'm a consultant on a fairly large VC++ project on Win2K and we are about to make our first shipment to the end users. I've been looking for a way to do branching like I'm used to in PVCS, but not finding anything. It seems like it has labels available, but we can't branch an individual file off and label the branch. Any ideas?

I can't really speak for what Microsoft uses; I haven't been there in years and SourceSafe didn't exist when I was there. But I have heard only bad things about it. What I've heard from other programmers is that it's not so strong in the data reliability department. Oops.

Do yourself a favor - use CVS like everyone else; it's simple, reliable, ubiquitous, and rock-solid.


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Trello and Fog Creek Software, and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky