A while back I tweeted about critical mass of software:

Critical Mass of Code - past which the changeability of the code is infeasible, requiring that it be completely rewritten.

An elaboration of this might be:

Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.

This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):

In a previous rant about the misuse of the term mitigate in the context of risk management I listed the following strategies (I call them MARTA) for managing a given risk:

• Mitigate - Reduce the severity of its impact
• Avoid - Don't do the thing that makes the risk possible
• Reduce - Make the risk less likely to happen
• Transfer - Move the impact of the problem to another party (e.g. insure such as paid insurance or outsource with penalties for failure)
• Accept - Do nothing or set aside budget to cope with the impact

I recently found myself having to explain this and used the analogy of crossing a busy road with fast-moving cars. What's the risk? Well, you might get hit by a car.

This weekend I attended CITCON Paris 2009 with my friend and business partner Andy Palmer. It was a fantastic event, although next time I think I'll volunteer fewer sessions. Andy and I found ourselves playing a major role in most of the sessions we attended which was absolutely exhausting!

Update: The 'new' WebUser's name has been changed to ScreenPlay4j. All rererences to the new WebUser below should be taken as 'User'.

At the first Agile Alliance Functional Test Tools workshop, I briefly showed a spike I'd done that illustrated how straight forward it would be to write acceptance tests in code. It was somewhat inspired by work already done on things like JBehave and RSpec. However, while they moved further away from code and towards plain text, I went in the opposite direction.

The FitNesse Narratives project that I've been working on along with Andy Palmer, has reached a major milestone - our first story is functionally complete. We're finishing off some refactoring and need to automate the build but once those things are in place our 'Iteration 0' Story will be done.

I thought that you'd like a preview of the NarrativeFixture, the star of this story, so you can start to see where we are going. You'll be able to get your hands on it and use it yourself soon enough.

Yes, that's right... I'm giving a public course in Agile Testing (or Agile QA as some might call it) on Thursday 9th July in London with Rachel Davies and in association with SkillsMatter.

We cover everything from Agile fundamentals through to Acceptance Test Driven Development and Behaviour Driven Development.

I frequently encounter people who tell me of risk management courses that they've been on and tell me of four (straight from Wikipedia) strategies for addressing a risk::

• Avoidance (eliminate)
• Reduction (mitigate)
• Transfer (outsource or insure)
• Retention (accept and budget)

I'm no risk management expert, but I've certainly got plenty of experience in it. I am a lover of language and words and immediately notice one small problem with this model - the use of the word "Mitigate".

"Mitigate" is a commonly misunderstood word. Many use it as a synonym for "reduce" but it actually has a special meaning:

to make something less harmful, unpleasant or bad -Cambridge Dictionary