Estimating with Fogbugz

I spent the weekend putting together a task list and estimates for Onpoint Connect. We use Fogbugz for issue tracking but I always found it a little underpowered for estimating; Even though they added Evidence-Based Scheduling (EBS), there were a number of things missing that made it difficult to build a good estimate that could actually be discussed with other managers. Most notably, it was not possible to setup high-level tasks that contained a number of detailed sub-tasks. I am pleased to say that this has changed in Fogbugz version 7. The subscase feature allows you to create more detailed (estimatable) cases that roll-up into their parent cases. I used this feature extensively to end up with a list of about 10 major cases to discuss with management that contained the much more detailed and numerous cases for the developers to estimate. The EBS algorithm combines the estimate data with historical data on the developer’s estimate accuracy to figure out the probability of completion by certain dates. Fogbugz will even track the estimated work remaining and probable completion dates as they change and show me the trends. Version 7 of Fogbugz has a number of other improvements that impact scheduling including dependencies between milestones and the ability to distribute staff resources across multiple projects.

Fogugz continues to include well-designed features for handling support cases, support email and documentation. The new version has a plug-in architecture and available plug-ins to add features that help with agile development, time reporting, documentation and user stories. The bottom line is I can now recommend version 7 of Fogbugz as the ideal tool for issue tracking, scheduling and documentation for development teams using almost any methodology. It is available as a hosted solution ($25/user per month) or for installation ($199/user). Make sure to check it out.

I spent the weekend putting together a task list and estimates for Onpoint Connect.  We use Fogbugz for issue tracking but I always found it a little underpowered for estimating; Even though they added Evidence-Based Scheduling (EBS), there were a number of things missing that made it difficult to build a good estimate that could actually be discussed with other managers.  Most notably, it was not possible to setup high-level tasks that contained a number of detailed sub-tasks.  I am pleased to say that this has changed in Fogbugz version 7.  The subscase feature allows you to create more detailed (estimatable) cases that roll-up into their parent cases.  I used this feature extensively to end up with a list of about 10 major cases to discuss with management that contained the much more detailed and numerous cases for the developers to estimate.  The EBS algorithm combines the estimate data with historical data on the developer’s estimate accuracy to figure out the probability of completion by certain dates.  Fogbugz will even track the estimated work remaining and probable completion dates as they change and show me the trends.  Version 7 of Fogbugz has a number of other improvements that impact scheduling including dependencies between milestones and the ability to distribute staff resources across multiple projects.
Fogugz continues to include well-designed features for handling support cases, support email and documentation.  The new version has a plug-in architecture and available plug-ins to add features that help with agile development, time reporting, documentation and user stories.  The bottom line is I can now recommend version 7 of Fogbugz as the ideal tool for issue tracking, scheduling and documentation for development teams using almost any methodology.  It is available as a hosted solution ($25/user per month) or for installation ($199/user).  Make sure to check it out.

Open Source and Unreasonable Expectations

I like Sharp Architecture. Anybody who’s glanced at this blog must have spotted this by now. I flirted with the .NET Entity Framework (too much hoo ha in .NET 3.5 and .NET 4.0 not ready yet) and Teleriks’ ORM (not used widely enough for my tastes) before settling on NHibernate. Once I did that, it was pretty easy to decide on using Sharp Architecture since it provided a more or less complete architectural framework built around NHibernate. I started out with pre 1.0 and upgraded to 1.0 when it became available.

I don’t agree with every choice Sharp Architecture made. For example, I prefer the Spark view engine over the standard .NET ASPX engine. I also rather like the xVal client-side validation library. None of this was a problem since I had the source. I modified the original code generation templates to generate Spark views instead of ASPX views. While I was at it, I had them generate the little bit of xVal stuff needed and also gave them the ability to read object properties from my existing database tables. I also had to work through issues related to the new file handling mechanisms in the latest version of the T4 template engine.

Most recently, I wanted to upgrade to the latest version of Fluent NHibernate because it fixed some annoying bugs. I checked with the SharpArch group and discovered it wouldn’t be upgraded for awhile yet. However, someone was kind enough to offer a set of steps for performing the upgrade. Perfect, I thought, and started to work through them. Turned out there were some breaking changes in Fluent that were not mentioned in the steps. No big deal. They got me 90% of the way there. I worked through the rest of the issues one by one and within a couple of hours I had everything working. Thanks again SharpArch community!

The next morning someone posted a question about upgrading to Fluent that I actually knew how to answer. I started to draft up a reply but quickly realized there was too much detail to stick in a post to the group. Instead, I made a long blog post and sent in a reply with a link to the blog. A few questions later I decided to post the upgraded SharpArch binaries as well. Before I knew it, I had spent more time helping others than I had spent upgrading my solution in the first place. Again, no problem. It was the least I could do to start to pay back all the thousands of hours of work that had been contributed by others to make SharpArch possible in the first place.

So what does this experience teach? Well, open source is a community effort. Don’t expect the community to jump in and solve your problems if you are unwilling or unable to take on some of the necessary work. Usually, it took a whole lot more effort than you realize to get the library to its present state and community members will not always have the time or inclination to immediately do what you want them to do. If you are willing to roll up your sleeves, open source does give you the ability to do what you want when you want it since you will always have access to the code. This is rarely the case with commercial products. Finally, when you do add some capability, contribute it back to the community to help make the library better for all.

I like Sharp Architecture.  I flirted with the .NET Entity Framework (too much hoo ha in .NET 3.5 and .NET 4.0 not ready yet) and Teleriks’ ORM (not used widely enough for my tastes) before settling on NHibernate.  Once I did that, it was pretty easy to decide on using Sharp Architecture since it provided a more or less complete architectural framework built around NHibernate.  I started out with pre 1.0 and upgraded to 1.0 when it became available.

I don’t agree with every choice Sharp Architecture made.  For example, I prefer the Spark view engine over the standard .NET ASPX engine.  I also rather like the xVal client-side validation library.  None of this was a problem since I had the source.   I modified the original code generation templates to generate Spark views instead of ASPX views.  While I was at it, I had them generate the little bit of xVal stuff needed and also gave them the ability to read object properties from my existing database tables.  I also had to work through issues related to the new file handling mechanisms in the latest version of the T4 template engine.

Most recently, I wanted to upgrade to the latest version of Fluent NHibernate because it fixed some annoying bugs.  I checked with the SharpArch group and discovered it wouldn’t be upgraded for awhile yet.  However, someone was kind enough to offer a set of steps for performing the upgrade.  Perfect, I thought, and started to work through them.  Turned out there were some breaking changes in Fluent that were not mentioned in the steps.  No big deal.  They got me 90% of the way there.  I worked through the rest of the issues one by one and within a couple of hours I had everything working.  Thanks again SharpArch community!

The next morning someone posted a question about upgrading to Fluent that I actually knew how to answer.  I started to draft up a reply but quickly realized there was too much detail to stick in a post to the group.  Instead, I made a long blog post and sent in a reply with a link to the blog.  A few questions later I decided to post the upgraded SharpArch binaries as well.  Before I knew it, I had spent more time helping others than I had spent upgrading my solution in the first place.  Again, no problem.  It was the least I could do to start to pay back all the thousands of hours of work that had been contributed by others to make SharpArch possible in the first place.

So what does this experience teach?  Well, open source is a community effort.  Don’t expect the community to jump in and solve your problems if you are unwilling or unable to take on some of the necessary work.  Usually, it took a whole lot more effort than you realize to get the library to its present state and community members will not always have the time or inclination to immediately do what you want them to do.  If you are willing to roll up your sleeves, open source does give you the ability to do what you want when you want it since you will always have access to the code.   This is rarely the case with commercial products.  Finally, when you do add some capability, contribute it back to the community to help make the library better for all.

An Open Source Project to Watch

If you use .NET open source libraries in your development, you need to take a look at hornget – The Horn Package Management Project. Its initial goal is to provide a way to download and build popular .NET open source libraries, like Sharp Architecture and NHibernate, automatically resolving all necessary dependencies. The project is in very early stages and very rough around the edges. However, when you consider the couple of hours it takes to do something like upgrading Sharp Architecture to Fluent NHibernate 1.0 (as I did recently), you can see why something like hornget would be quite useful. I certainly intend to keep my eye on this one and, if time permits, at least contribute some testing effort.

If you use .NET open source libraries in your development, you need to take a look at hornget – The Horn Package Management Project.  Its initial goal is to provide a way to download and build popular .NET open source libraries, like Sharp Architecture and NHibernate, automatically resolving all necessary dependencies.  The project is in very early stages and very rough around the edges.  However, when you consider the couple of hours it takes to do something like upgrading Sharp Architecture to Fluent NHibernate 1.0 (as I did recently), you can see why something like hornget would be quite useful.  I certainly intend to keep my eye on this one and, if time permits, at least contribute some testing effort.