My final set of requests for a development environment involve the bug tracking system.
The initial observation that I wish to make is that bugs relate to a particular version of code. And that bugs stay with code until they are fixed. This means that bugs are related to the version control system. For any branch of the code, you should find exactly which set of bugs it has, and which bugs remain open. Closing bugs tends to relate to a particular point in a version control system: either "This is the fix for the code" or "This is the point where I verified that the bug no longer exists". When you split a branch, you take the bugs from that point in time - and when you merge a branch back into the main tree - or pick up the changes from one branch into another, you should pick up the changes to the bug database too.
In an ideal system, when you check out a branch onto a local machine, you should also be able to check out a copy of the bug tracking system... which you can make changes to - changes which will be applied when you merge back later. This allows you a full dev environment when away from the corporate network.
Bugs are also related to tests. Tests should be able to generate bugs... these bugs are probably along the lines of "Test xyz fails", providing links to an overnight test failure. Bugs should also be able to say "This test will identify this bug" so that you can get the test system to help verify when a bug has gone.
Bugs form trees (or rather directed acyclic networks), in a similar way to a version control system. For example the test system might generate the bug "Test xyz fails". I might take this bug and want to split it into two bugs "On windows test xzy fails because of foo" "On Linux test xyz fails because of something else". If I were to then notice that I already have a bug about windows failures due to foo, I should be able to merge that bug with it.
Bug entry needs to be easy. Really easy. When a test fails, I need to be able to add a few notes to it and WHAM! thats the bug added. Bugs are a place to store knowledge, and to allow me to find things that are outstanding.
Bugs also need to be integrated with email. I need to be able to send people questions, directly relating to the bug (so that the question, and the response, are stored in the bug). Bugs really are a chat system. This is not a bad thing.
Finally, Bug tracking and todo lists are tightly integrated. So much so, that most developers I know use bug tracking as their todo list. So when I send another developer a question - that needs to show up in their todo list - as an uncompleted part of a bug. And users need to be able to add their own private bugs, and import their emails into bugs to let them keep track of their own tasks.
I've talked about bug tracking for non-IT businesses elsewhere. And this bug tracker needs to support all of that.
Showing posts with label bug tracking. Show all posts
Showing posts with label bug tracking. Show all posts
Thursday, 29 April 2010
Thursday, 15 April 2010
Bug Tracking For Business
Lets assume that telecommuting is desirable. Lets also assume that this is going to bring in a new raft of management issue (which is why the current generation are still dragging their feet on the way towards it). One of the biggest issues is visibility
At the moment, managers can manage by walking around, coming up behind you, suprising you and occasionally overhearig what you are doing. They get a good idea of what is going on from the office atmosphere. With everyone apart, communicating by a number of channels, both public and private, they will lose this sense of being in touch.
The IT indisutry is, however, already full of people who don't like to talk. Or see each other if at all possible. And we write tools to keep track of what we ought to be doing - one of the most used is the bug tracking system. Each software bug is entered into the database, passed around between people who take responsibility for it, and eventually it is closed. At the flick of a swithc a manager can see which bugs are still a problem and (by reading comments) exactly how near a programmer is to solving it.
And in the IT industry we have learned to abuse the bug tracking system. Almost everywhere managers add new features to the bug trackign system, as a way of assigning new tasks to programmers. And at one place I worked, an early bug was "We have run out of milk in the kitchen" which later became "we keep runing out of milk and need to find a way to stop this happening"
I was shocked when I heard that other white collar industries don't have anything similar. Sure they have their emails, their outlooks, their calendars and maybe their todo lists, but a simple Way of tracking how far they are on each problem, and of collecting all the information on each task, so that, if they need to hand it over to someone else they can do so trivially, all while being visible to anyone interested is missing.
The problem is we call bug tracking systems bug tracking systems, and orient them towards the sort of tasks programmers do.
While I was wondering about my ideal system for implementing something like Getting Things Done in my own life, it became clear that I wanted all the characteristics of a bug tracking system behind everything. I wanted to create dependencies and to be able to see all open tasks. I wanted to be able to categorise tasks and filter my searching appropriately. I wanted emails to tell me what I needed to do and when.
And I think this would be a superb addition to any office environment, especially one where telecommuting was considered desirable.
Not a bug tracking system (that's too IT oriented) but a Workflow Organisation System. Something which does to bug tracking what Facebook did to email, something that makes it all friendlier and simpler, with all the complexities hidden.
And with one feature that most bug tracking systems miss: the ability to create private tasks for your own use... because that allows you to use it for everything in your life (or your worklife) not just those things a manager wants visibility on. And that makes it something that can become generally useful to everyone.
At the moment, managers can manage by walking around, coming up behind you, suprising you and occasionally overhearig what you are doing. They get a good idea of what is going on from the office atmosphere. With everyone apart, communicating by a number of channels, both public and private, they will lose this sense of being in touch.
The IT indisutry is, however, already full of people who don't like to talk. Or see each other if at all possible. And we write tools to keep track of what we ought to be doing - one of the most used is the bug tracking system. Each software bug is entered into the database, passed around between people who take responsibility for it, and eventually it is closed. At the flick of a swithc a manager can see which bugs are still a problem and (by reading comments) exactly how near a programmer is to solving it.
And in the IT industry we have learned to abuse the bug tracking system. Almost everywhere managers add new features to the bug trackign system, as a way of assigning new tasks to programmers. And at one place I worked, an early bug was "We have run out of milk in the kitchen" which later became "we keep runing out of milk and need to find a way to stop this happening"
I was shocked when I heard that other white collar industries don't have anything similar. Sure they have their emails, their outlooks, their calendars and maybe their todo lists, but a simple Way of tracking how far they are on each problem, and of collecting all the information on each task, so that, if they need to hand it over to someone else they can do so trivially, all while being visible to anyone interested is missing.
The problem is we call bug tracking systems bug tracking systems, and orient them towards the sort of tasks programmers do.
While I was wondering about my ideal system for implementing something like Getting Things Done in my own life, it became clear that I wanted all the characteristics of a bug tracking system behind everything. I wanted to create dependencies and to be able to see all open tasks. I wanted to be able to categorise tasks and filter my searching appropriately. I wanted emails to tell me what I needed to do and when.
And I think this would be a superb addition to any office environment, especially one where telecommuting was considered desirable.
Not a bug tracking system (that's too IT oriented) but a Workflow Organisation System. Something which does to bug tracking what Facebook did to email, something that makes it all friendlier and simpler, with all the complexities hidden.
And with one feature that most bug tracking systems miss: the ability to create private tasks for your own use... because that allows you to use it for everything in your life (or your worklife) not just those things a manager wants visibility on. And that makes it something that can become generally useful to everyone.
Subscribe to:
Posts (Atom)