Google “revolutionises” issue tracking
I spent the weekend digging around “Google Code”:http://code.google.com/hosting/ – and to be honest, I was less than impressed. Let’s just say that SourceForge – however bad it may be – has nothing to fear at the moment.
The part that most interested me though was the whole “new approach to issue tracking”. From my readings, this comes down to throwing out all fields, replacing them with a large text area and labels (ne. tags). “Deconstructing Databases”:http://radar.oreilly.com/archives/2006/09/deconstructing_databases.html has more background information.
Perhaps I’m too invested in the area, but I just don’t get it. To me, it’s simply a worse system than most existing issue trackers. Yes – flexibility is good, small input forms are valuable, labels are useful devices to allow amorphous categorisation but are _fields_ really that evil?
What do I do if I want a due date on my issues to do temporal scheduling? Label something as “DueDate-27/09/06″? OK. I can do that. What if someone else labels their issue as “Due date-09/27/2006″? Now I can’t see all due dates together easily – for example to put issues on a “calendar”:http://confluence.atlassian.com/display/JIRAEXT/JIRA+Calendar+Plugin.
Fields themselves are not evil. To me, it’s a question of education. Yes, if someone buys a copy of JIRA and _requires_ 80 fields to enter an issue – well, I’d guess they won’t get many issues submitted. Hopefully they’re smart enough to realise this, get feedback from their own users and pare this back over time.
I’d hate to think of the reaction from our customers if we suddenly announced we were throwing out JIRA’s custom fields in favour of more flexible labels and a single textarea.
Perhaps it’s a case of launching one of those “newer, simpler products” (which really means they just haven’t had time to build a fully featured product, so they therefore convince people they don’t need all those features… until they are added in v 2.0) or did some Google engineer just read Joel’s “old piece” on why FogBugz is philosophically opposed to custom fields. I’m not sure.
I for one will be watching to see when they add fields though…
A year ago the CTO of a successful Enterprise Search company told me how databases were doomed as the foundation of Enterprise Software. Everything will be flat, since search is so powerful…
Baloney. I do buy the concept of using unstructured searchable information more and more – on my PC I hardly bother saving stuff in folders anymore, since desktop search is good enough. You must believe in “less structure: to some extent, since you’re selling a wiki, which does not come with *predefined* structure… but people do use wikis to build structure, except it’s their own, not preimposed.
But just because we now have the raw power to find info in the jungle, we should not throw away the finesse of databases and applications: That would be throwing the baby out with the bathwater. (and complete nonsence with transactional systems).
In a more generic sense it’s the essence of the Enterprise 2.0 debate: it wont be either the old, bad, rigid system vs. social software. It will be a blend of both.
Don’t throw out the custom fields for labels – but please please please ADD labels
One thing I’m holding out for is a way to categorize indiscriminant issues across projects with a similar tag, then pull that into say a confluence page.
At our institution I’ve needed to give department custom fields because they don’t do software development, but they track issues. They need various dates and to be able to sort on those dates. This Google Code doesn’t really sound like much of a threat…yet. Who knows where they will take it.
Alan Perlis once said “It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.”
Google can search text like nobody’s business. Given the size of their hammer it makes sense for them to treat everything as a nail.
Even small hammers can be effective. I use a mail client called mutt, which can search text at blazing speeds. When I want to find a JIRA issue, I frequently avoid the JIRA interface and point mutt at a mailbox of JIRA email notifications. It can find any regexp in 210Mb of raw text (~10,000 issues’ worth) in under 4s. No mucking around in a web interface finding projects and fields. No wondering if Lucene butchered my search terms. It’s simple, fast and accurate, just like Google.
That doesn’t mean field-centric apps can’t *also* be simple, fast and accurate. It’s just that in practice, they rarely are.
Did you try administering a project? The labels have configurable structure effectively making them custom fields (with enumerated types at least). The labels may not be as robust as what Jira offers, but they’re certainly suitable to small Open Source projects where you only have a few developers managing bugs and minimizing administrative overhead is a top priority.
Unstructured or tag search can supplement not replace structure searching. They are great when the data is unstructured. However it is easy (and norm) to store DTS data in structured format. It is foolish not to leverage that capability. I don’t buy Google’s vision here.