Axiom – a framework for sanity in Software Development

After many years of suffering from the slavish insistence on adherence to whatever development methodology was prescribed ( or in fashion) at the time, I’ve come up with a framework to apply to these methodologies.

The idea behind this is to :-

• avoid cutting down any more rainforest for use in utterly pointless documentation
• avoid fatally compromising application design due to the constraints imposed by the methodology
• state the blindingly obvious for the obviously blind

Software development is a fundamentally simple process, perhaps most succinctly described by Dan Gookin in C for Dummies which, paraphrased, is something like

• Come up with an idea for a program
• Write the program
• Curse the compiler for it’s cryptic errors
• fix (repeat previous step)
• Finish program
• Go to the pub.

OK, the last step is mine, but you get the idea.

Incidentally, his tips on passing as a C programmer included being able to quote spontaneously from Monty Python’s Holy Grail. This proved to be uncannily accurate ( although on this side of the Atlantic, The Life of Brian seemed to be rather more prevalent).

On the remote chance he’s reading this, I’d just like to say to him – “Nice one Centurion !”

Anyway – here it is – Axiom – 8 golden rules to apply to whatever bloated or crazy methodolgy you’re tied to :-

RULE 1 – Do what works

Pragmatism is the watchword here.

If the program spec is part of the deliverables and is required for ongoing support ( a bit of a joke, but some methodologies insist this is so) it could make more sense to write it after you’ve written the code. That way, at least it’ll describe what the code actually does.

Of course, you still need something to code to. In my experience a quick and dirty “fag-packet” spec ( i.e. written on the back of a fag-packet) can suffice for this purpose and be tossed once you’re done.

If you don’t need a full-blown technical spec before you start coding, then don’t do one.

RULE 2 – Before starting – be clear on the user requirements and Project Deliverables

It’s pretty important to have a clear picture of the business process(es) the application is required to support.

It’s an outstandingly good idea to know what the requirements are and to have them signed off in blood ( preferably someone else’s).

I’ve lost count of the number of times that projects have gone over time and over budget due to last-minute changes to requirements, usually as the result of not waiting for requirements to be finalised before starting to code.

The argument for doing this is that the requirements sign-off process is usually rather laborious – so many signatures are required that the requirements document spends an inordinate length of time being reviewed and re-issued with – generally – minor changes. Then suddenly, someone will come up with something fairly fundamental and you have to unpick large chunks of what you’ve done to that point.

At this point, I’m sure that any members of the Church of Agile will be smiling smugly to themselves. However, I have worked on at least one Agile project that suffered this affliction shortly before development was due to complete and suffered significantly as a result.

RULE 3 – Before starting – be clear on the context in which the application will be used

It’s a good idea to know what the usage volumes are likely to be and what existing processes/applications are you going to need to interface to.

What’s the hardware/software architecture ? Are you likely to beef it up to handle the new application/functionality/ load ?

RULE 4 – Pick the right technology for the job

Just because all the cool kids are using it, doesn’t necessarily mean that it’s here to stay, or that it’ll do what you need it to do.

Equally, just because it’s what you use now and have done for the last 10 years doesn’t make it the right choice.

You also need to give careful consideration to issues such as :-

• vendor tie-in
• recoverability of the entire application architecture
• whether the swish new tool your using will continue to be supported against the next RDBMS/Application Server/Java version that you’ll need for another architecture component.

This is especially important if you’re working in an environment where the phrase “Best of Breed” gets used a lot.

From my limited understanding, the etymology of this phrase seems to have it’s root in the world of animal shows – Crufts in particular.

It is therefore, not entirely surprising, that this approach  so often results in a dog’s breakfast.

RULE 5 – Agree and enforce coding AND commenting standards

Whatever technology you’re using, standards are there for the protection of the poor souls who’ll have to maintain the application once the development team have done their worst and the Application is in production. In many places, the development team will – at least partly – be required to perform this role. Therefore, it’s probably worth noting that, as a developer, standards are there for YOUR future protection and happiness.

RULE 6 – Test for functionality AND performance

Another one of those dreaded phrases that occasionally surfaces is “Live Proving” .

Roughly translated, this means “let’s just throw it into production and see what happens”.

The results are often hilarious…from a distance.

More common is that the need to test functionality is recognised, but tightening time scales result in the time allocated for testing being squeezed. The end result is usually that, whilst most of the functionality is tested, at least to an extent, the more tricky/expensive/time-consuming issue of performance and load testing tends to fall by the wayside.

Once again, we’re back to the Live Proving stage ( more accurately known as “suck it and see”), with the risk that your application is going to keel over slowly but inexorably like the statue of a deposed dictator.

RULE 7 – Ensure that the application is sufficiently documented

Users need to know how to use it

Support need to know how it all hangs together, and what you meant it to do.

Post rollout maintainability is considerably enhanced if code is adequately commented.

Taking a packaged procedure for example. Header comments describing the values required for each parameter ( possibly including where they come from); the functionality being implemented by the procedure, and – if relevant – where it is usually called from, provides a context for the poor put-upon Support Team before they have to start looking through any of the actual code.

RULE 8 – There are exceptions to EVERY rule

I’m tempted to say here that you should never trust an argument that starts with the word “always” or the word “never” – but that would just make me look silly 🙂

On a more serious note, the number of times I’ve seen projects fall victim to technological fundamentalism – “you can’t use an implicit cursor/trigger/Javascript because it’s evil” or, notably “you can’t write a spec for that bit of the system because that’s not Agile” would tend to re-enforce RULE 1.

As you can probably gather reading this, I could go on. Indeed, I probably already have.

Comments/arguments/fatwas welcome.