Tyre Swing and Architectural Artefacts

Using the legendary tree swing cartoon analogy of the IT industry for my own utility...

How does this sort of thing pan out in a naive project environment? (they're not all like this).

1. Analyst sits down with client for a chat about what's needed.


2. A mental picture (right or wrong - let's assume right for now) is formed in his/her head.


3. A blueprint of how it will work is drawn up (only mentally since we reckon the problem is simple enough).


4. A few questions come up when considering this; how heavy the user? how high the tree branch? etc.


5. Solution proposal is verified with client - via a chat over a pint because it's all pretty obvious and he's a mate.


6. Worked out what items are needed (tree, rope, tyre).


7. Worked out how to build it (again, only mentally because it's pretty straight-forward)...


8. Identified where to source the items from - rope from DIY shop, tyre from scrapyard, tree in back-garden (even checked that there was one!).


9. Took client to scrapyard - picked a nice 50s white-walled tyre he liked... (nice team building day-trip out).


10. Built it! Yeay!

All done with no documentation because it's a trivial problem and hell, it worked so let's do it this way everytime... until you write the requirement down...

Requirement: "I want a swing for my 10 yr old child to play on."

Or as a user story: "As a child I want a swing in the garden so that I can play, see how high I can go, get dizzy and feel really funny!"

Or a set of 20 page use case documents (which is wrong in itself).. yawn!

At which point you'll go to Amazon and discover a host of inexpensive off-the-shelf options which are probably better-designed/safer/more-flexible etc. and unless you've a rope, tyre and tree lying around you're probably going to opt for the COTS option.

So it's worth writing it down, just to make sure it's understood, even if it seems obvious. Agile does not mean "no documentation", just "avoid the bloated detailed crap no-one reads and focus on the useful stuff".

Which for me starts with requirements! (functional requirements - a swing! non-functional requirements - for an average weight 10yr old child). It does not take a lot of effort...

But oh wait there's more!... some form of logical design (blueprints), a plan (sources, how to do it), infrastructure requirements (a tree), physical solution (which tree?).

And my favourite hobby-horse this month... traceability from the solution to the requirements to demonstrate why it's the way it is and to confirm it meets the clients needs and expectations. It can even be done in the pub with a whisky chaser!

None of this needs to be written down as reams of verbose documentation, none of this is counter to agile principles. A lot (if not all of it) can be done with a few lists, diagrams and matrices... no Word docs or Powerpoint decks in sight (unless that's the chosen crapware you use to draw diagrams) and you can save the tree if you choose not to print to paper... But all of it needs to be thought about - whether you write it down or not!

I'd still prefer it if you'd use UML though... ;)