So I need something to write about.  I’ve considered starting a blog at several points over the years, but I never got around to it.  Not because I didn’t have things to say, but because I didn’t anything to talk about.  I didn’t want to throw together a bunch of random thoughts, or worse a rant about whatever was annoying me that day.

Then I figured if I was going to write about developing software, I should just go ahead and write some software, the only problem is what to write.  I have a few ideas for viable commercial products that could make a profit, but those aren’t really things that I want to publicize until they’re finished.  I could talk about one of our existing products, like SportsCommander, but again that is a closed-source product, and I don’t think talking about a product that has already been built frankly would be all that interesting.

Then it occurred to me that I should build something that I’ve always wanted to build but never had a good reason.  Something that includes features that I’ve always wanted in similar products but could never exactly find despite a ridiculously saturated market.  Something that I wish I could build and sell, but probably would not be profitable, again because of the market saturation.  Something that would inherently addresses many of the development management concepts that I’d like discuss in this blog.  How about a bug tracking system?  Or better yet, how about an application lifecycle management system (ALM).

Years ago, like most developers, I wanted to build my own bug tracking system, but obviously the last thing the world needs is yet another bug tracker.  At MMDB, we’ve been using BugNET, and it works pretty well for a free open-source system.  Every company has their own, some use classic open source freeware like Bugzilla or JIRA, others use expensive enterprise systems like HP Quality Center or Microsoft’s Team Foundation Server (TFS), and many companies just build their own. 

Many of these systems start out a bug tracker, and then people want to use them for tracking new development work and enhancements too, which is fair enough.  They want to track enhancements.  The want to attach requirements.  They want to plan projects.  Sometimes the system handles these things easily, sometimes not.  Bug tracking evolves from tracking just bugs, to tracking issues (bugs and other things that need to be changed), to tracking work items (any generic type of work that needs to be performed).  For years I had seen the evolution of these systems into something bigger and more integrated, and I wondered when the developer tool market would catch up.  I began to hear about Microsoft’s Team System, which sounded cool, but it was supposed to be extremely expensive and no place I was working would shell out for it any time soon. 

Then, in 2006, as I was reading Eric Sink’s blog (the only blog I really read at the time, unless you count www.thedailywtf.com), I saw his pitch for SourceGear’s new ALM product, Fortress.  Go read it right now.  It’s worth it.  I’ll wait.

I was fascinated.  Tying together requirements and work items and bugs into one integrated system.  My mind spun a vision of some fantasy system where entire when you open a bug, there is the original feature attached to it, and a link to the relevant requirements, including who wrote them, who approved them, any clarifications that have been made, and who to talk to if you have questions.  A system where requirements were a living, breathing, evolving system, rather than a stale Word document that has been tweaked a million times.  A system that solved all the problems I’d seen over the years, and actually made everyone’s job easier.  A system that covered requirements, project planning, QA testing, work item and bug tracking, build management, and change control.  Heck, maybe even a call center module that allows a company to build up a knowledge base of common issues and their resolutions, and allows the company to feed those statistics back into the requirements and planning phases so that they can be prioritized, so that you can be confident that you are actually solving the point-points that your customers facing.

So I downloaded Fortress and tried it out.  It was a very cool system, and certainly worth the money for many organizations, but it couldn’t really live up to the hype that I built up in my head.  Nothing could.  My expectations were too unrealistic.  I was disappointed.

So I looked at other systems.  Most were too complicated.  Most were too expensive.  Most were too difficult to maintain.  They didn’t capture the end-to-end integration the way that I had pictured.  No product met my vision.

So I should build my own, right?  Not so fast.  Building and distributing a commercial software product is really hard.  We always look at the code and think it’s easy, just code it and the money will come, but the reality is that the code is a very small part of the process.  You have QA, documentation, marketing, distribution, payment processing, customer support, and more legal issues than you could shake a stick at.  If you have a great focused product idea that is going to be easy to build and distribute, and will make a lot of money, and will fill a specific need in an underserved niche market, by all means plow ahead.  But if you want to make money by building yet another bug tracker, glorified as it may be, you’ll make yourself miserable.

So that’s where I found myself, with this possibly-great idea floating around in the back of my mind, knowing that it would probably never see the light of day because it was just not practical.  I moved from job to job, working with different systems, and remain moderately irritated that none of them, in my humble opinion, got it right.

I thought maybe I could build it just for MMDB’s internal use, and maybe release portions of it as open source portions of it, but it really wouldn’t be worth the time.  Between working full time consulting contracts during the day, working on MMDB projects at night and weekends, and a wonderful wife and two boys that I’d rather be spend my time with, I have an pretty clear idea of what my time is worth to me, and it’s quite a lot.  If I’m going to spend my time on a system that will never produce a profit, it will need to make my life a whole lot easier, or it will need to fill some other need.

So I’m multi-purposing here.  I’m writing the blog I always wanted to write about writing code and designing applications.  I’m writing about the process of software development, and I’m building the system that I always wanted to.  It will probably never get done, but that’s OK.  I may very well get bored and wander off, but that’s OK too.  The product may be a mess, but even that will teach me something.  The process itself is now the primary benefit.  I’ll get to experiment with some ideas and share what I find, and maybe get some feedback, and I’ll do it on whatever schedule I feel like.  I get to do something grossly impractical just for the sake of doing it, without the commitment of having to get it done.

I’ll go through the whole process here on this blog.  I’ll discuss what  I’m trying to accomplish, why I’m doing things certain ways, lessons I’ve learned over the years, and lessons I’ve learned just recently.  I’ll deal with specific issues, and I’ll go off on a few tangents.  Hopefully people find it interesting and useful.  If you get something out of it, great.  If not, too bad. 

I’ll try to use this as a testing ground to experiment with new technologies, because the only way I can really learn about something is to build something with it.  I’ll put all the code up on CodePlex or SourceForge so you can see it all for yourself. 

Here we go.