Lots of startups may be a single programmer, but my understanding is that the most successful ones have 2 to 4 (http://paulgraham.com/startupmistakes.html). I posted it because I found it useful for my own software project (involving 4 people) and believe me, we're far from a Microsoft type org. Anyway, maybe the bugtracking discussion will be informative for all, no matter how big their posse is. Sera
Many startups with multiple founders have one founder do most or all of the programming work. As I understand it, Reddit is like this: Steve does the coding while Alexis does all the other miscellaneous work. Sun had 4 founders, but Bill Joy did the programming. AFAIK, DHH did most of the initial programming for 37signals, though they obviously have more now. Their advice (in "Getting Real") was to start with one programmer, one designer, and one person who could do swing work - a little server admin here, a little CSS work there. This also squares with Fred Brooks's advice in Mythical Man Month - a programming team should be organized like a surgical team, with one lead programmer and 5-7 people running support so he has no distractions.
There're some big advantages to this structure, mostly involving communications overhead. With one programmer, you don't need to coordinate who does what. You don't need to explain what needs to be done. You don't waste time fixing broken interfaces. You can move quickly and add whatever features the customers want.
I've worked for two startups that have both suffered by starting with a team of 4-5 (1 founder + 3-4 employees) instead of a single founder. It's very hard to get everyone on the same page on the requirements, particularly if the employees don't know the domain well. And when startups change direction frequently, multi-programmers tend to get demoralized (because the switching costs are higher and comparatively more effort went into the previous product), while single tech leads just throw away the old code and write whatever they need.
Perhaps some of the 12 tests/tips are. But I think there is some good stuff in there for solo or small-team projects. I myself have never used a bug tracker, but I sure have spent a lot of time coming up with some sort of solution for that problem. These solutions get pretty hodge-podge after a while (wiki's, email, white boards, notes, etc.), and I am never satisfied. His argument for a good bug-tracker is compelling and it seems like it would benefit any project.
Well, remember that he's selling bugtracking software. ;-) Many of Joel's articles are very good, but remember that they are designed to sell his product.
You do need *some* sort of bug tracking system, but I've never found one that I like. I've used Bugzilla, Mantis, FogBugz (Joel's product) and reported on Jira, Sun's bugtracking system, and SourceForge, but the only one I halfway-liked was Jira. At work, I use pencil & paper along with fixing bugs as they're reported. For my startup, I'll likely roll up some custom solution, as I haven't seen anything that comes close to meeting our requirements. I'll take a second look at what's out there first, though - I've heard good things about Trac, and maybe someone somewhere has come up with a decent bugtracker.
