I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.


Proceedings of the Nerd Society

I've recently started to attend Extreme Wednesday sessions in the Filmhouse Cafe on Wednesdays. When I got back home after last night's session, Jenny asked how was the "Nerd Club Meeting". Well this is how it went. We had two separate goes at a simple web app to record expenses and payments, based on the spreadsheet I use to track my expenses. There were two pairs: Abdel and Jordon, Andy and I. Colin and John joined later. Getting started - Story Independence Trying to define the stories and acceptance tests was a useful exercise. We had trouble defining tests for "action" stories (eg add expense) without any view stories to verify the action had taken place: we combined an action and view story to get started. Ok, that seems obvious now but I really need to try these things to get a feel for them - reading books (eg Mike Cohn's) is not enough. Upfront Design vs The Simplest thing and Emergent Design Abdel and Jordon invested a small amount of time in defining a domain model. Andy and I had decided to go for what we thought was the simplest thing: a service that interacts directly with the database. We didn't get that for, through spending too much time discussing other things (Andy is so knowlegeable that it'd be a waste not to). Although by the end of the session we both thought our approach was the best - I've changed my mind. We were concentrating on an "enter" action: by the time we'd got to the "query" actions we would have probably needed to introduce some kind of DTO or swap to a domain model; the "simplest thing" was probably (in the end) a domain model. It's dangerous to draw conclusions from simple exercises, but maybe a small amount of upfront design is no bad thing. In reality I find it almost impossible not to think ahead when doing real work. I suppose the key practices are to delay over-commiting to a design until it is tried and proven; even then be prepared to change the design in the face of changing requirements, complexity, and knowledge.

subscribe here subscribe

About me

picture

Conference

RailsConf Europe 2008
Scotland on Rails Organiser

Previous blog posts

Blog archive

Other links: