Someone asked me several years ago why I am writing yet another issue tracking system, "There are literally hundreds of them" he said. "I know", I said, "but this one will be different". How many times has that been said?
I am fully aware that almost everyone at some point in their software writing careers has thought of or written a bug tracking system. They write these because their specific business need is not satisfied with the "hundreds" that are on the market today. Or, more likely, the ones on the market are just too feature rich and overly priced. Why wouldn't you write your own if you are just trying to capture some common information so you don't use half of the "features" but you still have to pay an arm and a leg? Or the tools are the market do not fit how you work. Some developers like to use Outlook tasks, some developers like to use an integrated IDE, some developers like to use a TODO.txt file. Everyone is different and so to find a tool that fits the needs of a whole team is difficult.
Throughout my career, I have used many tools to try and make the software development process a little more organized. Organized projects obviously have a better chance of getting done on time and on budget.
The tools that I have used however have been lacking in one area or another or they are just too "feature" rich and complicated. They all contain some sort of major pain points. I am just trying to reduce those major pain points. Those pain points range from having too much information to enter, too painful to add multipe work items within a session, too painful to edit multiple work items, too many fields to enter, not fast enough, to not enough integration into other applications that developers, managers, and testers use.
The system that I am building will address these pain points and concentrate on simplicity. It will not corner the users into a certain way of collecting work items for a software project. It will have integration points with the other software that you use. The first release will concentrate on collecting and editing the information followed quickly by the integration piece. After that release, I will look at actively using that information to help users manage a project. That is a whole 'nother conversation.
For those that already know about the history of this application, you may want to know what the heck have I been up to. I started working on the application several years ago and I have been working on it in between client projects for a full year. I was close to releasing it but when I started using it, I found that it sucked. So I scraped it and started over. I am happy with how the new one is looking and I am definitely going to dog food it a little earlier.
If you are interested in learning more, you can sign up at http://teammorale.com. You can also follow the development process and release process on Twitter at http://twitter.com/morale. We want to be very transparent and share with you our ideas and thoughts behind the application.
Comments