Skip to main content

Tyre Swing and Architectural Artefacts

Screen Shot 2014-11-04 at 21.47.41

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... ;)



Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.