Can the software industry learn from the Conservative/LibDem coalition?

During the recent election campaign there was a constant emphasis on how a coalition government would be weak and that the country would be in trouble. The mantra was that the winning party would need a solid majority so that it could be strong, and could force through its agenda for change as written in the manifesto.  

This led me to think about the politics of large software projects. We have all heard of the major disasters on large government IT projects. Could this be in part due to the politicians' often touted strong leadership, which in effect gives them the delusion that they have a mandate even when less than 40% of the voters agree with them?  On an IT project would it be good to only focus on the requirements you like or agree with? Does a forceful product manager guarantee success?  

Could it be that the old style politics is akin to the waterfall development method, and that the new coalition sees the birth of a more agile politics? I cannot say that I have ever really been taken by the more fervent Conservative policies, nor by some of the freakier aspects of Liberal Democrat proposals, but I do find the "merged" agenda strangely appealing.  I did a Google and found this definition ...

Coalition - n.

1. An alliance, especially a temporary one, of people, factions, parties, or nations.

2. A combination into one body; a union.

3. A group of usually two to six male lions that drive off and replace the male lions in a pride in order to mate with the females and protect the resulting offspring.

I like the first definition a lot. In my experience on successful projects you can feel that everyone is pulling in the same direction, you get that vibe, that excitement. In effect it's an alliance - where your differences fall away until the team is all working to achieve the same goal. In fact I have found that it is the very ability to express these differences openly, to discuss them, and then to agree a way forward that makes the project a success. Is there really much difference between collaboration and coalition? 

So maybe the new political arena will remind us that coalition is not a compromise, but in fact is necessary to deliver successfully.  And we should keep that in mind when defining that next piece of software.

Fitnesse is great

If you have seen the films "Meet the Parents" and "Meet the Fokkers" then you will know all about the Circle of Trust.  I have to confess that not many software solutions have made it into mine over the years. However, today I realised that Fitnesse deserves its place.

I know from reading other blogs that a lot of people have a less than happy relationship with Fitnesse, but I have nothing but praise for its ability to deliver automated testing solutions.  One reason maybe that I have not been working to validate simple UI/Web based requirements. My first FIT/Fitnesse project was for a complex FX Order Calculation engine. This we implemented using flow mode and the DO fixture. The final suite included 300+ scenarios and provided coverage for complex business rules for  currencies, fx rates, hedging, trading thresholds, time windows, bank holidays, etc. This code was delivered defect-free through UAT and into production.  Since then I have had other major successes including a complete trade lifecycle regression suite in a message-based environment.

Most recently I have used Fitnesse as a front-end to Selenium to implement a suite of Web-UI smoke tests for our software application.

So why allow Fitnesse into my circle of trust ...

• I have found it to be very flexible
• it has never let me down
• it's implementation is really simple - easy to debug
• it got me into writing some simple Java fixtures (before SLIM I just didn't want to learn about extending classes etc)
• it keeps getting better and better - e.g. scenarios, RESTful commands, JUnit integration
• it helps me to work the way I like to work
• it makes it easier to work with business users and developers
• it encourages the use of appropriate abstractions within the domain
• it is being driven by an active and responsive community
• oh yes, and last but not least it is FREE

If you don't love it then I suspect that the abstraction you are using is either incorrect, or inappropriate for the task at hand. If I find that my test suite is hard to work with then its time to refactor the design to a more appropriate level of abstraction.

What is in a name, a methodology, or a metaphor?

I was reading last night a section in Domain Driven Design by Eric Evans (follow the Links to see more about DDD) with regards to System Metaphors. The idea is that sometimes you can use a familiar metaphor to make a complex domain more accessible. On the flip side the use of an inappropriate metaphor can lead people to apply properties of the metaphor to inappropriate situations.

When I woke up this morning I was struck by some of the poor metaphors that are in common usage in the software development community.

SCRUM

This is supposed to represent different people working together as a unit and moving forwards with a common purpose. In reality isn't a rugby scrum a place of the dark arts, where all sorts of pressure are applied to weaken the opponents, often outside the laws of the game.  It doesn't sound like the environment marketed under the SCRUM process for agile development.

Sprint

A year breaks down into 26 two weekly sprints. Using this sprint metaphor with each iteration equating to a mile of a marathon then the agile team runs at full pelt to deliver the first mile, and then continues to sprint all the other 25 miles, without ever taking a rest.  Doesn't fit very well with the goal of agile development to maintain a constant and sustainable velocity.  Sprinting is hard work and unsustainable due to oxygen debt, so isn't software development sprinting also unsustainable due to the quality debt introduced striving to deliver too early.

Waterfall

If I wanted to generate electricity then I would want a good steady supply of water and if that should be energised by falling under gravity I would be able to generate even more power.  Interesting. In software development of course, a waterfall methodology delivers all the water in one big deluge - which is scheduled for 10:15am on 23rd August say, but may come along later. I defy anyone to explain how this is anything like a waterfall. 

Domain Specific Languages

I am sure if you think about it you can come up with some of your own anomalies. To my mind this re-affirms how important it is to express your requirements clearly using a single domain specific language where all names are explicitly defined. As you can see the software development domain uses some pretty misleading terms, be careful you don't get caught out in your business domain.

Agility Driven Development

• Test Driven Development

Focus on low-level tests to build an automated regression suite demonstrating that "things are still being done right". 

• Value Driven Development
• Behaviour Driven Development
• Acceptance Test Driven Development

The problem with all these conventions is that although they support the idea of testing what the customer wants , e.g. business value, they don't really take into consideration the underlying cost.

If we define Agility as "the Business Value returned per unit cost" - then we can realise:

Agility Driven Development