Thoughts on Scrum

The project that I'm on is being run as a pure Scrum project. I'm still forming my thoughts, but I think it's still worth sharing my first impressions.

I'm something of a reactionary old architect; I still instinctively like to design a lot up front. I'm fully aware that design still has a part to play in Scrum, but I do feel better with more up-front thought about the problems.

I've been surprised at how heavyweight the Sprint meetings feel (Planning, Review and Retrospective). We were running a 2 week sprint and it felt like we spent far too much time in these meetings, it felt a lot better when we moved to a 3 week sprint.

The Scrum Owner role is critical. He or she needs to keep all the meetings very well focussed. The meetings can become very wasteful if they are allowed to drift.

On this project I've been introduced to Behaviour Driven Development using JBehave and will use BDD on any project that I can as it has made developing and refactoring the system infinitely easier. Being able to form a contract in English with the customer for the functionality and automatically regression test it brings to the integrated system what Unit Testing did for individual classes.

Speaking of Unit Testing, I've been doing purer and purer Test Driven Development. I'm don't think I'll ever be a purist as I find that sometimes you need to do exploratory programming.

I do find it sensible to limit the scope of my firm estimating to just the upcoming Sprint; I'm fed up with being forced to give estimates for a poorly understood system 6 months or a year in advance. I also like the fact that Scrum works so well in the face of changing requirements. There has been no project I've ever worked on without chanign requirements and scope creep and Scrum keeps the effects of those changes very visible to the stakeholders.

As the project moves towards production I'll blog again on how well Scrum has worked.

Rules with Jess

As part of my recent contract with I've been working on a project that is likely to have a large rulebase requiring frequent change. As a result we've decided to use a rules engine to manage them. We won't necessarily be allowing real time changes to rules, but we may well allow some changes between releases.

Jess was selected as it is already used within the organisation. It's not open source but meets the JSR-94 specification. It's based on the Rete algorithm and uses a CLIPS based language to define the rules. (CLIPS is a derivative of LISP so be ready for a lot of brackets...).

I have to say that it has taken me a while to get to grips with Jess as, for whatever reason, I ended up with the work of integrating it with our codebase. Trying to write the rules was incredibly difficult until I had a key realisation: Jess is not object oriented.

In fact the data (facts in Jess-speak) needs to be presented in a relational manner. In effect instead of references you need to create Primary and Foreign keys. Then you can create rules that navigate graphs of facts relatively easily. In effect you can start to leverage your experience with relational databases, the syntax is different but the thinking abou relationships is the same.

Once I had that realisation I produced a set of 'Fact' classes that present the Object Oriented data model in a relational manner. In order to bind the facts I define Jess templates with meaningful names from the 'Fact' classes and then use the Rete.addAsTemplate method to add the objects representing the data as Facts to Jess.

Jess is now much easier to work with.

Winter Recipes

In this weather one's mind turns to good sustaining food so here I present a couple of favourite recipes for this kind of weather. One is a proper recipe, the other is an out and out cheat...

The first recipe is derived from a baked mushroom recipe that I first saw on 'The Victorian Kitchen' cooked by Ruth Mott. Her recipe was simply Portobello mushrooms baked with butter salt and pepper for about 20 or 30 minutes depending on the size of the mushrooms.

Delicious though the recipe was, I thought of a few things that I could add to it.

Robert's Portobello Mushrooms.
Ingredients:

• 4 or 5 large Portobello Mushrooms.
• A cup of pearl barley.
• 2 rashers of back bacon per mushroom.
• A large nob of butter per mushroom plus one.
• Salt & Pepper.

First cook the pearl barley in boiling water for about 45 minutes to an hour (untill cooked and lightly fluffy). Drain and keep the water if you want to make barley water. Pearl Barley once cooked can be kept in the fridge for a few days or even frozen for a few weeks.

Place a baking tray in an oven at 155 - 175 degrees centigrade to pre-heat.

Remove the stalks from the mushrooms trim them and add to a stock pot if you have one available.

Place the mushrooms with their bottoms up so that they then can be filled with the cooked pearl barley. Place a nob of butter on top of the pearl barley filling the mushrooms and season to taste. Be light with the salt as the bacon will add a lot of flavour.

Allowing two rashers of bacon per mushroom, halve the rashers so that you end up with 4 pieces per mushroom. Lay the first two pieces next to each on top of the mushroom. Then at ninety degrees to the first two pieces lay the next two pieces next to each other. You should end up with the pearl barley mostly covered by the bacon. Of course if you have massive mushrooms you may need to use whole rashers to do the covering.

Take the baking tray out and place the extra nob of butter in the bottom, allowing it to melt and cover the base. Place the filled and topped mushrooms carefully in the baking tray and return it to the oven.

Allow to bake for about 40-45 minutes.

Serve and eat...

I like to put the mushrooms in the oven before I go out for a brisk walk outside so I have a hot snack when I get back.

Cheat's Luxury Scotch Broth
This recipe depends entirely on the availability of certain products in the supermarket. Baxter's Scotch Broth is excellent, but is identifiably not a 'home made' Scotch Broth. Waitrose and a few other supermarkets have been selling a range of foods called 'Look What We've Found'. Basically stews, and casseroles in pouches that just need re-heating; the quality is excellent. One of the recipes that they do is 'Herdwick Mutton Stew'. It is delicious, but I find it a little heavy sometimes.

What I do when I'm feeling extremely lazy and want to have a delicious Scotch Broth or to impress someone is mix a pouch of the mutton stew with a can of the Baxter's soup and heat.

You end up what tastes like a brilliant home made Scotch Broth that will serve 2-3 people.

Are We Building a Biplane or a Jumbo Jet?

This is a question that I nowadays find myself asking very frequently; of myself and of my end clients. It's an important question as it frames the scope of the piece of work. The very technical versions of this question ('What percent Disaster Recovery do we need?' or 'What percent up time do we want to guaranteer?') tend to cause non-technical people to boggle and not come up with any useful answers.

My technique nowadays tends to lead people gently into the whole topic.

The analogy of building a Biplane or a Jumbo Jet is a good one and can be extended quite a long way. You can get across the English Channel safely in both, but you could only take a few people in a Biplane and the safety levels are not as good as in a Jumbo. A Jumbo tends to be faster but limited in where it can land, it tends to be more robust but costs much more to build and maintain. I'd happily cross the Atlantic in a Jumbo, but would be much less happy in a Biplane.

Once you've used this analogy to lead the client gently into thinking about the robustness and availability of the system, I then tend to get them thinking about the cost implications of the various levels of Service that the system could be offering. Point out that 99.999% availability would cost several tens of millions and do they really want to spend that much to build a system that would guarantee only a few minutes of downtime in a year? When you frame it that way they tend to become more amenable to 99.9% or less availability. It is also worth coming prepared with the staffing costs for a 24/7 system, they often realise that the system is only needed 5 days a week and for only 12 hours a day...

Until you know the Disaster Recovery and Availability requirements for a system you can't architect or design it. However you must be careful in asking the right questions so that your clients think thoroughly about what they need to be.