goto; Aarhus 2011 – Day 3

The final day of the conference kicked off with a great keynote, and my favourite presentation of the conference in the afternoon – Linda Risingsadly I had to leave early to catch my flight home so missed seeing my ex-ThoughtWorks colleague Alistair Jones speaking.

Keynote: Applying Design Thinking and Complexity theory in Agile Organisations

Jean Tabaka began her keynote with a story of trying to produce an agile cookbook to help a company implement Agile. She used complexity theory to explain why this approach is doomed to failure: most organisational environments are complex, the same actions do not always produce the same results, so we must look for emergent practices instead. She emphasised looking for resilience over robustness, and effectiveness over efficiency, and suggested that we can use design thinking techniques to help.

Architect track: Seven secrets every architect should know

Frank Buschmann talked about the importance of architects staying involved with the development teams they represent, and emphasised that architecture needs to be designed for understanding and maintenance, as well as to support the key system functions. He suggested that an architect’s job includes implementing a walk skeleton of the architecture, end-to-end, to prove it works well, and that they should continue to work closely with developers, pairing and writing code, while still maintaining a view across the system. I particularly liked his description of an architect as “the eye of Sauron”!

Java: Titanic, COBOL and the 100 year platform

Ola Bini kicked off with a check for any attendees from Oracle, luckily there were no takers. For the first part of his talk, he discussed the key attributes that a platform needs to support to take it into the future now, including lightweight threads (fibres). For the second, non-technical section, Ola described some of the processes by which Java and the JVM are updated, and how implementations like Apache Harmony are unable to be licensed for certain uses – the basis of Oracle’s lawsuit against Google. He lamented the lack of openness around much of the work Oracle have done and are doing with Java and the JVM, and speculated as to whether this may hurt the platform. With Java 7 out, Java 8 delayed until 2013 and discussion already going on around Java 9, he discussed some of the upcoming changes such as the introduction of the lambda.

Tools and Performance track: Personal Kanban

Troels Richter declared at the start of his talk that his goal is for us to want to try his Personal Kanban technique, and it only took less than half the talk for me to want to give it a go! He used his own web based Kanban board to demonstrate how he first visualised his own workflow (backlog, this week, today, pomodoro, waiting for feedback, evaluation, done) and then applied work in progress limits – which, interestingly, he’s breaking. The evaluation stage is interesting: here he asks what value the activity had and whether it helps to meet core goals or values. The Kanban board the Troels used was online at kanbana.com.

Tools and Performance track: Coffee, Tea or Agile?

We now sleep less and use caffeine to wake us up in the belief that this is the way to be more productive. Linda Rising suggested that these habits date back to the industrial age and factory workers, but ultimately the effects of caffeine can be more harmful than good. My personal favourite slide of the conference was Spiders on Drugs, when she asked: would you want the spider on caffeine writing your software? Looking at the mess it had made of it’s web is almost enough to put me off tea! Our bodies have a natural rhythm, maybe we should start listening to it, taking regular breaks – even naps – to maintain productivity and focus.

Tools and Performance track: Lightning talks

First up: Ola Bini charged through 28 slides and two demos in eight minutes, all in an attempt to convince us of the general awesomeness of Emacs.

Tudor Girba talked about the search for innovation, and how we can examine our own wrong assumptions by presenting to others, demonstrating our ideas, and looking for challenges to them.

Fred George presented on how we can remove things that kill productivity from our culture – in particular, fear of failure, and extra roles that create the need for more meetings to transfer knowledge.

Martin Thompson said that in software, we sculpt models. It’s art, which is better when it’s minimal and not overdone. If we get too hung up on what we have, we don’t learn – we need to refine and change the models in our software, while keeping their identities the same.

Kevlin Henney described the link between productivity, personal effectiveness and happiness. By taking up street photography, he sharpened his senses, increased patience and creativity, which brings benefits to work as well as his personal life.

goto; Aarhus 2011 – Day 2

Day 2 of the conference, and after last night’s conference party there are a few sore heads and yawns. With user groups taking up part of the afternoon, it was a slightly shorter day, but still plenty of good sessions and chat in between.

Agile at mid-life track: Fractal TDD

Steve Freeman talked about how We can use tests to help us identify places in our system that need to be refactored, in particular where we may want to begin pulling out new classes to take care of things like logging. He presented many examples of code before and after refactoring, so that it was clear how the changes could make the code clearer and neater. Many of the changes introduced for tests also had uses and benefits in production. He also described common unit test smells: too many assertions, magic set ups and long, long tests with an unclear purpose.

Technologies and Tools: Programmer Anarchy

As so many of my ex-colleagues work at Forward, I wanted to see what all the fuss was about, and Fred George didn’t disappoint! He described their working environment with a high level of trust both within the development team and between them and the business. One of the interesting points for me was how all of the applications are tiny, just a few hundred lines each. Instead of creating one monstrous codebase, each application just does one thing and does it well – like store data, or produce one report. This also means they can use the best technology for each part, and they use a wide variety including hadoop, clojure and Ruby. It certainly sounds like a programmer’s paradise.

Agile at mid-life track: Beyond Retrospectives

Linda Rising reminded us all of the importance of retrospectives as a driver for change, rather than a whinging session. She suggested at the next stage beyond retrospectives is continuous feedback: why not have a real time timeline in the team area? Some other things we can all try: take five minutes at the end of every day to reflect on the small wins of the day, experimenting with one or two new practices every day, making all meetings stand ups or even standing up to work (moving more keeps us healthier and happier).

Agile at mid-life track: Measuring Progress and Performance in Large Agile Developments

Andy Carmichael described his role as a lead scrum master across about a dozen scrum teams, out of a total of a hundred. He acknowledged the management attitudes that make it difficult to run agile in large, waterfall organisations, such as wanting to harass the team (sorry, “give them a pep talk”) when it doesn’t look like velocity is high enough. It’s not easy to move management away from the belief that the guys doing the (shortened) upfront planning are “all knowing” when it comes to estimating large projects accurately, and towards considering how to change the plan when things go wrong. The metrics were detailed and I can think of many managers I’ve worked with and for who would love this kind of visibility, but I can’t help thinking it moves the focus away from trust and empowerment.

goto; Aarhus 2011 – Day 1

It’s been a pretty awesome first day at goto; in Aarhus – after the first keynote, I found myself gravitating towards the DevOps sessions, which were really interesting. The .NET track was also good, and I was sorry to miss Rebecca Parsons – whose idea was it to put both Rebecca and Jez on at the same time?!

Keynote: Dart

Lars Bak and Gilad Bracha present a technology preview of Dart, a new language for programming on the web. Syntactically, it looks a bit like a cross between C# and JavaScript – which is unsurprising as there was a deliberate attempt to keep the syntax familiar. Types are optional and type errors don’t prevent the program running, instead the type checker is designed to help the programmer. The code compiles into JavaScript to run in the browser, and in future we may see support added to Google Chrome. My first impression was that it looks like it’d be pretty cool to work with, so excited to have a go.

They presented a news reader and a cool clock project running in the browser, both written in Dart.

More info: Tutorials and language specification, open source project

.NET track: Conventions – make your code consistent

Mark Seeman presented an interesting and very technical talk, using dependency injection with Castle Windsor as an example of where we can introduce conventions to reduce the amount of code we need, therefore making the code more maintainable. He used a series of well prepared code examples, also demonstrating the app working, to make his points. By describing the conventions we want to use within the code itself. Enabling conventions make it more straightforward to extend the code using the conventions, restraining conventions such as unit tests ensure developers are following the conventions in place. Mark presented an interesting example of a unit test used to prevent references to the DI container popping up in any assembly except the outermost one.

Mark’s code on github

DevOps Track: Evolving Continuous Delivery

Like all of his DRW colleagues I’ve heard speak or follow, Chris Read succeeds in making me quite jealous when he describes their working environment, with clients sitting next to developers, and happy to accept a higher level of production bugs than most places I’ve ever worked! This acceptance of risk means that they are able to push out changes within 30 minutes of writing the code – on average. What I liked the most about Chris’ talk was the message that the things we’re told when we start doing agile – continuous integration is important, automate tests – still hold, but the implementation of them varies greatly. Just like with agile practices, how we manage continuous delivery must also vary to suit the team.

DevOps Track: Scaling DevOps

Jez Humble’s talk was polished and engaging, covering the need to bring ops and development together in large organisations in order to deliver better quality software, faster – which is of course what he’s best known for writing and speaking about! The two key insights for me were that reducing the cycle time will mean people are less than 100% utilised (and conversely, aiming for 100% utilisation increases cycle time), and that deployment pipelines can actually be a great tool for helping audit software delivery, possibly for SOX or ITIL compliance. I only wish that more companies grasped these concepts from the top, and used them to manage projects.

DevOps Track: DevOps Fools, Tools, and other smart things

Patrick Debois’ talk was focussed on how tools can help us to change our ways of thinking, and cultures. He talked how tools can encourage about collaboration and how two people from different backgrounds, like development and operations, can combine to make “creative chaos” – and that may not see the benefit of collaboration until we look around to see its effects. He emphasised that we should use tools to find new ways of working – be creative and look under the hood. If a tool only has one way of using it, that’s a problem – given an API, we can find new ways to innovate with the tools we have.

.NET track: Developers have a mental disorder

Greg Young was loud and entertaining, the perfect talk for nearly the end of the day. Taking the view that abstraction is “programmer porn” and developers love to solve problems that nobody actually has, with abstract solutions, he tore holes in many common development practices. A couple of things that made me think: it’s easy to measure DRY, but the flip side of removing duplication (coupling and complexity) is much harder to measure, so we optimise for DRY. Many tools take away the pain we cause ourselves by writing bad code, making it much easier to do just that. Most complicated problems can be worked around without the tools. Many of his observations had me laughing, or groaning in recognition, but I still have no idea how to convince others of the truth behind them.

Keynote: Cool Code

In other careers, like writing for example, we would look at other people’s work, particularly good examples of it. Kevlin Henney suggested we should do the same for code, and produced many examples of “beautiful” code. Some is literally beautiful, like the C program that depicts a part of the globe – and when run, outputs itself with a 45 degree movement. Another example was the chess program as long as 4.8 tweets. Some of the best code will never be used in enterprise applications, but it’s ingenuity and sometimes sheer playfulness makes it provocative.

Running JSLint with Node

As part of some recent work on an open source project, I’ve been tinkering with node.js. When starting a new javascript project, I like to set up tools like JS Lint early on, since fixing lots of errors later is tedious. I wanted a simple script to run it within node – searching the interwebz revealed a couple of options to run on a single file, so I adapted a couple to do what I wanted.

The result is on github and below – I added just one line to the Crockford script:

exports.JSLINT = JSLINT;

The jslint-runner file sets up options and hooks into node, then loops through all the files in a directory and lints them one by one. It’s not recursive (I didn’t want it to be) but that could be easily added in. The predefinitions include jasmine keywords.


var options = {
    node: true,
    predef: [
            "jasmine",
            "describe",
            "it",
            "expect",
            "beforeEach"
    ]
};

var ANSIColors = {
  pass:    function() { return '\033[32m'; }, // Green
  fail:    function() { return '\033[31m'; }, // Red
  neutral: function() { return '\033[0m';  }  // Normal
};

var stringWithColor = function(str, color) {
    return (color || ANSIColors.neutral()) + str + ANSIColors.neutral();
  }

var fs = require('fs'),
        sys = require('sys'),
        dirName = process.argv[2],
        readFile = function (name) {
            return fs.readFileSync(name).toString();
        },
        print = function (message) {
            sys.puts(message);
        },
        quit = function (code) {
            process.exit(code)
        },
        jslint = require('./jslint');


if (!dirName) {
    print("Usage: jslint.js directory");
    quit(1);
}

fs.readdir(process.cwd() + "/" + dirName, function(err, list) {
    list.forEach(function (file) {
        var fileExtension = file.substr(file.length - 3);
        if (fileExtension === ".js") {
            doLint(dirName + "/" + file);
        }
    });
});

var doLint = function(fileName) {
    var e,i,input;
    input = readFile(fileName);
    if (!input) {
        print(stringWithColor("jslint: Couldn't open file '" + fileName + "'.", ANSIColors.fail()));
        quit(1);
    }
    if (!jslint.JSLINT(input, options)) {
        print(stringWithColor("Problems in " + fileName, ANSIColors.fail()));
        for (i = 0; i < jslint.JSLINT.errors.length; i += 1) {
            e = jslint.JSLINT.errors[i];
            if (e) {
                print('Lint at line ' + e.line + ' character ' +
                        e.character + ': ' + e.reason);
                print((e.evidence || '').replace(/^\s*(\S*(\s+\S+)*)\s*$/, "$1"));
                print('');
            }
        }
    } else {
        print(stringWithColor("jslint: No problems found in " + fileName, ANSIColors.pass()));
    }
};


Whoops!

In the middle of a busy summer that involved moving out of my flat in London, trying to plan a move to Australia, and taking in an obscene amount of beer and comedy at the Edinburgh Festival, I lost my blog. But it’s coming back, shortly.

Apologies to my (very few) commenters, I don’t think I can restore those. However, I do plan to restore some very old posts from my original Spike the Poodle blog, tales from my very first steps with Scrum, so that might be fun. There, I’ve said it. Now I have to do it.

Incorporating Usability

In my quest to incorporate usability into our Scrum model in an agile way, I came across this article on Agile Usability.

It advocates drawing the design on paper to hammer out the big concepts, and running a heuristic analysis with several usability experts to uncover any major design flaws. The designer and developer then pair program to create the interface. Once a prototype is created, perform small scale usability testing. The requirements can then be adjusted. It also points out that Usability experts can help break down the items on the product backlog.

For us, the concept of having usability break down the product backlog is something we are already starting to do, and definitely something I want to continue. The idea of having our designer pair program with a developer to create a design is interesting. I wonder how he’d feel without Photoshop?? The rest of the cycle makes pretty good sense, isn’t that far from what we did this Sprint and seems like a good way to play once the team is all in London (until then, if we can’t be perfectly agile, I’m happy to live with it!)

I’m still researching, but this one was worth highlighting.

Launch48, round 2. This time, it’s different.

This time, I know what to expect. I’m not pitching. I’m not project managing. I’m coding, and this time, I want to finish something.

Friday Evening

I’m stuck in traffic on the Putney Bridge, while somewhere in the depths of Kingston University, Ian is tutting and wondering why I haven’t arrived yet. Hours later, it seems, I nearly give up after wandering the empty halls fruitlessly trying to find a group of would-be entrepreneurs. Finally, a couple of lecturers point me in the direction of voices and I breathe a sigh of relief that I have just about managed to catch the last of the pitches.

None of the ideas scream out to me, but some spark an interest: a diet and exercise website, a specialist food store building on the Tesco API, and fashion website Look Book.

Second round: Joe jumps up to present mobile spy game Espionage, which is one of the winners alongside Look Book and group travel planning site Trips Together. He’s energetic and fun, and despite not being a gamer I am drawn to work with his team. We’re going to allow people to create secret agencies with their friends, and score hits for targeting their enemies. Good old passive aggressive fun.

Our team includes developer Michael, designer Bruno and front-end developer Richard as well as the usual marketing and business junkies – in this case: Joe, James, Jonny and Nick. We have a good mix of skills, and to my delight the team are in eager agreement to keep things small and simple.

We discuss technologies, and Joe’s eyes glaze over slightly, but he’s excited that we have something resembling a plan.

I go home inspired, and spend a few hours tinkering with Appcelerator and PhoneGap to get a basic Android application running. It’s way past bedtime, but sleep seems far away as the ideas keep flittering through my head … need … to … code …

Saturday morning

Junk food, it seems, is the theme for today: our team have a stack of chocolate biscuits and Haribo which Trips Together put to shame with their crisp mountain.

My first task for Saturday morning is to get the map up and running, but despite being from the same company, Google maps doesn’t want to run on the Android emulator. iOS seems happier with it, so I switch to iPhone, and by the time the first board meeting comes around I’m happily in the zone. I skip the opportunity to be distracted and hounded by the mean mentors (no offence, Ian) and remain at my laptop.

By lunchtime on Saturday, I have a working map with some fake friendlies and enemies appearing on it, and I can tap a target to make a hit. Bruno is producing slick designs and Richard is working on the styling. It’s like a dream come true, all I need to do is the fun stuff of making it work, and they make it look amazing.

Mentors stop by occasionally, I ignore them. I’m not here to start a business, I want to hack something together and I’m loving this team atmosphere.

By mid-afternoon, we’re in a position to pick a few features to focus on for Sunday. The app is working but isn’t very inspiring, so we decide to make improvements to the game play, including a revolving target area on the map.

I go back to my laptop and realise I have no idea how to calculate points on a circle, a quick google search reveals it involves some kind of trigonometry … I dredge my mind to recall lessons from secondary school maths, but it’s too deeply buried. Thank God for the interwebs though: I find that somebody has already done it and we’re moving forward again.

One topic for the second board meeting is technical strategy, so I reluctantly tag along. I should have known better: this is of course the point where the mentors flex their muscle, and we are no exception. Angry Bird Julien Fourgeaud questions why we have chosen the technically difficult route of creating a location based app rather than a website, and lectures us on building a decent user base.

I’m not too concerned since the app is built using web technologies anyway, but Julien is on a roll and declares that with the Rovio user base, he could easily take us out. Joe stands his ground, that could be true of any start up.

I’m mildly disappointed that I don’t even get a chance to talk about the technical architecture: Ian brushes this aside as he’s seen our app running, so we limp back to the team area. Feeling slightly battered and randomized, the team fall into debate over the game purpose and name while Bruno, Richard and I work on tidying up the game play and user interface.

Tired and growing irritiable from overdosing on sugar, we began to tail off around eight o’clock. I spent the evening playing with Ruby on Rails and Heroku, trying to build a simple back end for the app.

Sunday

Sunday morning, I threw myself out of bed with the consolation that Monday was a day off work, and therefore, a lie-in. Launch 48 is truly exhausting if you give it your all, but it is only one weekend, and it didn’t take long to shake off the tiredness and start planning for the day.

We arrived to find Joe grinning and acting mysteriously. He declared that he’d cracked it, and it was amazing, and he would tell us everything shortly, but first we had to write down why we decided to join his team. I debated what to write, finally deciding on, “Passionate and energetic pitch, it sounded like it would be fun”.

Turns out the great idea was a strapline and mantra: Spontaneous Disruptive Gaming.

For the presentation, he said, we’ll go in there and tell them we don’t have a business plan, we don’t need one. We’re about fun and spontaneity, we’re being disruptive! It was a good way to avoid spending all day working on boring stuff, and I was intrigued to see what the mentors would make of it. After all, this is really a weekend people choose to attend, if we don’t produce a business plan, so what?

The day progresses and the code progresses. I’m having a lovely time. In the early afternoon, we have real users and Joe, James and Nick see the app working for the first time in a mobile browser. They are delighted, which in turn lifts the energy even further. We’re on fire!

With nearly three hours to go, a simple working app and lots of ideas, I hand Joe and James a pile of stickies with features on to prioritise. Joe immediately ditches over half of them, leaving us with a few tweaks that look pretty achievable within the time, including an array of guns with different ranges.

So the app is slowly coming together, but with no business plan to prepare, the group is meandering a bit. Where’s our facebook group, I demand, our twitter account, our domain name? They shift up a gear, and I bury myself in my laptop again.

The afternoon flies by and suddenly we’re being rounded up for the presentation. Typically, I break the app trying to adjust the web page in the last few minutes before the presentation, which I haven’t even seen until I’m standing at the front of the room, craning my neck to see the slides. It was slick and well put together, although I am hoping for a bit more attitude and disruption. I think that I would definitely have liked to see the boys in suits and shades or something. ;)

The demo is a bit rocky, and I make a quick fix during the mentor’s questions, but there is no denying that what we’ve achieved within two days is impressive and looking pretty damn good.

Finally the reason for writing down why we joined became clear when James reads all of our slips of paper out to the group: every single person had thought it sounded fun. We don’t have a plan for the future, but we’ve had a damn good time.

The other teams present: Trips Together still looks hopelessly ambitious to me as a project, but Look Book have a working website with commission based links and of all the teams, I think this is the one that may actually go far with it.

In our case, we’ve been in it for the fun, it’s been amazing, but I’m done, and I achieved my objective. I have no desire to be part of a game start up; it doesn’t fit in with my nomadic lifestyle. All I want now is a nice glass of wine and to go home and collapse.

But something’s not right: I go home but I can’t put my laptop down, I’m proud of it and I don’t want to let it go. I try to get the facebook integration working, when that becomes impossible I lose myself writing a blog post. I wonder to myself how I will think back on this weekend in a week, a month, a year; will it change my trajectory?

Monday is spontaneous and disruptive: maybe it’s not over after all. Over the following week, the six remaining team members (Joe, James, Bruno, Richard, Nick and I) exchange over a hundred emails, grab a domain name and a basecamp project, and make plans for another hack weekend. Apparently there’s still a lot of excitement and energy.

It may never become anything, but whatever happens … it’s definitely, definitely been fun.

The “finished” app: Espionage!
The in progress website: Espionage GPS
We did finally get a Twitter account

Review of Agile Coaching

The book: Agile Coaching by Rachel Davies and Liz Sedley (September 2010)

Why I chose this book …

I bought and read this book when I was approaching the first engagement where my role would be solely to coach. In nearly three years at ThoughtWorks, all of the projects I had worked on until January were either pure software delivery, or co-sourced delivery, where coaching of the team was a happy side effect of the work we did.

Summary

This is a great book for first time coaches. It consists of four parts: the first one covers coaching in general and people skills, and the rest walk through Agile practices and how to coach teams to use them. The last section also includes a chapter called “Growing You” which reminds the reader to look after their own skills – and sanity:

“It’s vital to invest in yourself and your own learning so you can grow as a person and keep your ideas fresh. You also need to take care of yourself in order to cope with the day-to-day demands of being an Agile coach.”

The good bits

The book is straightforward and easy to read. The content is broken up with lots of short stories and examples, which I really like – I find this helps to understand the points better.

The book encourages the reader to help the team to think for itself and make mistakes:

“Your goal is to grow a productive Agile team that thinks for itself rather than relying on you to lay down the Agile law. Showing people how to be Agile isn’t enough; they need to change how they work and how they think in order for Agile to stick.”

There are lots of practical recommendations and exercises for how to achieve this, which was great because it was immediately useful and applicable – I often found myself wanting to get into work and try out something the book had suggested. Alongside this, the authors pointed out common hurdles to introducing new practices, often illustrated with examples from their own experience.

I also enjoyed the chapters on development. The book isn’t a technical read and doesn’t try to be, but I thought it dealt reasonably well with the social issues around collective code ownership, refactoring, incremental design and pair programming.

Each of the chapters in the book is self-contained, so you can either dip in to the bits you want or read it from cover to cover.

The bad bits

I can’t really point to anything I disliked about this book! For more experienced coaches, it might not be as useful – I don’t think it contains anything groundbreaking or new.

Recommended?

I would definitely recommend this book for anybody looking to start coaching Agile, looking for a good general read on the subject or some tips and techniques for introducing Agile to a team.

A “Live Coding” experiment …

My colleague Rachel Laycock and I prepared a presentation in April on testing JavaScript with Jasmine. It is based on the work we had done introducing Jasmine earlier this year to a team of JavaScript developers who were working on a large and complex JavaScript application, with little or no unit testing in place already (I wrote about this here and here).

For our first “practice run”, we prepared demonstration code and tests based on the Bowling Game Kata and presented it to a group of fellow ThoughtWorkers. We demonstrated the tests running, and at the request of the audience, changed the code to break one of the tests and demonstrate the error messages.

Feedback from the group was that the pace of the presentation was fairly fast, and the most exciting bit was when we actually changed the code “live”.

More recently, our team on my current client were asked if we might be able to fill in for a lunchtime Tech Talk at short notice, so I dug out the Jasmine presentation again (sadly, I had to do it without Rachel, since she is thousands of miles away enjoying the delights of Bangalore as a trainer at ThoughtWorks University!)

With only a few hours to adapt the presentation, I decided based on the previous feedback to write all of the code and tests during the presentation. Brave maybe, slightly reckless and risky for sure! I ran through the code I planned to write only once with another colleague Chris, and stumbled in a number of places, particularly in the code I wanted to write to demonstrate Jasmine spies, but overall I was happy that it would be good enough. I also decided to try and recruit audience members who might be willing to write some of the code for me.

Learnings from how it went

Overall, I was happy with the decision to code live – the first half of the presentation went very well. When I reached the code around spies, the tests went red and I was unable to multi task well enough to keep presenting, see the bugs and fix them and the tests so I abandoned the real code and carried on, using just the slides and test code. I also received feedback that suggested that the action of writing tests first was a powerful demonstration of test-driven-development, which was also something that was interesting for the audience.

I also found it very difficult to keep talking and keep it interesting while I was either writing code or somebody else was writing a test, so there were a few short silences.

Lastly, I was aware that some of the code I was writing was not optimal, but I didn’t feel that I had the time or enough focus to refactor it (particularly when it wasn’t working anyway).

I think the presentation would work better with two people and a little more practice of the code. This way, one person could talk while the other focused on writing a test or making it pass. However, I would definitely keep the live coding aspect.

I fell back on the short preparation time as an excuse when things didn’t quite go to plan, but I hope a development audience would usually be fairly forgiving if you can’t quite write code right first time around!

The presentation and code is available from github. I hope to present it again at the London Java Community in July.

Review of Head First Design Patterns

The book: Head First Design Patterns by Eric T Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra

Why I chose this book …

I switched from BA back to development last year and was looking for good books to learn from, and one of my friends suggested HFDP. I didn’t know much at all about design patterns – I’d only really encountered MVC.

Summary

This is a book to work through rather than a reference book. It presents a series of design patterns with exercises including code ‘fridge magnets’, crosswords and general challenges. The code samples are all in Java, but very simple and should be no problem for non-Java devs – there is a very positive review from an ActionScript developer on Amazon!

The patterns it covers are: Abstract Factory, Adapter, Command, Composite, Decorator, Facade, Factory Method, Iterator, Model-View-Controller, Observer, Proxy, Singleton, State, Strategy, Template Method.

In the appendix, it also covers: Bridge, Builder, Chain of Responsiblity, Flyweight, Interpreter, Mediator, Memento, Prototype, Visitor.

The first time I tried to read the book I put it down after I’d read about half of it, because I was struggling to relate it to the real world. I picked it up again when I was also reading Pro JavaScript Design Patterns, to try and understand that better.

Although I did read the whole book in the end, I didn’t follow the exercises – partly because I was using an e-reader, and partly because I just didn’t want to spend that much time on it. By the time I finished, I felt that I had got what I wanted out of it, which was a high level understanding of the patterns, and the ability to better recognise where I was using them and have a conversation about them.

The good bits

The book is really easy to read and follow, and mostly quite fun to read, which is its main strength, and this also shows in the reviews on Amazon. Each pattern is introduced using a story of somebody asking for a software solution. Often the authors use conversations between a fictional team of developers trying to solve the problem to explain the concepts. There are lots of diagrams and “Q&A”, reviews of what you should have learned, and a nice summary at the end of each chapter, which was good to refer back to.

The book also explains and emphasizes OO principles, and how they are linked to each pattern, which I liked. The extra summaries in the appendix of the patterns that didn’t quite make it into the main text were also really useful.

The bad bits

My main gripe with the book is that the stories and code samples are too far removed from real life situations, which made it more difficult to grasp some of the patterns first time around. The second time I read it, I had a lot more context and could relate what I was reading to real-world code I’d seen on projects.

The puzzles and exercises don’t lend themselves well to reading on an e-reader. I also grew slightly tired of the ‘Fireside Chats’ between design patterns, and after reading about two thirds of the book I began to wish they would hurry up a bit more.

Recommended?

I would recommend this book as a good read as an introduction to design patterns, especially for people who have enough coding experience to recognise the patterns in what they’ve done but don’t really know much about them. If you already know a fair bit about patterns and just want to brush up or read up on a specific one, you’re probably better off asking the interwebs :)