The chart to the left represents the Burn Down chart for the Secret Server 4.1 release which shipped on March 14th 2008.  We have always shipped Secret Server on the published date (or in the early hours of morning the next day!) but this release pushed things a little too close for our liking.  What was the problem?  Did we take on too much?  Did we trade off scope like we are supposed to?

Looking at the Burn Down we can see that our velocity was really low in the early stages of the release.  This was mostly due to some support issues that drained our development resources and also some staff shuffling on projects which lead to inefficiencies.  We were able to make up for this with a phenomenal increase in velocity in the final iterations.  Unfortunately this was achieved by using more team resources to accomplish the tasks.  While the increased velocity is good, it also means there was a greater rate of change in the codebase at a point where quality assurance was trying to stabilize the product.  Test Driven Development certainly helps by allowing us to lean on our regression suite of tests but it is still not ideal.

So what went wrong?  We will be having a recap meeting later this week to determine how to improve our planning for future releases. We need to get back on track to our usual release schedule where we are ready for the actual release days before the release date (not bad for a small team with frequent releases!).  I think part of the problem was not planning properly for reducing scope.  We left one of the larger features of the release until the end (the Role Based Security feature) - then we didn't recognize that this feature could be thinned out to reduce scope but rather implemented most of the originally specified functionality. 

Typically our team cannot easily change resources (cost) since most team members are committed to projects and cannot easily shift responsibilities.  We also can't change the date since customers are expecting a release on a particular date because sales and support have been giving this date out for a few weeks.  This only leaves scope as the final equalizer to make timely releases possible.  In future, we will need to be more careful to ensure that scope can always still be reduced if necessary.

What does your Burn Down Chart tell you?

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products? 
Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com.

.NET 2.0 introduced a check for FIPS certified algorithms if your local security policy was configured to require them.  This resulted in algorithms which are not FIPS compliant (or implementations which were not FIPS certified) throwing an InvalidOperationException from their constructors.

In some cases this isn't a desirable behavior.  For instance, some applications need to use the MD5 hashing algorithm for compatibility with an older communication protocol or file format.  Prior to .NET 3.5, the AES algorithm was only available in an implementation which was not FIPS certified, and if you needed to use that algorithm the FIPS check could also block you.

To help these cases, we added a configuration file switch to .NET 2.0 SP 1 (and therefore .NET 3.5) which allows an application to say "I know what I'm doing, please don't enforce FIPS for me".  For these applications, they can setup a configuration file similar to:

<configuration>

    <runtime>

        <enforceFIPSPolicy enabled="false"/>

    </runtime>

</configuration>

Which will prevent the CLR from throwing InvalidOperationExceptions from the constructor of uncertified algorithms and implementations.

A very good and easy-to-read article about loosely coupled design, Dependency Inversion and Inversion of Control (IoC).

http://msdn2.microsoft.com/en-us/magazine/cc337885.aspx

I was catching up with some of the people I follow on Twitter tonight (as a side note, I used to think Twitter was a waste of time but I'm actually finding it useful now days) and noticed that Scott Cate listed a link to a free tool called LINQPad.  Wow...I wish I would've known about this tool a few months back when I was working on different LINQ queries for an application.  It really simplifies building queries and also happens to be a great way to learn the LINQ syntax as well.  It was created by Joseph Albahari for the C# 3.0 in a Nutshell book.

Here's a screenshot from the Website.  You can download LINQPad at http://www.linqpad.net.  I'm really impressed with it so far. 

On a related note, if you're interested in seeing how LINQ, Lambdas and LINQ with Stored procedures can be used, you can download the sample ASP.NET 3.5 application I put together that will help get you started with the different options available in .NET 3.5.

Want to know how C# evolved through the years? Here's a fascinating chronology and also some predictions for the future.

Check it out.

http://msmvps.com/blogs/jon.skeet/archive/2008/02/05/c-4-part-1-looking-back-at-the-past.aspx

I´m writing some posts about Commerce Server 2007, involving development, costs, administration, learning, and so on, at andrenobre.wordpress.com. I´ll translate it and put it here ASAP :)