The fastest way to make your bug tracker into a challenging project is to approach it with the idea that it's not a challenging project and therefore unworthy of serious developer time or energy.
We had one of those where I work. It just got its ass decommissioned and replaced by virtue of being too challenging to work with.
Every non-trivial program has significant challenges in it; if you can't see them, it's probably your lack of experience or your casual assumption that it must be easy, not the fact that the task itself is that easy.
Of course, that challenge may be hidden behind other problems. You may not be allowed to actually address the challenges; a code monkey making the same change to 50 webpages instead of writing the proper code to do it all in one fell swoop is doing something challenging in the sense of difficult (more difficult than it has to be!), but not the right things. This is a far more common cause of "unchallenging programming" than the actual lack of hard problems; most of the time, most programs completely fall apart under their own complexity load before the true challenges even come into sight. This is, however, the fault of the system building the program (programmers and management), not the problem domain. Wherever there are people to interface to computers, there is challenge.
> Every non-trivial program has significant challenges in it; if you can't see them, it's probably your lack of experience or your casual assumption that it must be easy, not the fact that the task itself is that easy.
I remember Joel talking about Wasabi, purpose built language for making their main product cross platform. I see many business software vendors doing this e.g., SAP with ABAP, but I'm curious as to whether there has been a significant ROI from it (I heard mixed things about its current status of both Wasabi and ABAP and since I have no background in business software I'll refrain from commenting further on this practice).
I agree that are there are significant UI/UX challenges in a system like a bug tracker (and quite frankly, most of the existing offerings are a disaster in that space). There's also a whole slew of fairly interesting problems you could do in the greater space (integration with a VCS/code-review/diff tools in comprehensive system like Github, Google's internal tools or some of Atlassian's offerings).
It's also far from a trivial problem, which is why most companies are willing to pay for bug tracking systems rather than write their own (although, it used to be common to use heavily customized versions of Bugzilla): problems don't have to be "hard-core" to be non-trivial or extremely useful (much like Joel advices, I'd refuse to work in a company that didn't have a bug tracker). If I ever gave an impression that I considered a bug tracker trivial, I apologize for it.
What I should say instead is if you're looking for a "hard-core CS" challenge (systems, networks, data structures and algorithms) -- and certainly only a small minority of people are both qualified to and are interested in working in that space, in reality these topics involve lots of fairly unglamorous work -- a bug tracker seems like the wrong thing to work on.
I wouldn't make the whole point, if Joel didn't spread the whole "we're hiring best programmers to solve the most difficult problems" aura and has instead stated "we may not be the most hard-core, but we build great products and treat developers as more than just cogs". The latter point sounds a lot more honest and still suffices in terms of recruitment. There are many people (including many hackers I know and respect) who are passionate specifically about development tools and they're the people you want to be working on development tools who aren't going to be interested in Wall Street (or any other place where building development tools isn't a core competency, which excludes most other software and Internet firms with exceptions of the largest, who have custom needs) in the first place.
One thing which is surprising with bug tracking is how crappy most of the products are, especially the open source ones. This strikes me as odd a priori since open source is generally pretty good at core programming tools - and bug tracking certainly fits that category.
We had one of those where I work. It just got its ass decommissioned and replaced by virtue of being too challenging to work with.
Every non-trivial program has significant challenges in it; if you can't see them, it's probably your lack of experience or your casual assumption that it must be easy, not the fact that the task itself is that easy.
Of course, that challenge may be hidden behind other problems. You may not be allowed to actually address the challenges; a code monkey making the same change to 50 webpages instead of writing the proper code to do it all in one fell swoop is doing something challenging in the sense of difficult (more difficult than it has to be!), but not the right things. This is a far more common cause of "unchallenging programming" than the actual lack of hard problems; most of the time, most programs completely fall apart under their own complexity load before the true challenges even come into sight. This is, however, the fault of the system building the program (programmers and management), not the problem domain. Wherever there are people to interface to computers, there is challenge.