Today marks 60 days since I took over the development team for VistaDB.  I just wanted to write up a brief “how are we doing” blog entry.  We have exceeded my expectations in some areas, and failed in others.  But that is to be expected.  The best plans in the world always look great on paper and fall apart 60 seconds after coming into contact with the real world (I always found the phenomenon to be amazing true in the military).

NUnit tests

We started with 0 NUnit or regression tests.  Today we have 298 public NUnit tests, and around 140 private ones.  When we started our code coverage for the tests being used was less than 10% code testing.  Today we cover 51% on daily builds.  The number and breadth of the tests are continuing to increase.  We have found a number of issues that were never reported by users just through the NUnit tests.

The NUnit tests have boosted our stability quite a bit.  There have been no reported regression issues, and they have prevented two issues that I know would have re-appeared if not for the testing in place. Overall they have had exactly the impact that I expected them to have, stabilize the builds, and formalize the testing.  We don’t have as much code coverage as I would like at this point, but we are slowly but surely improving in that area.

8 Releases

That is correct, EIGHT releases in the first 60 days.  Here I think we have done a great job of setting goals, and meeting them.  CLR Procs, CLR Triggers, and Full Text Search (FTS) all done on time.  We had a very aggressive schedule for the first 60 days, but we met all of our goals.  We slipped a few days here and there, but the overall schedule was kept.  I know the entire team is incredibly proud of what they have accomplished. These 8 releases have solved 38 ticketed items, and dozens that were non-ticketed found through NUnit and other testing.  We have also found some specific bottlenecks and solved them, but I would still not consider optimization to have started yet. When I started there was a loose ticketing system in place that was not very effective for tracking update status or knowledge from the customer to the user. 

We now have a FogBugz system in place to provide more formalized bug tracking and reporting.  All users may submit tickets and then receive all their updates through email.  To update a ticket, you only have to respond to the original email.  This keeps all our communication between the team and customers in a single location.  The development team has expressed how much they like being able to come in to a ticket and look at the history of what steps have been tried. A few things that have not made it in yet are the check for updates application, and integrated F1 help in VS 2005.  And while the documentation has come a long ways, it is still not where I want it.  There is just so much to the system to document!  But, I am committed to getting it all down in the help files.  I am just taking a little piece each day.  I don’t anticipate that we will ever truly be done with the docs.  There will always be a new HOWTO, or examples to be added.  I think that is the approach we have to take; documentation is packaged and shipped on a schedule just like the code.  It is not an afterthought, it is a part of the project to be managed and maintained just like the code.

Release schedules

Where do we go from here?  The roadmap has been updated with our schedule for the next 60 days.  I am planning to keep looking about 8 weeks in advance for release scheduling.  I feel this is close enough to be realistic and keep us tightly focused on deliverables.  We have some updates to FTS for compliance with MS SQL, and some other MS TSQL functions where we are not in line with how they do things.  But the majority of the upcoming schedule is for optimizations. We will also be planning the 3.1 release and staking out what the API changes will consist of and how we want to implement them.  The 3.1 release will be our first new significant release since the 3.0 rollout.  The 3.1 API changes have to be well documented and in place before we ship the system.

Dog Food Update

Things are going well on the Dog Food front.  We now have two systems in place that use the VDB3 engine for production usage.  The trial user contact and update systems.  At Emerald we have not made as much progress as I had hoped.  There have been a number of non-VistaDB related issues that have impacted the move to VDB3, but there is progress.  I am hopeful that the web crawler and reporting systems will be moved over the VDB3 in the next month.  The main Emerald customer management and billing system is a huge chunk of systems that all talk to VDB2 systems right now.  Moving all of them is almost a total rewrite due to the API changes from VDB2 to VDB3.  I am hoping that the 3.1 API changes will bring us closer to the older API model to make porting easier.  I am also thinking about writing a porting guide for recommendations of how to port VDB2 code to VDB3.

How are we doing?

I will open a topic in the boards pointing to this post, and posing the question: 

• How are we doing for you?
• Are things stabilizing for your usage of VDB3? 
• Do you feel we are moving in the right direction? 
• Like / Dislike the subscription model?