Yesterday ThoughtWorks held a quarterly briefing in Brisbane for which they shipped out Neal Ford (who I had seen speak at Agile 2008 previously). My notes from the breakfast session are following. I was also lucky enough to get invited to a roundtable lunchtime one-on-one discussion with Neal and a handful of my peers from Brisbane, which provoked some great discussion.

My key takeaways were thinking about design like a lossy compression algoritm (it’s a good analogy about the loss of clarity), the secret to winning Pacman and the insight (from the lunchtime session) that Flickr have got continuous deployment down to 30 minutes (impressive!)

The slides for this session are available on Neal Ford’s website and via Slideshare.

My notes:

• basis for this talk comes from a number of IBM developerWorks articles by same name
• emergent architecture – bad idea, because you need something to build on
• spectrum of design – from waterfall to cowboy hacking, agile design is somewhere in the middle
• big design up front – a bit like trying to reconstruct a picture that has been through lossy compression, you lose the clarity
• emergent design (hardware) – Apple iPod click wheel – refactored, but you had to buy a new ipod to get the updated functionality
• patterns – technical (plumbing) and domain (business logic) – defines abstractions
• avoid abstracting too early – speculation, YAGNI, business changes radically, experience helps to identify these (architects)
• What is Sofware Design? (Jack C. Reeves, 1992) – proves we just reinvent the same thing over and over in software
• final delivery for engineering is a document (because you are designing a bridge, not building it), The design document in software is the complete source code (source == design)
• manufacturing is the build process – in Java/.NET this is free, and happens automatically
• in software, everything is part of the design process – code, test, debug
• software cheap to build but expensive to design

Things that obscure emergent design:

• complexity – essential (inherent) and accidental (we usually take a simple problem and accidentally make it complex) – what we imagine and what results are different (field level security example)
• technical debt – gap between design you imagined and design you got (usually due to schedule pressures), debt is not a bad thing unless it gets out of control, so in software you need to negotiate repayment
• negotiate repayment – hard to convince management, demonstration trumps discussion eg. cyclomatic complexity per tag / branch of code (proved that we made the date but the effect that had on the code)
• genericness- building in layers, just in case

Things that make emergent design easy:

• test driven design – design emerges from tests, undertanding of intent and allows you to measure it, exposes design flaws early and allows refactoring (Neal has a talk specifically on this subject)
• refactoring – encourages collective code ownership, fix broken windows (from “The Pragmatic Programmer“), prudently refactor aggressively (fix small problems at the time they are discovered otherwise create a technical debt backlog – assign a pair that does this for the entire iteration), code should get stronger with age

Metrics

• cyclomatic complexity – measures complexity of function based on branches and decisions
• afferent coupling – how many other classes use this class, shows the centre of the code base – ckjm (Java), showed an example across the Struts codebase
• expressiveness – neads to be readable, comments not executable and always out of date – Java vs Groovy and Ruby example (no closures vs closures)

• abstractions – Pacman example – intelligence built into maze (a large state machine), ghosts use Pacman smell (can’t tell where Pacman is going, only where he has been)
• framework level architecture – you download a library, usually not a single class, JSR294 solves this in Java (have done this with Ivy and Maven previously)
• “architecture is the stuff that is hard to change later” (Martin Fowler see his article “Who Needs An Architect?“)
• politics of architecture (usually because architects are senior), build vs buy (generic software with a few tweaks is usually just a myth because software can provide a strategic advantage)
• design == code, always try to leave decisions until the last responsible moment