Don't get me wrong, I know why we use them. We track our issues and bugs so that we can control and manage them. Right, got it, but in this fine, fine universe of issue tracking we've created we've perhaps forgotten why we track them in the first place. It's because we've got issues.
We don't have issue trackers because we want to track issues in a database. We've got them because we get issues and don't know any other way of dealing with them. There's a gap between understanding that issues is something we get from doing things wrong and trying to work out ways to deal with them. Issue trackers are not there to help us fix problems, they're there to help us organize our problems. But we still got problems even if they are shifted into another system, in fact duplicating their existance.
Now, having said that, this state of affairs comes from the way issue trackers are designed, and, to some extent, how we've always viewed them; they are a separate bucket to carry shit in. So we got some shit in our system, and we dump some of it into this other bucket to offload our systems, and we think somehow that the weight of our systems get lighter through using this bucket. But the truth is that we've still got the same amount of shit lying around, albeit in a more organized way. No, it's even worse; we now got more shit lying around. Well, to a point.
What happens when it's time to shift the shit from one place to another? Those who come from a colder climate farm-life know all about the cow shed, how there's a trench down the middle of the hall that you scoop all the shit into, and then from there down to the manure cellar underneath. So now you've got a nicer looking hall, but you've still got a cellar full of shit. At some point you need to get that shit out of there, because it doesn't go away by itself. (Incidentally, a good friend of mine, Jens Maage and his company BioWaz, use manure cellars for producing electricity; you should check it out!)
Most, if not all, issue trackers are pretty much the same thing; a database of issues, and then you can shuffle things about with multi-person interaction. There's nothing magic about it, and there's a particular model of "issue trackers" that we've all come to accept, not only as a way to deal with issues, but that every project in the universe must have one of or else they will fail. JIRA, BugZilla, Trac, whatever; they're database applications that offer some interaction to shift shit around.
But is this really a good model? Is this the best we can come up with?
Every application, every system, every class, or every little piece of code will, at some point, be addressable, but not always in a meaningful way. The problem is quite often one of identifying a bridge between "the issue" and the systems we create. Some times this is very hard, like with workflows. Some times it's dead easy, like with a GUI. At the end of the day, the success of any issue tracker - and hence, the success-rate of the issues you're trying to resolve! - depends on how the human interaction against it is done. Poor user interfaces is, in fact, a make or break for this, a sad, sad fact that's been neglected for far too long. I guess most of the reason for this is because issue trackers were created by geeks for geeks, and as geeks we worry about functionality first and aesthetics later, if at all. It's not until you talk with HCI professional you learn that the two are not even separated, but two facets of the same thing.
I've whined long and hard about issue tracker user interfaces in the past, and I'm not going to revisit them here, but suffice to say they mostly suck. Give JIRA to normal people, and they can't understand what on earth they are supposed to do with it. BugZilla and Trac are no better. (I haven't tried the latest version of FogBugz which I hear good things about, but it's still based on the separate divide idea, and I've tried some older versions which, indeed, sucked)
"Stop whining and show me alternatives, schmuck!" I hear me say. On one of my last projects I embedded issue tracking and reporting straight into the applications GUI itself. A small button in the top-right corner on any page (and sometimes on whatever part of the GUI you would like) would pop out a pre-filled form with things that's important to the bug hunter later; URLs, login credentials, roles, names, runtime environment, version, states, and so forth. This gives us some very important things;
- Nearest possible identificator to where the problem was discovered. (And yes, this works even when the point of error can't be determined; the front page is a good start for any weird issue)
- Boring information already filled out, taking less time and would be more accurate. People will report more issues if it's easy to do.
- Possible automatic "screenshots" (state, page, role, etc.) of issue state, making it much easier to back-track and find the bugs again.
- Visual cues for visual humans, tacit cues for stupid computers.
- Integrated point of contact, so even if reports come out through some other application, the point of interaction is where the application is, lowering the threshold of entry.
- Possible loop-back to developers who can browse the application and simple reports to move to points of issues. Every page can have a counter of issues in the vicinity of it (and clicking it display all of those issues). How freakin' cool is that?!
Now, if the admin interface and the shifting of shit around could be integrated into the interface itself as well, I could do away with the whole GUI of the issue tracker, and just use the database and underlying issue model part of it. Now that would be cool, and would be an important step forward in making tools work for developers instead of just shifting the shit to the side in the hopes of making it go away.
Of course a lot of applications don't have a GUI. Let's invent better ways of doing this, from mock test classes to functions that can somehow integrate against issue trackers (or embed them). There are better way of dealing with these issues; we just got to think smarter about it. I'm sick of having one tool for every little domain of trouble we can think of. We need less tools to do a better job, not more. Less is more; we've know this for many years.
Shit never goes away; they're a natural part of life. But instead of just chucking the shit down into our manure cellars and hope it goes away or resolve itself we should design systems where the shit is immediately turned into something more useful. Like electricity. Or, in our case, into better pointers and interaction with the actual problems, directly at the point where the shit was found in the first place.
Issue trackers as they exist today must die, and become one with the problem.
I was enjoying your shit/barn metaphor in your post, and was curious to see where your thinking was going.
ReplyDeleteBut, then, you shifted into the topic of making it easier to capture issue data, making the form more available, automating it a bit. The info you capture, though, still goes into Jira.
In terms of your metaphor, you have proposed an easier way of collecting the buckets of shit and moving them into the shit pile. But your proposal doesn't deal with making the shit pile go away.
Where I thought your post was going was some sort of practice, thinking, habit that would prevent the shit pile from growing higher and higher.
I see where you're going with this, and I'm sorry I didn't leap into a lament on how to make things better. Although, I think I was. Let me try to clarify;
ReplyDeleteI think the point I was making was to reduce the shit by integrating into the already existing pile of shit better ways of addressing that shit. We're not going to get rid of shit, because, let's face it, we're always going to create steaming piles of the stuff no matter how clever we think we are, no matter the precautions and rigor we wrap around it.
For me, the issue trackers, the documenting Wiki's, the build farms, the IDEs, all the various tools we use are external tools used to make sense of that inner thing known as our "application", and they are all sadly disjoint from the application itself. What I'm talking about is to build into our application measures for dealing with shit instead of letting it slip outside, filling up your cellar.
This analogy can be taken further; why do we design applications as if they will run perfectly? We never design cellars to deal with unlimited amounts of shit; at some point you need to get it out of there to make space for more shit that's coming soon. No, instead, by designing for change and faults, we can create systems that are easier to fix. That's really the point here; bringing a more eco-friendly structure to how we design our systems.
Let's face it, we will never design systems that will run perfectly in production. Let's deal with that shit.