Print
Bookmark with del.icio.usBuild a Web-Based Bug Tracking App
by Jesse Liberty
05/09/2006
For the last few articles, I've been discussing applications I was asked to build or to assist with. In this article I will cover a bit of quick ASP.NET programming I've done for myself that, one day soon, may turn out to be a product.
Please note, this article assumes you are already comfortable with creating ASP.NET applications, using the Website Application Tool, and using Data Source controls with SqlServer.
"Save time, don't put the bugs in."
--Patrick Johnson
Every time I set out to create a project, I'm confronted with the same question: "How will we track the bugs?" I find there are a plethora of solutions to this problem, but none that I want. Most of the time, they are far too complex for the kind of 1-3 person project I tend to work on. Recently a light bulb came on (actually, it came on in my co-author Dan Hurwitz' head, but it illuminated this article). What I really want is the absolute simplest, easiest to use, totally reliable bug tracker and, well, that can't be all that hard to write myself.
What you learn when you set out on such a project is that the truly hard part is exercising the self-restraint to keep it truly simple and avoid adding features. Thus, Tiny Bug Tracker (TBT) will be built in three stages:
The simplest usable bug tracker
The few additional features I really, really want
The business version (that is, the one on which we might build a business)
I won't be writing about phase 3 unless a) it is really interesting, and b) I decide that giving away that much of the source code won't kill the business before it is born. In any event, the first two parts should, I hope, illustrate a few interesting aspects of building ASP.NET applications. This particular article (which may well turn out to be part 1 of 2 or even part 1 of 3) will focus on the absolute minimal set of functionality: just enough to keep track of the bugs in a program and not one additional feature.
Further, as a development strategy, every time I have the option to do it fancy or do it simple, I'll choose simple--as long as I create reasonably factored code that will allow me to add features and fix it up once I start using the program.
The minimal feature set
To keep the feature set very small, I've divided the features into three groups:
Those features that must be in the program
Those features that will be in the program eventually, but can be done externally for now
Those features I want, but which don't make the first cut
Before I started coding, I created three lists, even though I knew that by the time I wrote this article (having completed step 1), the lists would have changed. Here are my original lists:
Features that must be in the program
Ability to add a bug
Ability to modify a bug
Ability to see all the bugs
Features that will be in the program eventually, but can be done externally for now
Add users (use WAT) [Note: the WAT is described below]
Add roles (use WAT)
Audit trail of a bug's history (use DB)
Features I want, but which don't make the first cut
Filter the list of bugs (by the following, for example):
Just my bugs (for developer/ manager)
Just my open bugs (for developer/ manager)
All open bugs (for manager/ QA)
All closed bugs (for manager/ QA)
Just show stoppers (for team)
Etc.
Reports
Show me all bugs by priority that have been open for more than n days.
Etc. (by Etc., I mean there are a lot of potential reports)
Role management (for example):
Restrict pages and/or controls based on role (e.g., only QA can close a bug)
User management
Screens to add users, add roles, and assign users to roles
Stop second-guessing
I could have spent the next month second-guessing what belonged in each list. In any case, the lists would change as I developed the product. It turned out, for example, that displaying the audit trail of a bug made it into the first cut, only because the design I used for the database (discussed in just a moment) made this wicked easy to do.
http://www.windowsdevcenter.com/pub/a/windows/2006/05/09/build-a-web-based-bug-tracking-app.html
Bookmark with del.icio.usBuild a Web-Based Bug Tracking App
by Jesse Liberty
05/09/2006
For the last few articles, I've been discussing applications I was asked to build or to assist with. In this article I will cover a bit of quick ASP.NET programming I've done for myself that, one day soon, may turn out to be a product.
Please note, this article assumes you are already comfortable with creating ASP.NET applications, using the Website Application Tool, and using Data Source controls with SqlServer.
"Save time, don't put the bugs in."
--Patrick Johnson
Every time I set out to create a project, I'm confronted with the same question: "How will we track the bugs?" I find there are a plethora of solutions to this problem, but none that I want. Most of the time, they are far too complex for the kind of 1-3 person project I tend to work on. Recently a light bulb came on (actually, it came on in my co-author Dan Hurwitz' head, but it illuminated this article). What I really want is the absolute simplest, easiest to use, totally reliable bug tracker and, well, that can't be all that hard to write myself.
What you learn when you set out on such a project is that the truly hard part is exercising the self-restraint to keep it truly simple and avoid adding features. Thus, Tiny Bug Tracker (TBT) will be built in three stages:
The simplest usable bug tracker
The few additional features I really, really want
The business version (that is, the one on which we might build a business)
I won't be writing about phase 3 unless a) it is really interesting, and b) I decide that giving away that much of the source code won't kill the business before it is born. In any event, the first two parts should, I hope, illustrate a few interesting aspects of building ASP.NET applications. This particular article (which may well turn out to be part 1 of 2 or even part 1 of 3) will focus on the absolute minimal set of functionality: just enough to keep track of the bugs in a program and not one additional feature.
Further, as a development strategy, every time I have the option to do it fancy or do it simple, I'll choose simple--as long as I create reasonably factored code that will allow me to add features and fix it up once I start using the program.
The minimal feature set
To keep the feature set very small, I've divided the features into three groups:
Those features that must be in the program
Those features that will be in the program eventually, but can be done externally for now
Those features I want, but which don't make the first cut
Before I started coding, I created three lists, even though I knew that by the time I wrote this article (having completed step 1), the lists would have changed. Here are my original lists:
Features that must be in the program
Ability to add a bug
Ability to modify a bug
Ability to see all the bugs
Features that will be in the program eventually, but can be done externally for now
Add users (use WAT) [Note: the WAT is described below]
Add roles (use WAT)
Audit trail of a bug's history (use DB)
Features I want, but which don't make the first cut
Filter the list of bugs (by the following, for example):
Just my bugs (for developer/ manager)
Just my open bugs (for developer/ manager)
All open bugs (for manager/ QA)
All closed bugs (for manager/ QA)
Just show stoppers (for team)
Etc.
Reports
Show me all bugs by priority that have been open for more than n days.
Etc. (by Etc., I mean there are a lot of potential reports)
Role management (for example):
Restrict pages and/or controls based on role (e.g., only QA can close a bug)
User management
Screens to add users, add roles, and assign users to roles
Stop second-guessing
I could have spent the next month second-guessing what belonged in each list. In any case, the lists would change as I developed the product. It turned out, for example, that displaying the audit trail of a bug made it into the first cut, only because the design I used for the database (discussed in just a moment) made this wicked easy to do.
http://www.windowsdevcenter.com/pub/a/windows/2006/05/09/build-a-web-based-bug-tracking-app.html
