Recent posts







Recent comments

Archive

Sign in

BugTracker.NET in the big corporation

by Corey Trager 11/20/2007 10:17:00 PM



Brilliantly simple, incredibly powerful bug and issue tracking software used by more than 8,700 organizations in over 97 countries.
Get your free evaluation copy now.
A bug tracker, project wiki, requirements manager, and help desk solution that manages the development process so developers can focus on coding. Windows, Web, and VS.NET interfaces.
Free single-user licences and 30-day Team Trials
Easy and Clear bug, issue, requirements, and support ticket management. ASP.NET Web, Windows, VS.NET and MS Outlook integration.
Free 5 User License to get you started!

In my previous post about eating my own dog food I outlined three settings where BugTracker.NET struggles or falls short entirely to be a good fit. In this post I’ll go into detail about one of them, a “big company with hierarchy, division of labor, and rules about who is allowed to do what”.

I’m going to describe a database model that such a setting might demand. I’ll start simple, and then as I add requirements, I’ll revise the model.

I’ll start with a table of  “issues”. There are different types of issues: bugs, enhancements, tasks, trouble tickets, so I add a lookup table of “issue types”. Issues can be in various statuses like “new”, “in progress”, “closed”, so I’ll add a lookup table of “statuses”. And of course, there are users. Here’s my simple model so far...

Issues
Issue types
Statuses
Users

It turns out that there are different kinds of users, such as  “programmers”, and “testers”. These are “roles”. And it turns out that this company has restrictions about who can change a status from one to another, depending on a person’s role. Maybe only “testers” can change a bug’s status to “passed testing”. Altering the model accordingly...

Issues
Issue types
Statuses
Users
Roles: A user must be associated with a role (just one role).
Roles - Statuses: Defines which roles can use which statuses.

It turns out, that the life cycle of one issue type isn’t the same as another. A “bug” might have statuses like “new”, “assigned”, “ready for testing”, “tested”,  “shipped”, “closed”.  A “task” might have statuses like “new”, “in progress”, “done”, etc. Altering the model according...

Issues
Issue types
Issue type statuses: Each issue type has its own set of statuses.
Users
Roles
Roles – Issue type statuses: Defines which roles can use which statuses.

It turns out that the people sometimes don’t understand the correct sequence of statuses. If a bug is now in “ready for testing” status, the next status couldn’t be “new”. It would have to be something like “passed testing” or “failed testing”. Altering the model accordingly...

Issues
Issue types
Issue type statuses
Issue type statuses – related statuses: Defines which statuses are valid “pre” and “post” states for any given status.
Users
Roles
Roles – Issue type statuses.

It’s a big company. There isn’t just one project, and different teams want to do things different ways. So, let’s add “Project” and allow everything that’s configurable to vary by Project. Also, the same person might be on more than one project and have different roles on the different projects...   (See my "Empathy with Jira" post - this is what Jira's customers want.)

Issues
Project
Project Issue types
Project Issue type statuses: Each issue type has its own set of statuses. Issue types and their statuses are defined per project.
Users
Project Role
User – Project Role: Same person, different roles on different projects.
Project Roles – Issue type statuses: Defines which roles can use which statuses.
Project Issue type statuses – related statuses: Defines which statuses are valid “pre” and “post” states for any given status.

See where I'm going with this? With each new requirement, control and configuration is getting more and more granular.  On the one hand, the model is becoming more like the real world, but on the other hand, the model is becoming unwieldy. 

Did you ever try to model a contact list, or address book? John and Mary have their home, their summer home, their workplaces, their home phones, their cell phones, the phone in their summer home.  If you modeled that like a relational database designer, it would end up being a very complicated model.  You might have entities like Person, Location, Location Type, Phone, Person/Phone, Location/Phone, Household, Household/Location.   Real world contact lists - like the ones in Yahoo mail or Gmail - flatten out everything.  Easier for us to understand.  

As a data model becomes more complicated, as there are more "by's", as in status BY item type BY project, the GUI becomes more complicated also. The task of configuration becomes bigger, more time-consuming, more daunting.  While I do want BugTracker.NET to be more adaptable, I always want it to remain a good choice for the small, fast, informal, non-hierachical team. 

Right now, BugTracker.NET's data model is the first model I described.   Very simple.  (BugTracker.NET does have "Projects", but item types and statuses are global, not per project).  The model is too simple to meet the requirements of a big organization that wants an issue tracker to help enforce hierarchy and division of labor. In the near future - the coming weeks - I will be adding the concept of role to BugTracker.NET in December (it's already implemented in the development codebase), but I don’t have plans in the near future to support different status types for different issue types and no near-term plans for enforcing valid pre/post status transitions. So, because BugTracker.NET lacks the means to enforce hierarchy, division of labor, workflow, I think that large corporations, which tend to be enforcement-minded, would find it lacking.

 

Tags:

issue tracking

E-mail | Kick it! | DZone it! | del.icio.us
Permalink | Comments (10) | Post RSSRSS comment feed

Comments

1/9/2008 5:44:19 PM

What you describe in the complex scenarios (different sets of statuses and restricted transitions between statuses) is called "workflows" in other bug/issue tracking systems. Once you start thinking in terms of workflows, things become a little easier (both database schema and programming logic). Hope that helps.

Alexei Boukirev

1/10/2008 11:47:12 AM

Strange, my first attempt at commenting seem to get lost somehow.
A collection of statuses and possible transitions between them is called a "workflow" in other bug/issue tracker systems. You only need to validate against it and populate drop-down selection of statuses during issue editing (and also in workflow configuration screen, of course). No need to enforce any other constraints otherwise. That should simplify design.

Alexei Boukirev

1/10/2008 12:40:22 PM

Sorry Alexei - I was just slow in approving your first post.

I do understand the term "workflow". The fact that you think I didn't understand that term shows that I didn't do a good job explaining myself in the original post. Sorry. Let me try again...

Let's say we want to allow users to setup up a workflow for bugs that is different than for enhancements. And let's say we want that to be controllable on a per project basis. These are pretty normal requirements for folks who are interested in controlling workflow.

The admin and the admin subsystem now has a lot of work to do, because whereas today with, say, 10 projects each with 3 item types I just configure 1 universal set of statuses, with the workflow rules, I would have to configure 30 (3 X 10) sets of statuses (not even talking about the legal transitions here - just the values to show in the dropdown). It would be a hassle to maintain unless the admin pages offered tools to compare status sets, do mass edits, copies of sets, etc.

That's the admin part. Now, it's bug entry part. It follows that in order to populate the status dropdown, the system would have to do a lookup in the database based on the issue's type and project. In BugTracker.NET, neither project nor type is even a required field. So, right away the change would be to require that those fields be set first before the status dropdown can even be populated. It is unacceptable to me - and I think many BugTracker.NET users - to add the burden of more required fields. That would change the basic character of BugTracker.NET into something else.

So, maybe, in order to to allow those fields to be optional, we would need a scheme for how to populate the statuses when either the project or the item type is not populated. That would add even more complexity to the admin subsystem.

What about change? Let's say after you add an item you want to change either its project or its item type. You want to change a bug in project1 to an enhancement in project2. What happens to the status? What if the original status from the bug/project1 set is not legal in the enhancement/project2 set?

Corey Trager

1/10/2008 5:04:31 PM

Ahh, but you still overcomplicate things. Yo do not need to administer 30 statuses. Let's say you have bugs, issues, and requests. That's 3 workflows with however many (in your example 3) statuses in each.
When a user enter a bug/issue/request, that user selects workflow, that has nothing to do with project type (although some projects may decide to not use some of the workflows).
Complexity does increase when different organizations use different workflows but I doubt there would be so many different permutations. And for a single organization it makes a lot of sense to standardize on practices across different projects.
Regarding changes from project to project, you gave a bad example: the bug in first project should be closed with a proper description, an enhancement in the second project should be created and reference a bug number in first project - they are two different things.
In my programming work I used to come up with crazy scenarios but I learned to drop them or split into simple ones.
Just put it aside for a while, eventually you'll have a bright idea of how it should be done. Or maybe I'll have an idea Smile

Alexei Boukirev

1/10/2008 7:20:47 PM

Regarding "that has nothing to do with project", see Jira's documentation at www.atlassian.com/.../workflow.html where it says,

"JIRA Enterprise supports multiple active workflows. Each workflow can be associated with particular projects and (optionally) particular issue type(s)."

Jira is considered to be very powerful and configurable, but also very complex. Some folks evaluating a bug trackers are drawn to its power, some are put off by the difficulty. It's a tradeoff. That's a theme throughout many of my posts.

Regarding "the bug in first project should be closed with a proper description, an enchancement in the second project should be created and reference a bug number in the first projet". Well, yes, there are some trackers that would force you to do things YOUR way, but BugTracker.NET let's you simply change the project and type. Some folks might like a tracker that enforced your way of doing things, others like BugTracker.NET's looseness.

I do try to make both kinds of users happy by supporting both a loose and strict style of configuration, but that approach has its own complexity both for users and me, the programmer, and since rigidity is not my personal style, my heart's not in the work.

Corey Trager

1/11/2008 1:05:36 PM

Yes, JIRA is complex and powerful. Does BugTracker.NET need to catch up with it in one huge step or are there intermediate steps possible? The final goal is indeed to give the most flexibility. The road there is not necessarily straight... Besides, having capability and having really useful capability are very different things. It'd be interesting to see how many unique workflows per project on average are used in JIRA in multi-project setup. There are other products with limited number (in some configurations) or even single workflow that are still very useful. Now that I'm thinking of it, it seems that issue type defines statuses, while workflow defines possible (and mandatory) transitions between statuses. So the task can be split into 2.

I admire your efforts to make all kinds of users happy. What I suggested with closing bug and opening a new enhancement is in no way to complicate things. The user would just change project/issue type, while the system would create new record and populate most of fields from the bug record (or operation could be performed by clicking "Evolve" button). The good side effect will be that no one will say "Where did the bug go? Can't see it with filters off." What I'm saying is that users may not be aware of all the consequences of the action, so careful design is important there as well.

I like BugTracker.net very much and care about it. Thanks for all the work you are doing. Sorry, if my posts came through looking as though I'm pushing for something. It's just that I have been through 3 different designs in my current application before I understood the issue and ended up with a much simpler design that works Smile

Alexei Boukirev

1/11/2008 1:26:39 PM

I wouldn't say that I'm trying to make all kinds of users happy. Just the opposite. In my post here, I wrote that I do *NOT* have plans to change BugTracker.NET to be a better fit for a hierarchical organization.

Corey Trager

3/1/2008 9:07:20 AM

I did make a change recently to allow BugTracker.NET to enforce workflow. Instead of designing a complicated database schema that would accommodate the most granular schemes people could dream up I created a designed place where people with some basic C# coding skills could add rules. Allowing people to express the rules in C# is probably easier anyway. The rules could be expressed something like this:

if (currentStatus == "fixed by programmer" && userOrganizastion = "tester"Wink
{
listOfNextStatuses.Add( "passed testing" )
listOfNextStatuses.Add( "failed testing" )
}

Corey Trager

10/9/2008 6:07:15 AM

Hi, Corey! I would like to add some rules to BugTracker.Net to enforce the workflow. How can I do that? Where should I write those rules? Where is that place you are talking about? And what version of BugTracker.Net supports adding rules?

Margarita

10/9/2008 7:06:12 AM

Margarita - Take a look at the sample code in workflow.cs

Corey Trager

Add comment