The FogBugz Salesman

{

Once or twice people have confused what I'm doing with sales. Some time back I met with a prospective client and kept having to explain that I actually do write code and would probably be a lead developer on any work they gave us. The reaction I had for even the mere perception that I was "sales" was a little surprising to myself although with some reflection I realized it was because I conflated most of what I disliked about salesmen into an image I couldn't deal with for myself:

• Style over substance
• Shallow understanding
• Pandering for a quick buck

But once in my life I was a happy salesman. Some time back I pushed the company I worked for into adopting FogBugz and really building a large part of our lifecycle around it. I did so enthusiastically after reading Joel's early essays on bug tracking and seeing how well it applied to our situation.

I've seen other bug tracking software since but still think the FogBugz experience was best.  It seems simple, but because of how much thought has gone into the product, I gather a lot of work has gone into keeping it stripped from unnecessary features.

To be clear, I don't work as a bona fide "in house" developer. But as a consulting company, I spend a lot of time playing that role or working with people in it.  It's therefore conflicting when I read his understanding of what it means to work in house. Phil Haack had it right in the middle of 2005 when he wrote of the irony of this disdain towards the people that would be excited to use his software in the first place.

I wonder what kind of conditioning it is - maybe that I've liked musical artists who are fairly open about loathing their fanbase - but I still miss the simplicity and elegance of FogBugz. 

What's sad these days is that as much as I'd like to slip on the poorly fitting suit and do my sales routine, we get Sharepoint for free (okay, not free but let's just say Microsoft does an excellent job making it seem so) and it's the environment in which we track what I'd gotten my previous company to use FogBugz for so effectively.  I'm not a big Sharepoint fan (that's an understatement) so I'd even be tempted to go The Powers That Be and ask for FogBugz if I couldn't predict the answer right away.

Tomorrow I'll be unflustered but I've got a few comments on what it's like to be in house:

1. In a small enough company, it's great to have decision making power.  I've used technologies like Ajax and Perl where a larger environment would have involved committee meetings with some manager shooting me down for doing things differently. You don't have to be a renegade to do this, just document what you do well and communicate with anyone you're working with that may have to look at it on your behalf.

2. In consulting it helps a lot to condition your client.  First build confidence with a track record of success, after which the client is usually willing to listen to you when you'd like to do things "right" or improve a piece of software even if it's getting by functionally.  After a while, depending on the client, they will usually just trust your judgement and stay away from technical arguments unless there's some disproportionate cost.

3. Software is never finished.  This is true even for what is developed in house.  As a result the process of continual improvement still exists.  It takes a tremendous amount of discipline to try to develop things right when there's a small budget or a tight deadline but I always think of those moments I've spent late at night hacking the ugliest workarounds because of a bad initial effort. Most of the time finishing when it's "good enough" is about the taste and craftsmanship of the person who writes the software; whether they tried to think of the future or not.

4. From working in both a "software company" and a "consulting company" I understand that software development is always a process of coming to terms with friction - all the unexpected realities and circumstances of real life and real users. Different places will have different kinds of friction; where an in house developer may have to deal with the kind of discipline it takes to write unit tests on a deadline a programmer at a software company may have the dilemma of trying to be all things to all people.

}