Craig and Renee are in Sydney and dangerously podcast after Renee’s one (1) drink and Craig’s two (2) drinks. Along the way they fumble over the following topics:
- Agile Sydney meetup – Agile 101
- Build Your Own Manifesto and Adam Weisbart’s Build Your Own Manifesto (and my Interview with Adam Weisbart at Agile 2012 in case you missed it)
- Wordle – awesome word cloud generation tool
- Agile observations from Dave Thomas (not Dave Thomas)
- YOW! Lambda Jam and Lambda Jam and the buzz around functional programming
- Emergent Design
- Mike Cohn on “Hard to Read Handwriting is Best for User Stories” (and the associated research)
- Craig’s notes from Tech Connect 2013 in Brisbane
- Startup Metrics for Pirates (AARRR)
- When would you pick waterfall over agile (…we think you know the answer!)
- DWP drops agile from flagship government software project
- New book Commitment from Chris Matts and Olav Maassen has been released – a full review coming soon
- Craig has been reading the MEAP of Kanban in Action and Renee is writing her own Agile Forest story
Quotes:
TheAgileRevolution-58 (55 minutes)
The Agile Revolution Podcast 
Hi guys. Listener # 2 here. 😉
A quick point on the emergent design topic: Emergent design is driven by Simple Design (particularly “The Simplest Thing That Can Possibly Work”, “You Ain’t Gonna Need It”, “Don’t Repeat Yourself” and the Single Responsibility Principle), solid testing and “Merciless Refactoring”.
These practices, when taken together, should result in a lot of relatively small classes, each doing one (sometimes two) things, co-operating together. Like Lego blocks, these pieces can then be re-assembled quickly to address new changes – you may need to take some parts out, and replace others, but the rest of the system should remain intact. It’s essentially allowing micro-design (paying attention to individual classes, ensuring that they aren’t getting bloated) to dominate, whilst validating your design decisions as early and often as possible. Thus, the macro-design “emerges” from the interaction of lots of small micro-design choices.
Emergent design requires developers to be regularly scanning their work (with an emphasis on the newer stuff, obviously) to detect patterns, followed by refactoring to remove the duplication in those patterns. From this, application architecture will evolve.
The real test of emergent design is how your design can change to accommodate new or altered requirements – things that you didn’t see coming. Maybe you need to change your persistence backend; maybe you need a mobile client quickly to win a new client; maybe a whole heap of business rules are changing, say due to a regulatory change. If you can make these sort of big changes quickly – in particular, without having to do work not directly related to the change – then you’ve probably doing emergent design right.
Sure, experience helps with emergent design. What doesn’t it help with? But even relative novices can have success by following the principles behind it – because emergent design is about being able to respond to change, including the things you didn’t see coming. I’d even say that they are _more_ likely to succeed with this approach, due to the focus on validation.
Also – why does your theme song at the end include the repeated refrain “Going into debt”?
Reblogged this on Craig Smith.