breaking the ice

A new project and a new pile of legacy code always presents me with a large psychological barrier: where should I begin testing, and where should I begin trying to understand what’s where?

Bill Wake, in the Planning Game Simulator chapter of his Refactoring Workbook, has a great answer. Bill suggests that we begin by writing just one test – any test – for every class in the system. The tests can be as simple as you like; their only purpose is to break the ice. Not only do these tests get every class into the test harness, they also prove to me that it’s possible to get every class under test – and that removes the psychological barrier completely. From there it is always a lot easier to continue writing more tests.

I saw this effect for real recently on a client project, and we also experienced it at this month’s AgileNorth coding dojo. We wanted to refactor a smell away from some of the “GUI” code in Wake’s planning game simulator exercise, and someone suggested we needed to make the refactoring safe by writing a test first. But this was GUI code, so the temptation was to shrug and claim it was impossible. Undeterred, Guy wrote a couple of lines that created the window, pushed a button and checked the resulting number of cards in the backlog, and suddenly we were off and running. The refactoring we had in mind was now safe, and the code now seemed like it was ours.

At that point another interesting effect occurred. We looked at the few tests we now had, and we saw smells in the product code – smells we hadn’t seen when we reviewed it at the start of the evening. The test code was revealing usability smells in the class’ interfaces, and our understanding of what to do and where the code wanted to go deepened.

Even a two-line test can have a dramatic impact on the stress of dealing with “untamed” code.

introducing andy lawrence

I was delighted to discover today that Andy Lawrence has started a blog – and I was even more delighted when I read his first few posts. Andy has managed to put into words something I’ve held off saying, and he’s neatly expressed it in the same terms as the agile manifesto:

“I am uncovering better ways of delivering valuable software by doing it and helping others do it. Through this work I have come to value: applying agile values over following Agile practices
That is, while there is value in the item on the right, I value the item on the left more”

Many of you will know Andy: he was one of the original AgileNorth committee members, and he and I collaborated on our muda workshops a while back. Give him a look, at http://learningtobeagile.blogspot.com/.

agilenorth 2006 retrospective

The AgileNorth 2006 1-day conference has come and gone, and so far I’ve had no time to comment on it. I was extremely happy with how the day turned out – lots of new faces, and lots of very interesting sessions led by enthusiastic and knowledgeable volunteers. I hope to post some photos on the conference website soon.

And in lieu of comments from me, here are a couple of blog posts by other attendees:

Please let me know if you’ve blogged about the conference so that I can link to you from the website.

joomla can be almost a wiki

This summer I spent some time learning about and using Joomla, so that I could maintain AgileNorth‘s new website. I took a long time to get my head around the structure and concepts, and I don’t know whether that’s due to my lack of exposure to content management systems, or to Joomla itself. I think it has mostly clicked for me now, and one little thing has helped more than any other: a “mambot” called rdlc. This little plug-in allows you to type

{rdlc My Page Title}

anywhere in a content item, and it replaces itself with a link to the page with that title. No more fiddling and faffing with cumbersome links; no more trying to remember which item ID refers to which page. I’ve been using rdlc so much, in fact, that it almost feels as if I’m working in a wiki. This little macro has caused my productivity to rocket, because now I’m in familiar territory. I work with wikis every day, and so I no longer feel I’m lost in a strange CMS. rdlc is a must.

scrum or lean?

This week’s April meeting of the AgileNorth group was a book review. Kevin Dockerill reviewed Mary Poppendieck’s Lean Software Development and Ken Schwaber’s Agile Software Development with Scrum. We spent about forty-five minutes discussing each book, and then half and hour or so comparing the two methods, particularly in relation to applying them in Kevin’s own small team.

While reading the books in preparation for the meeting, Kevin had created a little summary leaflet for each. Each leaflet was in two parts: the first stepped through the book’s chapters picking out the main points, while the second provided Kevin’s commentary and opinion. (In the case of the Scrum book, Kevin also rated each chapter out of 10 – from which we discovered that the first half was much more to his taste than the second!) The format of Kevin’s little leaflets worked extremely well, and I would recommend this kind of approach for any subsequent book review. I particularly liked the idea of chapter ratings, which gave us an at-a-glance view of Kevin’s opinion and also highlighted the two very different halves of the Scrum book.

As the meeting progressed, the discussion moved away from the books and on to comparing and contrasting the two methods – Scrum vs. lean. I was too engaged for taking notes, but I recall some main themes emerging in the opinion of the group as a whole:

  • Scrum is likely to serve well in a traditional, structured, command-and-control organisation, where strong project management and reporting lines reign. Whereas the Lean book offers a bag of tools, and so will probably appeal to more ‘fluid’ organisations.
  • The mapping of software development to manufacturing is not helpful to organisations that aren’t used to growing their own processes and adapting them regularly.
  • The Lean book maps specific practices from lean manufacturing into software development, without providing enough background on why those practices are appropriate.
  • It seems unlikely that many software projects could go 30 days without changing their requirements; so Scrum seems to be targeted at bigger projects.

This was an enjoyable evening, made very productive by Kevin’s thorough and thoughful preparation. I’m looking forward to the next one, on May 15th!

What were your first impressions when you read these two books?

introducing david draper

David Draper, a new friend of mine from the AgileNorth group, has begun blogging (again) this week. He has strong opinions about the lack of design that gets done on agile projects, and he has been instrumental in helping to set up and run our successful recent series of coding dojos. But don’t take my word for it – check him out in person at http://www.agiledesign.co.uk/wordpress/.

AgileNorth 2005 retrospective

The conference was a great success, with over 50 attendees! Many thanks to the committee (Phran, Katie, Ant, Donna and Paul) for all their hard work organising everything, and to the various speakers for giving their time to create such a full and varied programme. We have collected feedback from the attendees so that we can ensure next year’s event is even better.

Here are a few thoughts on sessions I attended…

What is Agile?

The day began with a re-run of my overview of agile software development. After discussion with Brian Button I tightened the schedule and the process, and I thought it went very well this time. The variety of topics raised by the audience was challenging and encouraging, and of course we only managed to scratch the surface…

XP Teamwork – a goldfish bowl led by Charles Weir

The original descriptions of eXtremeProgramming suggested that a project’s staff would play only three roles: Developer, Coach and Customer. But in reality, the role of Customer is very hard to fill using real people. In this session the group discussed the difficulties of setting up an effective Customer role, using a format in which only those sitting in the four central chairs may speak. The topic swerved around depending on the mix of people in the chairs at any time, and I think some good insights were gained. Rachel Davies contributed a great deal from her experiences coaching XP teams.

Test-Driven Development – a demonstration by Brian Swan

In which we began the development of a blackjack game, with Brian driving and me pairing. We ran out of time, but still got some basic techniques and functionality in place.

Refactoring – a workshop with Ivan Moore and Duncan Pierce

Duncan and Ivan presented a piece of Java code that included loads of smells, and the group identified them and refactored to remove them. There was lots of discussion among the more experienced members of the group; some wanted to keep the design naive, while others wanted to introduced new classes to represent some of the more obvious domain concepts. Very enjoyable.

Finally, note that Andrew Beacock has also blogged about the day.