Oct 31 2007

Great Developers, Projects That Sound Boring

Published by at 7:51 am under Business   

I’ve been a fan of Joel Spolsky for years, though I haven’t agreed with everything he’s written, and even mocked him a bit. Joel has written at length on his web site and in print about attracting the best developers, and one aspect of that has bothered me:

How do you attract top developers to work on something that sounds rather dull, like a bug tracking application? It mostly shuffles data back and forth between screens and reports and database tables – far too boring for top developers.

Of course that’s an exaggeration, but a relevant one: at Oasis Digital much of our work is on enterprise business process automation, database-centric applications, and could likewise be described casually (though not accurately) as “just” shuffling data between screens and tables. I worry that our work will not sound interesting to prospective hires.

This week at the Business of Software conference I got a chance to ask (confront?) Joel about this. He offered a great, four-part answer, which I present here with my own additions mixed in. I don’t have careful notes about which bits came from Joel, so you are welcome to give him all the credit and me all the blame.

1) There is Interesting Technology Inside

Even in an application which, at first glance, just shuffles data around, there can turn out to be a lot of very interesting work inside. This is true of FogBugz and it is true of our work at Oasis Digital as well. Here are some examples of interesting work here, all of it inside dull-sounding applications:

  • Process metadata and generate code and GUI elements. Top developers certainly are those who solve a family of problems with generic code and metadata, rather than tediously one at a time.
  • Process large hierarchies efficiently using Celko’s nested sets representation technique. Top developers are all about using better data structures.
  • Custom GUI components to provide a drag-drop, direct manipulation approach to visualize and modifying data. The results has both a high “wow” factor, and is genuinely useful – a willing combination for top developers.
  • Integrate a Prolog-based rules mechanism to provide a vital algorithm in one page of code, that would have required countless pages of code and hundreds-to-thousands of hours of work to do otherwise. Using a radically different language to solve a problem with a small fraction of the effort… exactly the sort of thing a top developer wants to do.
  • Generic data replication mechanism: building our own was certainly more interesting work than adoptions one off the shelf.
  • Learn how OLAP works, implement an OLAP ETL process.
  • … I could list many more examples

2) One Level Down the Stack

Fog Creek aims to make compellingly good software because that is how you outcompete established competitors in a commercial shrinkwrap market. Oasis Digital likewise has this aim for a different reason: it is our intended niche. We aim to differentiate ourselves from “yet another outsourced dev company” by building unexpectedly good software. We don’t want customers who will be happy with the results available from the typical development firm; we want customers who are playing to win.

To meet either goal, it is sometimes necessary to work at one level of abstraction lower than would otherwise be necessarily. Joel’s examples were their own data grid and their own AJAX library. Some of our examples are listed above.

This kind of work, further in to the details, is generally more compelling to top developers.

Caveat: Don’t do this very often. If you want to ship software anytime soon, you need to mostly use off the shelf libraries that already work. Don’t build a data-grid, for example, unless you really need something that you can’t find in any off the shelf products. We don’t have our own data-grid; we use (among other things) the excellent grid products from Developer Express.

3) Problem Domain is less important than other factors

Joel has observed that developers aren’t as picky about the problem domain of their project as one might think; rather, other factors are more important: great co-workers, nice working environment, working for a boss who is a developers, etc. Top developers want to work on a high quality end product worthy of taking pride in.

4) All Projects need a lot of Grunt Work

To build a high quality product, in any problem domain, will require spending a great amount of your time on grunt work: tracking down bugs and fixing them, filling in feature “holes”, cleaning up design problems, improving GUI layouts, and the like. This is true for any problem domain. Top developers know this, and just get on with doing that work when needed.

Conclusion

My worry was unjustified. Our work at Oasis Digital is interesting and worthwhile, both for our customers and for our developers. To grow our team, we must focus on making it an increasingly good place to work.

A final anecdote: Joel mentioned that FogBugz 6 was feature-complete in the summer of 2006 – that means they spent around a year polishing it, fixing bugs, filling in holes, etc. That shows a phenomenal amount of dedication and discipline to create quality software.

If you found this post useful, please link to it from your web site, mention it online, or mention it to a colleague.

3 responses so far

3 Responses to “Great Developers, Projects That Sound Boring”

  1. Tim Skanner says:

    By themselves, Joel’s products are pretty uninteresting. They’re not extraordinary in any way and honestly, as far as product ideas go – they’re rather dumb. They compete with many very good, very established free software suites.

    The only reason Joel’s company exists at all is the sales driven off people that read his blog. Thats fine and all, but it really should be acknowledged for what it is. Just like Guy Kawasaki’s Truemors site, it only exists because Guy himself pushes it – Guy’s popularity is the key ingredient – Not because its an extraordinary or compelling site on its own (and I think Guy acknowledges that fact far more than Joel who seems to think his software packages are at all uncommon).

  2. Kyle Cordes says:

    FogBugz indeed competes with many other projects – there are over 100 open source issue tracking tools, and at least several dozen issue tracking tools. Windows competes with Linux. Word competes with AbiWord. The existence of open source products in a market segment confirms the segment exists, it does not necessarily mean there is no room for commercial products in the segment.

    FogBugz 1.0 was pretty ordinary, and Joel’s site’s popularity was no doubt vital to getting a foothold in the market for a basic 1.0 product. That was 5 major versions ago; FogBugz 6 is quite impressive, very featureful and polished. Trac and Mantis (open source tools that we use in projects here) are nice but they aren’t comparable to FogBugz.

  3. >>> Fog Creek aims to make compellingly good software because that is how you outcompete
    >>> established competitors in a commercial shrinkwrap market.

    Neat post, Kyle. I’m a longtime fan of Joel’s writing as well.

    Just to clarify… do you use FogBugz? Do you agree with the above quote or was that from Joel?

    I have never used his software and wonder if it is as good as his writing.