Agile and mountain climbing

I love agile. I cannot imagine getting software done in a traditional waterfront/BUFD way ever again.

Each sprint or iteration is kind of like making camp at the end of the day as you climb a mountain. However, the mountain does not go on forever (although it probably feels that way). You have to reach the summit one day and declare victory (then move on to another mountain - once you descend, recover and replenish supplies of course).

With agile you end up with a ton of releases accumulating - 1 for the end of each sprint. During the sprints, we pile features and fixes and we pray the documentation and QA can keep up with the pace. These releases are not really intended for external consumption. However, sometimes they may find their way into customers hands. This could happen from time to time.

However, let's consider the scenario where you had reached 8 sprints after a period of ~8 months (assuming 4 week sprints). You now have accumulated 8 releases in your wake. If each of those 8 releases have found their way into different customers hands, you are obliged to support that release. This means you have to consider 8 different upgrade scenarios. You also have to consider 8 x n different compatibility tests where n is the number of components in the product. This becomes un-manageable.

What is the solution? The answer is you have to bake into your release cycle a GA release. How many sprints maketh a GA release? It depends. How often should you do a GA release? It depends. The GA release is where you finally say - yes, we've reached the summit. It's time to put this effort to rest. Time to move on to the next mountain.

Are there any special considerations for the GA release? Yes. The emphasis for the GA release should be all about quality. Often, during the sprint the QA effort is most likely going to be focussed on functional testing. For a GA release, there is so much more testing that needs to be performed.

The GA release is about slowing down the pace of change and allowing the product to bake.

The parallels between Oil and Relational Database Management Systems

We are addicted to Relational Database Management Systems. It's a safe, well-understood mature technology. Whenever we have
persistence requirements, our knee-jerk reaction is typically "let's stick it in a relational database". And why not indeed. It's not
a bad choice, and in some cases it may be your only choice.

Along the way, there have been some contenders to the crown. OODBMS - Object Oriented Database Management Systems spring to mind. But they never really took off, finding themselves pushed into a niche.

It kind of reminds me of our dependence on oil for energy. Instead of OPEC though, we have IBM, Oracle and Microsoft plus
I would include Sun (MySQL). I'd probably get slammed if I didn't include PostgreSQL in the mix too (although I would say this
is probably not high octane).

However, in 2008 things are a little different. There are some worthy alternatives you may want to check out. So what are the alternatives? Well, we have data grids. There are a bunch to chose from. Oracle Coherence is one that I first became familiar
with through my work at Delta (back when it was Tangosol). There are others available too now for both Java and .NET platforms.

Bigtable (http://labs.google.com/papers/bigtable.html) from Google and SimpleDB/S3 are also very interesting alternatives.

Next time you are working on designing a new system, you owe it to yourself to at least check out some alternatives.