Recipe for Disaster - Naming a Release after a Feature

by jmorris 8. October 2009 22:22

Note: This post was motivated by a 3 hour discussion with a release manager regarding why the name of the release was the same as a feature that we had pushed to a future release – “If feature x has moved to release y, why are we still releasing a build called feature x."

Why? Simple, it holds you and/or the team accountable for releasing the feature in that release on the planned date. This doesn't sound so bad one would think. After all, the feature was conceived hopefully from some end user or business need, feasibility was assessed, and the sprint was planned with dates engraved in stone. The reality is that while LOE can be estimated, there are additional factors at hand that wreck havoc on what will be completed by the cut-off date.

Typically, common cause variance can be mitigated and the estimate included in the original LOE, however the same cannot be said for special case variance.  For example, you can pretty much assume that a certain amount of effort will be attributed to research and discovery, before the developer even starts working on the task or feature. While in the exceptional case a developer may have sufficient domain experience to simply start coding a whip out the feature, the rule is that the developer will have to spend time familiarizing them with the environment, before jumping in. This is expected to cause a certain amount of containable variance with respect to a project or sprint. However, how do you reasonable plan the case where another developer on the team contacts some grave illness, such as swine flu and is not available and reduces the number of resources available?

In cases such as this, we simple do not plan for these special cases, because it is virtually impossible. If you did try to plan for them, you would never finish planning because there are an infinite number of things that can happen. It costs too much to plan for these types of things!

Back to my original point, when you name a release after a feature you commit yourselves to completing that feature and releasing it on the planned date, however you omit the possibility of special case variance affecting the outcome. In which case you still want to release something so maybe you release another, less resource feature; but the release is named after the feature that was omitted…this is awkward (especially for the build engineer).

You will communicate your intentions better (i.e. the goal is a release, not necessarily the release of a specific feature) if you name the release after some arbitrary name not tied in directly to a feature.

Tags: , ,

FragileUnit Tests and External Dependencies

by jmorris 6. October 2009 23:42

An example of why unit tests that depend upon external resources, such as databases are fragile:

And the code that is breaking:

Reason: article was versioned repeatedly in the UI after this unit test was created...noise.

Tags: , ,

Updating Records With Randomly Selected Values - SQL Server

by jmorris 4. October 2009 05:40
It turns out that selecting random values from a table column and updating or inserting them into another table is trickier than I imagined. For example, the following SQL snippet seems to work, but it will always assign the first random value to

Tags:

Jeff Morris

Tag cloud

Month List

Page List