My latest article, “Building Communities with Software,” was sent to email subscribers earlier today.
If you did not get it and expected to get it, you're probably having problems with overenthusiastic spam filters. I got lots of bounces, mostly from Fortune 500 type companies, rejecting the message, because of "inappropriate content" or because their automatic filters had decided it was spam. Some of them complained about "taboo," other's complained about "hard core." Most didn't tell me. Such is the state of email today.
If you did not get the article and you want it, you can read a shorter, sanitized version online. But it still contains the word "taboo" so if that offends you you may want to avert your eyes!
I just got back from inspecting the new Fog Creek Office, a sunny loft in the shmatta district, with the architect. It's going to make a really nice office when we're finished building it out, with private offices, a living room area, kitchenette, and, budget permitting, a pool table and plasma TV. Here's what I told the architect:
AngryCoder: “FogBUGZ is very well designed, and virtually bug free. Frankly, if you are in the market for a defect tracking solution, you can’t do much better than FogBUGZ. It is by far the best solution on the market right now, and is also very attractively priced.” Thanks!
Joseph Jones, who wrote the review, didn’t like the perceived lack of customizability in FogBUGZ. I hear ya. This was one of those agonizing decisions for us. It’s a tradeoff between implementing features that make the sale, versus implementing features that, we think, will make people who use our software love it, which helps in the long term. At the time it was discussed in depth here on Joel on Software.
Take, for example, a typical report a bug tracking package gives you that shows you the number of bugs generated per day per programmer. Typical bad managers will use that tool to punish programmers with high bug counts or reward programmers with low bug counts. As a result, every time a tester tries to enter a bug, the programmer will argue about it. “That's not really a bug.” “Please don't enter it, I'll fix it on the side for you.” Eventually the bug tracking system subverts itself. That's not FogBUGZ's fault, but there you have it. Nobody wants to use it, they never upgrade, they don't buy more licenses when they get more programmers, and we lose the potential word of mouth.
The current system, in which we expect FogBUGZ users to have enlightened development processes, makes us miss out on initial sales but it makes our existing customers happier. And they tell friends, and they buy more and more licences, and all is good. We've found that anyone who has been using FogBUGZ and moves on to a new job that doesn't have bug tracking will recommend FogBUGZ at their new job, which is one reason our sales are up by about 200% since last year.
But this is all, to some extent, speculation. I can't prove anything here. Design decisions are hard that way.
A couple of the monthly columns I’ve been doing for the Programmer’s Paradise catalog are now on the web: a review of VMWare and a column on data modeling with ERwin. Coming up: a five minute introduction to user interface design, and a look at my experience using the profiler in CompuWare's DevPartner Studio to speed up CityDesk.
750 words doesn't give me much of a chance to really review things in depth, but I do have a policy for writing reviews: I only review products that I actually want to use in my daily work at Fog Creek. Unlike trade magazine reviewers, I still spend about 50% of my time doing software development, and I’m happy to try the latest toys if I think they will help. For example, this week I’m going to try to implement a basic image editor into CityDesk using LeadTools.
In other news, we have signed the lease for our new office space, and the architect came up with a groovy floorplan with parallelogram offices.
Not bad: about four hours of work to implement a picture editor with crop, resize, rotate, undo, and save.
It did take about four hours yesterday to figure out which OCX/DLL files I need to ship and make sure that SETUP included them, and I spent an hour last night reading the documentation to get a better idea for what I have to do.
Basically, we're moving because of William Whyte's rule: virtually all corporate relocations involve a move to a location which is closer to the CEO's home than the old location. Whyte discovered this principle after an extensive study of Fortune 500 companies that left New York City for the suburbs in the 1950s and 1960s. They always had big, complicated Relocation Committees which carefully studied all the options and chose, coincidentally I'm sure, to move to within half a mile of the CEO's home in Danbury, Connecticut. Whyte also showed that these companies all tanked after the relocation.
This may be, possibly, the most off-topic article I've ever done here. But I try to write only about things I know about, and, recently, I learned a lot more about commercial real estate than I ever imagined I would need to know...
Oh, good, TechInterview is back!
1110 posts over 13 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.