coding is like cooking

Global Day of Code Retreat

2011-12-20T15:00:00.002+01:00

A little while back I was back in Stockholm facilitating another Code Retreat, (see previous post), this time as part of Global Day of Code Retreat, (GDCR). (Take a look at Corey Haines' site for loads of information about this global event that comprised meetings in over 90 cities worldwide, with over 2000 developers attending.)

I think the coding community could really do with more people who know how to do TDD and think about good design, so I'm generally pretty encouraged by the success of this event. I do feel a bit disappointed about some aspects of the day though, and this post is my attempt to outline what I think could be improved.

I spent most of the Global Day of Code Retreat walking around looking over people's shoulders and giving them feedback on the state of their code and tests. I noticed that very few pairs got anywhere close to solving the problem before they deleted the code at the end of each 45 minute session. Corey says that this is very much by design. You know you don't have time to solve the problem, so you can de-stress: no-one will demand delivery of anything. You can concentrate on just writing good tests and code.

In between coding sessions, I spent quite a lot of effort reminding people about simple design, SOLID principles, and how to do TDD (in terms of states and moves). Unfortunately I found people rarely wrote enough code for any of these ideas to really be applicable, and TDD wan't always helping people.

I saw a lot of solutions that started with the "Cell" class, that had an x and y coordinate, and a boolean to say whether it was alive or not. Then people tended to add a "void tick(int liveNeighbourCount)" method, and start to implement code that would follow the four rules of Conway's Game of Life to work out if the cell should flip the state of its boolean or not. At some point they would create a "World" class that would hold all the cells, and "tick()" them. Or some variant of that. Then, (generally when the 45 minutes were running out), people started trying to find a data structure to hold the cells in, and some way to find out which were neighbours with each other. Not many questioned whether they actually needed a Cell class in the first place.

Everyone at the code retreat deleted their code afterwards, of course, but you can see an example of a variant on this kind of design by Ryan Bigg here (a work in progress, he has a screencast too).

Of course, as facilitator I spent a fair amount of time trying to ask the kind of questions that would push people to reevaluate their approach. I had partial success, I guess. Overall though, I came away feeling a bit disillusioned, and wanting to improve my facilitation so that people would learn more about using TDD to actually solve problems.

At the final retrospective of the day, everyone seemed to be very positive about the event, and most people said they learnt more about pair programming, TDD, and the language and tools they were working with. We all had fun. (If you read Swedish, Peter Lind wrote up the retrospective in Valtech's blog) This is great, but could we tweak the format to encourage even more learning?

I think to solve Conway's Game of Life adequately, you need to find a good datastructure to represent the cells, and an efficient algorithm to "tick" to the next generation. Just having well named classes and methods, although a good idea, probably won't be enough.

For me, TDD is a good method for designing code when you already mostly know what you're doing. I don't think it's a good method for discovering algorithms. I'm reminded of the debate a few years back when Peter Norvig posted an excellent Sudoku solver (here) and people thought it was much better than Ron Jeffries' TDD solution to the same problem (here). Peter was later interviewed about whether this proved that TDD was not useful. Dr Norvig said he didn't think that it proved much about TDD at all, since

"you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution"
(from Peter Siebel's book "Coders At Work", an extract of which is available in his blog)

I felt that most of the coders at the code retreat were messing around without actually knowing how to solve the problem. They played with syntax and names and styles of tests without ever writing enough code to tell whether their tests were driving a design that would ultimately solve the problem.

Following the GDCR, I held a coding dojo where I experimented with the format a little. I only had time to get the participants do two 45 minute coding sessions on the Game of Life problem. At the start, as a group we discussed the Game of Life problem, much as Corey recommends for a Code Retreat introduction. However, in addition, I explained my favoured approach to a solution - the data structure and algorithm I like to use. I immediately saw that they started their TDD sessions with tests and classes that could lead somewhere. I feel that if they had continued coding for longer, they should have ended up with a decent solution. Hopefully it would also have been possible to refactor it from one datastructure to another, and to switch elements of the algorithm without breaking most of the tests.

I think this is one way to improve the code retreat. Just give people more clues at the outset as to how to tackle the problem. In real life when you sit down to do TDD you'll often already know how to solve similar problems. This would be a way for the facilitator to give everyone a leg-up if they havn't worked on any rule-based games involving a 2D infinite grid before.

Rather than just explaining a good solution up front, we could spend the first session doing a "Spike Solution". This is one of the practices of XP:

"the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out."
From "Extreme Programming Installed" by Jeffries, Anderson, Hendrickson, p41

Basically, you hack around without writing any tests or polishing your design, until you understand the problem well enough to know how you plan to solve it. Then you throw your spike code away, and start over with TDD.

Spending the first 45 minute session spiking would enable people to learn more about the problem space in a shorter amount of time than you generally do with TDD. By dropping the requirement to write tests or good names or avoid code smells, you could hopefully hack together more alternatives, and maybe find out for yourself what would make a good data structure for easily enumerating neighbouring cells.

So the next time I run a code retreat, I think I'll start with a "spiking" session and encourage people to just optimize for learning about the problem, not beautiful code. Then after that maybe I'll sketch out my favourite algorithm, in case they didn't come up with anything by themselves that they want to pursue. Then in the second session we could start with TDD in earnest.

I always say that the code you end up with from doing a Kata is not half as interesting as the route you took to get there. To this end I've published a screencast of myself doing the Game of Life Kata in Python. (The code I end up with is also published, here). I'm hoping that people might want to prepare for a Code Retreat by watching it. It could be an approach they try to emulate, improve on or criticise. On the other hand, showing my best solution like this is probably breaking the neutrality of how a code retreat facilitator is supposed to behave. I don't think Corey has ever published a solution to this kata, and there's probably a reason for that.

I have to confess, I already broke all the rules of being a facilitator, when I spent the last session of the Global Day of Code Retreat actually coding. There was someone there who really wanted to do Python, and no-one else seemed to want to pair with him. So I succombed. In 45 minutes we very nearly had a working solution, mostly because I had hacked around and practiced how to do it several times before. It felt good. I think more people should experience the satisfaction of actually completing a useful piece of code using TDD at a Code Retreat.

Scandinavian Developer Conference

2011-12-20T13:11:00.000+01:00

Scandinavian Developer Conference will be held in Göteborg in April, and last week we launched the detailed programme on the website. I've been involved with the conference ever since the first event in 2009, but this year I've taken on increased responsibilities, acting as Programme Chair.

When P-A Freiholtz, the Managing Director at Apper Systems*, (the company behind the conference), approached me about taking this role, I jumped at the chance. My business is all about professional development for software developers, and a conference in Göteborg is a really good opportunity for a lot of local people to hear about what's going on in the world outside. Many of the developers I meet in my work don't often get away from their desks, spending the majority of their time caught up in the intrigues and deadlines of a single project and company environment. SDC2012 will be a chance for a lot of local people to broaden their horizons without it costing their boss a fortune, or disrupting their usual schedule too much.

I wrote an editorial on the front page of the conference website which explains more about what's on the programme and who should come. Everyone involved in software development, basically :-)

These days, we compete in a global marketplace for software development. I'm hopeful about the future, I'm enthusiastic about Swedish working culture, and I think Scandinavian Developer Conference is helping Göteborg grow as a center of competence. Please do join us at the conference.

* formerly named Iptor - now under new ownership.

XP2012 Team Challenge

2011-11-27T20:58:00.001+01:00

At a conference about software development, wouldn’t it be useful to have some people there actually develop software? We want to invite you to bring your whole team, and show off how agile you are. Set up your team information radiators, pair programming stations and servers, and spend part of the conference actually developing your product! With any luck, some of the excellent agilists at the conference will come and pair with you.

The only rules are that you must be agile, and you must deploy into production during the conference. If you deploy several times a day and the product is generally available for conference delegates to use and try the new features, all the better. :-)

See this as a challenge for your team. If you’re going to be able to show your process off to a whole conference of agilists, wouldn’t you like to have the best possible process? Wouldn’t you like all your team members to work effectively with the latest tools and techniques? Wouldn’t the challenge of having to be ready to show off what you can do at XP2012 be a great way to motivate your team to improve over the next 6 months?

This is the challenge that the team behind http://blocket.se (one of Sweden’s biggest ecommerce sites), and a team from SAAB Gripen, (software for jet fighters), have already accepted. Will you join them, and take up the XP2012 team challenge?

Tech Demos at XP2012

2011-11-27T20:55:00.001+01:00

At XP2011 we introduced a new kind of presentation - the tech demo. The idea was to give people 30 minutes to demonstrate a new tool or technique. For example, some people performed code katas in diverse languages, and others showed various productivity-boosting frameworks.

For XP2012 we want to continue with these kinds of demos, but with an additional rule. You can’t touch the keyboard yourself when you present. We want you to co-present with someone else, drawn from the audience, who will do the typing and demonstrate the tool or technique. Your job is to coach them into doing the demo you've planned, and to explain to everyone what’s going on.

Your co-presenter could be someone drawn from the audience who you’ve never met before. You’ll have to expertly coach them into demonstrating what you aim to show to the rest of the audience. If you choose this route, it will certainly be a big test of your skills of coaching and pedagogy.

Alternatively you can come to the conference and find a volunteer in advance of the presentation. You could make time for a practice run or two before the presentation. Again, you’ll be showing not only your tool or techique, but also how easy it is for a good programmer to learn.

If you’re thinking this sounds like an awfly scary way to do a demo, then you may be right. We think it’s also a very good way to have demos that engage the audience and really show off what you’re capable of.

If you know someone else who’ll be at the conference you could of course prepare the demo with them well in advance. You’d be able to work out exactly what pitfalls they will fall into, and have a slick commentary ready. Just having one person typing and the other talking is a great advantage in a demo, and this would probably still be good to watch. It might not be quite as challenging though :-)

Will you accept the XP2012 Tech Demo challenge?

Presenting a session at XP2012

2011-11-27T20:45:00.001+01:00

The Call for Papers for XP2012 is currently open, and this year we’re doing things a little differently*. I'm one of the co-chairs responsible for programme design, and also involved in reviewing session proposals. (You might be interested in my post about XP2011, which I was also involved in organizing)

Most proposals are going through what will hopefully be a more transparent, agile and effective review process than we’ve had in the past. The idea is that everyone sends in a first draft proposal, and then receives feedback from reviewers who want to help them to improve and refine their ideas. When everyone has had a chance to act on this feedback, the review committee will select the proposals that will be put on the programme for the conference.

More information, dates and benefits of speaking are listed on the conference website. My next two posts contain more information about a couple of the session types we're looking for: Tech Demos
and the Team Challenge.

*Academic papers have a separate review track, and proceed much as they have done previously. The demands of academic rigour and peer review mean we won’t change a formula that clearly works for this kind of submission. See the call for research papers.

Öredev experiences on my first day here

2011-11-10T07:05:00.000+01:00

I've never been to Öredev before, and it really is a very impressive conference. Gathered in Malmö right now, is over a thousand developers, with a collection of speakers representing the elite of the global software development industry. The sessions are overflowing with a plethora of great advice, news and inspiration. That's primarily why I'm here, although I could also praise the excellent conference organization, food, live music, sponsor giveaways and other entertainments.

I'd like to talk about my first impressions of the conference. As with other software conferences I've been too, women are rather unusual here, both among delegates and speakers. I've blogged about this before, and it's not untypical. The sad fact is that the proportion of women is low, and, unlike in other industries, actually falling in software development.

I'd just like to relate two experiences I had yesterday.

Women speakers
I'm here as an ordinary delegate at this conference, but at most conferences I go to, I'm a speaker. I was really happy to be greeted yesterday by Dan North, Gojko Adzic, Pat Kua, Corey Haines and others, since they're people who I really respect. I've mostly got to know them when we've spoken at the same conferences in the past. Of course they all asked me which day I was speaking on at Öredev. Well, the easy answer is that I was not asked to speak here. I looked on the Öredev conference website and there was no call for submissions, unlike other conferences I have spoken at like XP, Agile Testing Days, ScanDev, Agile, JFokus etc. I assumed that it was invitation only, and the track chairs would mail me if they were interested in having me speak. Now I realize that I should have mailed them to point out I wanted to speak here.

I think I just fell into this trap that women apparently often fall into, described in this article I read this week: "Four Ways Women Stunt Their Careers Unintentionally". Apparently we tend to be "overly modest" and "women fail to get promoted because they fail to step up and apply". So I didn't apply, and I didn't get a job to speak at Öredev. #kickingmyself

Neal Ford's keynote
I listened to a keynote by Neal Ford yesterday. I've heard him speak before, and he is always very entertaining and yet makes some interesting points about software. It's just a small thing he said that really bothered me. A keynote speech is supposed to set the tone for a whole conference - you have the everybody gathered, and you're supposed to say something inspirational and thought provoking.

One of Neal's jokes was about some obscure Star Trek reference that I didn't get (although from the audience reaction I'm guessing most others did), that he followed up with a slide showing the top Google image results when you searched for this thing. He made some comment about google knowing that when you search for this, you're really asking for porn. He had helpfully airbrushed out the image results so you could only vaguely see the outline of naked women.

Neal, you really didn't need to do that. Your talk had enough fun stuff in it without alienating me with science fiction references and disguised porn.

Looking forward
There are two more days of the main conference, and plenty more good stuff on the programme. I've spotted a session called "geek feminism" in the "extra" track. I've never thought of myself as a geek feminist, but maybe I am. Having had the experiences described above, I think I'll go along and find out.

What is Text-Based Testing?

2011-11-09T08:03:00.000+01:00

Programmers have a vested interest in making sure the software they create does what they think it does. When I'm coding I prefer to work in the context of feedback from automated tests, that help me to keep track of what works and how far I've got. I've written before about Test Driven Development, (TDD). In this article I'd like to explain some of the main features of Text-Based Testing. It's a variant on TDD, perhaps more suited to the functional level than unit tests, and which I've found powerful and productive to use.

The basic idea
You get your program to produce a plain text file that documents all the important things that it does. A log, if you will. You run the program and store this text as a "golden copy" of the output. You create from this a Text-Based Test with a descriptive name, any inputs you gave to the program, and the golden copy of the textual output.

You make some changes to your program, and you run it again, gathering the new text produced. You compare the text with the golden copy, and if they are identical, the test passes. If the there is a difference, the test fails. If you look at the diff, and you like the new text better than the old text, you update your golden copy, and the test is passing once again.

Tool Support
Text-Based Testing is a simple idea, and in fact many people do it already in their unit tests. AssertEquals(String expected, String actual) is actually a form of it. You often create the "expected" string based on the actual output of the program, (although purists will write the whole assert before they execute the test).

Most unit test tools these days give you a nice diff even on multi-line strings. For example:

Which is a failing text-based test using JUnit.

Once your strings get very long, to the scale of whole log files, even multi-line diffs aren't really enough. You get datestamps, process ids and other stuff that changes every run, hashmaps with indeterminate order, etc. It gets tedious to deal with all this on a test-by-test basis.

My husband, Geoff Bache, has created a tool called "TextTest" to support Text-Based testing. Amongst other things, it helps you organize and run your text-based tests, and filter the text before you compare it. It's free, open source, and of course used to test itself. (Eats own dog food!) TextTest is used extensively within Jeppesen Systems, (Geoff works for them, and they support development), and I've used it too on various projects in other organizations.

In the rest of this article I'll look at some of the main implications of using a Text-Based Testing approach, and some of my experiences.

Little code per test
The biggest advantage of the approach, is that you tend to write very little unique code for each test. You generally access the application through a public interface as a user would, often a command line interface or (web)service call. You then create many tests by for example varying the command line options or request contents. This reduces test maintenance work, since you have less test code to worry about, and the public API of your program should change relatively infrequently.

Legacy code
Text-Based Testing is obviously a regression testing technique. You're checking the code still does what it did before, by checking the log is the same. So these tests are perfect for refactoring. As you move around the code, the log statements move too, and your tests stay green, (so long as you don't make any mistakes!) In most systems, it's cheap and risk-free to add log statements, no matter how horribly gnarly the design is. So text-based testing is an easy way to get some initial tests in place to lean on while refactoring. I've used it this way fairly successfully to get legacy code under control, particularly if the code already produces a meaningful log or textual output.

No help with your design
I just told you how good Text-Based Testing is with Legacy code. But actually these tests give you very little help with the internal design of your program. With normal TDD, the activity of creating unit tests at least forces you to decompose your design into units, and if you do it well, you'll find these tests giving you all sorts of feedback about your design. Text-Based tests don't. Log statements don't care if they're in the middle of a long horrible method or if they're spread around several smaller ones. So you have to get feedback on your design some other way.

I usually work with TDD at the unit level in combination with Text-Based tests at the functional level. I think it gives me the best of both worlds.

Log statements and readability
Some people complain that log statements reduce the readability of their code and don't like to add any at all. They seem to be out of fashion, just like comments. The idea is that all the important ideas should be expressed in the class and method names, and logs and comments just clutter up the important stuff. I agree to an extent, you can definitely over-use logs and comments. I think a few well placed ones can make all the difference though. For Text-Based Testing purposes, you don't want a log that is megabytes and megabytes of junk, listing every time you enter and leave every method, and the values of every variable. That's going to seriously hinder your refactoring, apart from being a nightmare to store and update.

What we're talking about here is targeted log statements at the points when something important happens, that we want to make sure should continue happening. You can think about it like the asserts you make in unit tests. You don't assert everything, just what's important. In my experience less than two percent of the lines of code end up being log statements, and if anything, they increase readability.

Text-Based tests are completed after the code
In normal TDD you write the test first, and thereby set up a mini pull system for the functionality you need. It's lean, it forces you to focus on the problem you're trying to solve before you solve it, and starts giving you feedback before you commit to an implementation. With Text-Based Testing, you often find it's too much work the specify the log up front. It's much easier to wait until you've implemented the feature, run the test, and save the log afterwards.

So your tests usually aren't completed until after the code they test, unlike in normal TDD. Having said that, I would argue that you can still do a form of TDD with Text-Based Tests. I'd normally create the half the test before the code. I name the test, and find suitable inputs that should provoke the behaviour I need to implement in the system. The test will fail the first time I run it. In this way I think I get many of the benefits of TDD, but only actually pin down the exact assertion once the functionality is working.

"Expert Reads Output" Antipattern
If you're relying on a diff in the logs to tell you when your program is broken, you had better have good logs! But who decides what to log? Who checks the "golden copy"? Usually it is the person creating the test, who should look through the log and check everything is in order the first time. Of course, after a test is created, every time it fails you have to make a decision whether to update the golden copy of the log. You might make a mistake. There's a well known antipattern called "Expert Reads Output" which basically says that you shouldn't rely on having someone check the results of your tests by eye.

This is actually a problem with any automated testing approach - someone has to make a judgement about what to do when a test fails - whether the test is wrong or there's a bug in the application. With Text-Based Testing you might have a larger quantity of text to read through compared with other approaches, or maybe not. If you have human-readable, concise, targeted log statements and good tools for working with them, it goes a long way. You need a good diff tool, version control, and some way of grouping similar changes. It's also useful to have some sanity checks. For example TextTest can easily search for regular expressions in the log and warn you if you try to save a golden copy containing a stack trace for example.

In my experience, you do need to update the golden copy quite often. I think this is one of the key skills with a Text-Based Testing approach. You have to learn to write good logs, and to be disciplined about either doing refactoring or adding functionality, not both at the same time. If you're refactoring and the logs change, you need to be able to quickly recognize if it's ok, or if you made a mistake. Similarly, if you add new functionality and no logs change, that could be a problem.

Agile Tests Manage Behaviour
When you create a unit test, you end with an Assert statement. This is supposed to be some kind of universal truth that should always be valid, or else there is a big problem. Particularly for functional level tests, it can be hard to find these kinds of invariants. What is correct today might be updated next week when the market moves or the product owner changes their mind. With Text-Based Testing you have an opportunity to quickly and easily update the golden copy every time the test "fails". This makes your tests much more about keeping control of what your app does over time, and less about rewriting assert statements.

Text-Based Testing grew up in the domain of optimizing logistics planning. In this domain there is no "correct" answer you can predict in advance and assert. Planning problems that are interesting to solve are far too complex for a complete mathematical analysis, and the code relies on heuristics and fancy algorithms to come up with better and better solutions. So Text-Based Testing makes it easy to spot when the test produces a different plan from before, and use it as the new baseline if it's an improvement.

I think generally it leads to more "agile" tests. They can easily respond to changes in the business requirements.

Conclusions
There is undoubtedly a lot more to be said about Text-Based Testing. I havn't mentioned text-based mocking, data-driven vs workflow testing, or how to handle databases and GUIs - all relevant topics. I hope this article has given you a flavour of how it's different from ordinary TDD, though. I've found that good tool support is pretty essential to making Text-Based Testing work well, and that it's a particularly good technique for handling legacy code, although not exclusively. I like the approach because it minimizes the amount of code per test, and makes it easy to keep the tests in sync with the current behaviour of the system.

The Clean Coder & Apprenticeship Patterns

2011-10-14T11:43:00.000+02:00

I'm speaking next week at ScanDev on Tour in Stockholm on the subject of "Software Development Craftsmanship", and as part of my research I read both "The Clean Coder" by Robert C. Martin and "Apprenticeship Patterns" by Dave Hoover & Adewale Oshineye. These are very different books, but both aimed at less experienced software developers who want to learn about what it means to be a professional in the field. In this article I'd like to review them side by side. First some text from each preface on what the authors think the books are about:

Apprenticeship Patterns

"This book should help you through the tough decisions you face as a newcomer to the field of professional software development. " (preface xi)

The Clean Coder

"This book is about software professionalism. It contains a lot of pragmatic advice" (preface xxii)

The Content
Both books contain a lot of personal stories and anecdotes from the authors' careers, and begin with a short autobiography. Some of the advice is also similar. Both advise you to practice with "Kata" exercises, to read widely and to find suitable mentors. I think that's mostly where the similarities end though.

Dave and Ade don't say much about how to handle unreasonable managers imposing impossible deadlines. Bob Martin devotes a several chapters to this kind of issue, handling pressure, time management, estimation, making committments etc.

Dave and Ade talk more about how to get yourself into situations optimized for learning and progress in your career. They advise you to "Be the worst", "Find mentors", seek "Kindred Spirits". In other words, join a team where you're the least skilled but you'll be taught, look for mentors in many places, and get involved in the community.

Bob talks about a lot of specific practices and has detailed advice. He mentions "... pairing is the most efficient way to solve a problem" (p164) Later in the chapter he suggests the optimal composition of job roles in a gelled team. (p169) He also has some advice about how to successfully argue with your boss and go over their head when necessary (p35).

The Advice
Those few example perhaps illustrate that these two books are miles apart when it comes to writing style, approach and world view. Dave&Ade have clearly spent a lot of time talking with other professionals about their material, acting on feedback and testing their ideas for validity in real situations. The book is highly collaborative and while full of advice, is not prescriptive.

Bob Martin on the other hand loves to be specific, provocative and extreme in his advice. "QA should find nothing."(p114) "You should plan on working 60 hours per week." (p16) "Avoid the Zone." (p62) "The jury is in! ... TDD works" (p79) These are some of his more suprising pieces of advice, which I think are actually fairly doubtful propositions when taken to extremes like this. Mixed in are more reasonable statements. "You do not have to attend every meeting to which you are invited" (p123) "The professional developer is calm and decisive under pressure". (p150)

The way everything is presented as black-and-white, do-or-do-not-there-is-no-try is actually pretty wearing after a while. He does it to try to make you think, as a rhetorical device, to promote healthy discussion. I think it all too easily leads the reader to throw the baby out with the bathwater. I can't accept one of his recommendations, so I throw them all out.

Some of Dave&Ade's advice is actually just as hard to put into practice. Each of their patterns is followed by a call to action. Things like re-implementing a program you've written in an imperative language in a functional language (p21). Join or start a user group (p65). Solve the same coding exercise once a week for the next four weeks (p79). None of these things is particularly easy to do, but they seem to me to be interesting and useful challenges.

Collaboration
Bob has also clearly not collaborated very widely when preparing his material. One part that particularly sticks out for me is a footnote on page 75:

"I had a wonderful conversation with @desi (Desi McAdam, founder of DevChix) about what motivates women programmers. I told her that when I got a program working, it was like slaying the great beast. She told me that for her and other women she had spoken to, the act of writing code was an act of nurturing creation." (footnote, p75)

Has he ever actually run his "programming is slaying a great beast" thing past any other male programmers? Let me qualify that - non-fantasy-role-playing male programmers? Thought not. This is in enormous contrast to Dave&Ade, whose book is full of stories from other people backing up their claims.

Stories
Bob's book is full of stories from his own career, and he is very honest and open about his failures. This is a very brave thing to do, and I have a great deal of respect for him for doing so. It's also really interesting to hear about the history of what life was like when computers filled a room and people used punch cards to program them. Dave&Ades stories are less compelling and not always as well written.

Bob's book is not just about his professional life, he shares his likes and dislikes. He reccommends cycling or walking to recharge your energy, or "focus-manna" as he calls it, (p127). Reading science fiction as a cure for writer's block. (p66) Listening to "The Wall" while coding could be bad for your design. (p63) When describing "Master" programmers he likens them to Scotty from Star Trek. (p182)

All this is very cute and gives you a more rounded picture of what software professionalism is about. Maybe. Actually it really puts me off the idea. I know a lot of software developers like science fiction and fantasy role playing, but it really isn't mandatory. He usually says that you may have other preferences, and you don't have to do like he does, but I just don't think it helps all that much. The rest of the book is highly dogmatic about what you should and shouldn't do, and it kind of rubs off.

Conclusions
The bottom line is, I wouldn't reccommend "The Clean Coder" to any young inexperienced software developer, particularly not if she were a woman. There is too much of it written from a foreign culture, in a demanding tone, propounding overly extreme behaviour. The interesting stories and good pieces of advice are drowned out.

On the other hand, I would recommend "Apprenticeship Patterns". I think it is humbly written and anchored in real experience from a range of people. I agree with them when they say you need to read it twice to understand it. The first time to get an overview, the second time to understand how the patterns connect. It's not as easy to read as it might be. But still, I think the content is interesting, and it gives a good introduction to what being a professional software craftsman is about, and how to get there.

Code Retreat Stockholm

2011-09-21T10:47:00.000+02:00

This weekend I was in Stockholm to facilitate a Code Retreat, organized by Peter Lind and sponsored by Valtech. We were about 40 coders gathered in the warm autumn sunshine early on a Saturday morning at Valtech's offices. (Do take a look at Peter's blog post about it, he has a photo too).

It's actually the first time I've even attended a code retreat, let alone facilitated, but I think it went pretty well. Corey Haines has written extensively about what should happen, and what the facilitator should do. I think he's given a great gift to the community, not just by inventing the format, but also by documenting it thorougly. I've previously led various coding dojos and "clean code day" events, but code retreat is somewhat different in format, if not in aim.

The reason for going to a code retreat is to practice your coding skills. By repeating the same exercise over and over, with different pairing partners, you have a chance to work on your coding habits. Do you pay attention to what your tests are telling you about your design? Do you remember to refactor regularly? Can you take really small steps when you need to?

For the day in Stockholm, we followed the tried and tested formula for a code retreat that Corey has laid out. I spent about 20 minutes introducing the day, the aims and the coding problem (Conway's Game of Life). Then we did 6 coding sessions, each with a short retrospective, and a longer retrospective at the end of the day. Each session comprised 45 minutes coding in pairs, 10 minutes retrospective in groups of 6-8, and 5 minutes to swap partners. I also began each coding session by reminding everyone of what we were supposed to be practicing, and highlighted a different "challenge" to add some variety. The challenges were things like:

- concentrate on writing really beautiful code so the language looks like it was made for the problem. *
- partition code at different levels of abstraction. **
- Think about TDD in terms of states and moves.
- do TDD as if you meant it
- concentrate on refactoring in very small steps

Each pairing session is just 45 minutes, and in that time you don't actually have time to really solve the whole kata, and that's actually quite difficult to cope with. Most coders are very motivated by writing code that does something useful, and like to show off their finished designs at the end. To try to prevent that, Corey emphasizes that you should keep in mind the end result isn't important, and be sure to delete the code at the end of the session. I found that even with that rule, there was quite a lot of discussion of how the designs ended up, and some people even saved their code.

One of the things I encouraged people to try was working in an unfamiliar programming language, and although I specified "for 1 or 2 sessions", I was surprised to find how popular it was to do this. After the first session when most people used Java, C#, Ruby or Python, there were more and more people coding in Clojure, Javascript, Erlang and even Vim script. I think it got a bit out of hand actually. It's hard to practice your coding habits and TDD skills when you're struggling with the language syntax and how to get the tests to run. Next time I facilitate I'll try to be clearer about using a familiar environment for most of the sessions.

One of the things I offered in the last session was using the cyberdojo, and three pairs agreed to try it. I had them working in Java and Ruby, switching pairs every 5 minutes, coding in a browser window. They complained about the browser experience compared with their IDEs, but they liked the feedback cyberdojo gives you. It shows how long you spend between running the tests, and whether the tests pass, fail or give a compiler error.

I'm not sure if it was a good idea to bring in the cyberdojo at the code retreat. One of the main things we discussed in the retrospective for that session was the resistance they all felt to changing the first test that was written at one of the three pairing stations. This test was too big and focussed on a boring part of the problem. Yet each person who "inherited" the code tried their best to make it pass, no-one started over with a better test. It's that kind of collaboration problem that the cyberdojo is good at highlighting. It's not so much a tool for improving your coding skills as improving your collaboration skills. This is good, but not really the purpose of the code retreat.

Thinking back over the day, I've also become a little uncertain about the "delete your code" rule. I understand why it's there, but it didn't seem to prevent people from trying to solve the whole problem in 45 minutes. By deleting the code, you also lose the opportunity to use analysis tools like those in the cyberdojo to give you some more feedback on how you're doing.

Outside of this code retreat, I've been trying out the codersdojo client quite a bit recently, to see if it gives a useful analysis of a coding session. Unlike cyberdojo, it lets you use your normal coding tools/IDE. So far it's still in beta testing and seems too buggy for me to recommend, but if you're lucky enough to successfully upload your coding session, you do get quite a good visualization of some of your coding habits. It will clearly show if you spend a long time between test runs, or if you spend a lot of time with failing tests.

So after my first code retreat, I'm feeling very encouraged that this is a good format for becoming a better coder, and I'd be happy to run one again. I'd like to try using coding visualization tools as part of the retrospective for each session. I'd also like to try setting the challenges before people have chosen a pairing partner, so they can find someone who also wants to work on my challenge rather than just try a new language. Or maybe I just need to emphasize more that trying a new language isn't the focus of the day.

In any case, I hope this blog post shows that I learnt a lot from facilitating this code retreat, even if I didn't write a single line of code myself :-)

* "You can call it beautiful code when the code also makes it look like the language was made for the problem" -- Ward Cunningham quoted in "Clean Code" by Bob Martin.
** G6: Code at Wrong Level of Abstraction - advice from "Clean Code" by Bob Martin.

Refactoring Kata fun

2011-08-25T15:18:00.000+02:00

I've been working on a kata called "Tennis"*, which I find interesting, because it is quite quick to code, yet is a big enough problem to be worth doing. It's also possible to enumerate pretty much all the allowed scores, and get very comprehensive test coverage.

What I've found is that when I'm using TDD to solve the Kata, I tend to only enumerate actually a very small number of the test cases. I generally end up with something like:

Love-All
Fifteen-All
Fifteen-Love
Thirty-Forty
Deuce
Advantage Player1
Win for Player1
Advantage Player2

I think that's enough to test drive a complete implementation, built up in stages. I thought it would be enough tests to also support refactoring the code, but I actually found it wasn't. After I'd finished my implementation and mercilessly refactored it for total readability, I went back and implemented exhaustive tests. To my horror I found three (of 33) that failed! I'd made a mistake in one of my refactorings, and none of my original tests found it. The bug only showed up with scores like Fifteen-Forty, Love-Thirty and Love-Forty, where my code instead reported a win for Player 2. (I leave it as an exercise for the reader to identify my logic error :-)

So what's the point of TDD? Is it to help you make your design good, or to protect you from introducing bugs when refactoring? Of course it should help with both, but I think doing this practice exercise showed me (again!) that it really is worth being disciplined and careful about refactorings. I also think I need to develop a better sense for which refactorings might not be well covered by the tests I have, and when I should add more.

This is something that my friend Andrew Dalke brings up when he criticises TDD. The red-green-refactor iterative, incremental rhythm can lull you into a false sense of security, and means you forget to stop and look at the big picture, and analyze if the tests you have are sufficient. You don't get reminded to add tests that should pass straight away, but might be needed if you refactor the code.

So in any case, I figured I needed to practice my refactoring skills. I've created comprehensive tests and three different "defactored" solutions to this kata, in Java and Python. You can get the starting code here. You can use this to practice refactoring with a full safety net, or if you feeling brave, without. Try commenting out a good percentage of the tests, and do some major refactoring. When you bring all the tests back, will they still all pass?

I'm planning to try this exercise with my local python user group, GothPy, in a few weeks time. I think it's going to be fun!

* Tennis Kata: write a program that if you tell it how many points each player has won in a single game of tennis, it will tell you the score.

Books on automated testing

2011-08-09T11:00:00.001+02:00

As I mentioned in my last post I've recently taught a course in automated testing to a bunch of students at KYH. Before the course I spent some time looking for good course books for them. I looked at a few options and eventually decided on "The art of Unit Testing with examples in .Net" by Roy Osherove, and "The RSpec Book" by Chelimsky et al.

I chose the unit testing book because Roy does a good job of describing the basics of test driven development, including simple mocks and stubs. The book is very practical and is full of insight from experience and code examples.

I also looked at "Pragmatic Unit Testing in C# with NUnit" by Andrew Hunt and David Thomas. I'm a big fan of their book "The Pragmatic Programmer", so I had high hopes for this one. Unfortunately I was rather disappointed with it. It talks about what good unit tests should look like, but not much about how you use Test Driven Development to create them.

I chose the RSpec Book because it has quite a bit of material about Cucumber and how it fits in to a Behaviour Driven Development process. I think the published literature on automated testing focuses too much on unit level tools, and there is not enough written about feature level tests and how to use them as part of the whole agile process.

I also looked at "Bridging the Communication Gap" by Gojko Adzic, which I think is an excellent introduction to how to use feature level tests as part of the agile process, but it is largely tool agnostic. There is a short chapter introducing some tools, including JBehave, a forerunner to Cucumber, Selenium and TextTest too. It's a little out of date now though, and for this course I wanted something with more detail.

I hope these short book reviews are useful.

Teaching a diverse bunch of Testers

2011-06-22T20:42:00.001+02:00

I've just spent 3 weeks teaching a class of 11 students about automated testing, as part of a one year course in software testing. The course is organized by the local "Kvalificerade Yrkes Högskolan", KYH. (loosely translated: Skilled Trade University). The students come from all kinds of job backgrounds, from sitting in a supermarket checkout to driving trams to gardening, and most of them had never written a computer program before the course started.

The KYH tries to design their courses so that students will be competent enough to get a job by the end of them, so they work closely with local employers to set the curriculum and find teachers for the courses.

I was pleased to be asked to do this teaching job, since automated testing is one of my main areas of expertise, but at the same time I was quite daunted by the prospect. I've never taught non-programmers before, and I've certainly never had to set an exam or hand out grades. Before I agreed to do it, I spent some time talking to a friend of mine who has previously taught a different KYH course, and his story actually wasn't all that encouraging. It's hard work preparing the teaching materials, and some of the students will find it very difficult and need a lot of help and coaching. I decided it could be worth doing, anyway. I had some teaching materials prepared already, and I wanted the chance to invent more, try out some new ideas, and broaden my horizons.

Now that I've done the course I can attest that it really is hard work preparing lessons and exercises, and some of the students do need a lot of help. It is very rewarding though when they start to understand. I got a real kick out of going round the classroom seeing them all starting to write tests with Selenium and Cucumber, and answering their questions about Ruby and Page Objects and how to name tests and what to assert, and where to put the code and which parts to write tests for...

I think by teaching this course I've learnt a lot myself about things like how to communicate ideas, give feedback and encouragement, and to set boundaries and manage expectations. I found marking their work much more interesting than I expected, too. What kinds of mistakes do inexperienced programmers make when doing TDD? Do they find it easier to write good tests with Selenium or Cucumber? Is there any correlation between testing skill and programming skill? (short answers - they don't refactor enough, Cucumber is way easier, and no, the correlation seems pretty weak)

So do I recommend getting involved? Absolutely! I think the IT industry in general needs more people in it from diverse backgrounds, and this is the kind of course that brings them in. If my experience is anything to go by, you'll work hard but you'll learn a lot from the students too. Networking with the other employers in the course Industry Reference Group is useful, and if I was looking to hire a junior tester I'd now know exactly who to ask first. Actually, who knows, in a few years some of my students might even be in a position to give me a job.

Don't just complain that it's hard to hire qualified people and/or people from diverse backgrounds. Get down to your local KYH equivalent and help them set up a course! I think that being a good software developer or tester is not restricted to only those with a degree in Computer Science. A course at a trade school where local employers get involved is good value for everyone.

Nordic Ruby and Diversity

2011-06-21T12:03:00.001+02:00

This is the second time I've attended Nordic Ruby, you can read about what I thought last year here. This year I enjoyed the conference more, for several reasons. There were some small changes in the way it was organized, (on a Friday and Saturday instead of taking up a whole weekend), a better choice of speakers and topics, (less technical, more inspirational), and I knew more of the people there.

One of the themes of the conference was diversity, which I was very, very happy to see. There was an inspiring talk by Joshua Wehner about this topic, taking up some depressing statistics about the IT industry in general and open source software in particular. What struck me most was that he said the statistics for women involvement are improving in many formerly male-dominated disciplines, like maths, physics and law, but in computing, the situation was actually better 20 years ago than it is now. The curves are pointing the wrong way in our industry.

Having said that, there were slightly more women at the conference this year than last, I think I counted 4 of 150, compared with 2 of 90 last year. There were also far fewer references to science fiction movies from the speakers this year ;-)

Joshua did take up several things that we could do practically to reduce bias and positively encourage diversity. He's written about some of them in this blog post. Another one he mentioned that I liked was the "no asshole rule". If people engage in arrogant one-upmanship, talk down to others, and emphasize their superior programming abilities, they should be regarded as not just annoying, but actually incompetent. Developing software is a multi-faceted skill, and it takes a lot more than just writing good code to be a good software developer.

Joe O'Brien continued the diversity theme in his talk "Taking back education" by basically arguing that having a degree in computer science correlates very badly with being a good software developer, and that we should be finding ways to bring people into our industry who have non-traditional backgrounds. He advocated companies to start apprenticeship programmes, while conceding that this model of education doesn't scale very well. He talked about getting a group of companies together to set up a "code school". He said "forget universities when it comes to education [of software developers]. We're better at it"

I applaud his efforts to bring a more diverse range of people into the industry, and I think my recent experiences teaching a group like this are relevant. I think I'll write a separate blog post about that experience, but basically I think the idea of a "code school" is a good one, and similar institutions probably already exist, and could add a course in software development to their programme of courses in practical skills. For this to happen it's up to companies to put in time and energy setting them up, rather than just complaining that when they put out a job advert, all they get are white male applicants between the ages of 25-35, so it's not their fault.

Another talk that deserves a mention is the one by Joseph Wilk. He spoke about "The Limited Red Society" which is an idea that Joshua Kerievsky came up with. I heard Joshua speak about it at XP2009, and I thought Joseph did a very good job of explaining what it is, and why it's important.

Basically the idea is that although you need your tests to go red during TDD, if they stay red for any length of time, it can get you into trouble. While they are red, you can't check in, ship your code, or change to working on a different task. This is one motivation for trying to measure, and limit, how much of the time your tests are red. It's also about more generally improving the feedback we get for ourselves while we work. Professional sports stars spend time analysing and visualizing their performances (where balls land on a tennis court, footballers rates of passing etc). We programmers could benefit from that kind of thing too.

Joseph has invented a tool that helps him to track his state when doing TDD. It's a simple monitoring program that makes a note every time he runs his tests. It's not as elaborate as the commercial tool offered by Joshua Kerievsky's company, but it does work with Ruby and Cucumber. Joseph also has his tool connected to his CI server so that it runs tests that have failed recently in his and others' checkouts first in the CI test run. He also gathers statistics about individual tests, how often they fail, and whether they are fixed without the production code needing to be changed - a way of spotting fragile tests.

I think this kind of statistics gathering is really interesting and I think Joseph will just have more insights to share as he gathers more data and does more analysis. I've been experimenting with the tool provided by codersdojo.org for measuring my performance at code katas, but Joseph seems to be taking this all to the next level.

Overall I thoroughly enjoyed Nordic Ruby. (I still think it would be improved by some actual open space sessions though). I talked to loads of really interesting people, enjoyed good food and drink in comfortable surroundings, and listened to some people give excellent talks. Thanks for organizing a great conference, Elabs.

TDD in terms of states and moves

2011-05-10T16:25:00.000+02:00

The classic description of TDD that most people know is the 3 rules by Bob Martin. I think his rules are a very succinct description, and for a long time I've just relied on them, together with a picture of "red-green-refactor" to describe TDD to newcomers. More recently I've found value in expanding this description in terms of states and moves.

When I'm doing TDD in a coding dojo using the Randori form, I get people stepping up to take the keyboard who've never done it before, and I find it helps them to understand what's going on if I explain which state we're in and what the legal moves are for that state. The picture I've used is like this:

I'd like to go through each state and some of the moves you can make in each.

I think before we start on a TDD coding session there is value in doing a small amount of analysis and planning. In the dojo, I'll spend around 15 minutes in this starting state before we start coding. We'll talk about the chosen kata so everyone hopefully understands the problem we're going to solve. We'll write a list of potential test cases on a whiteboard, and identify some kind of "guiding test". This is an overarching test that will probably take us a couple of hours to get to pass. It helps us to define the API we want to write, and the goal for our session. We may also talk a little about how we'll implement the solution, perhaps discuss a possible data structure or algorithm.

I know the group is ready to move on when we have sketched a guiding test or goal for the session, and have chosen the first test we'll try to make pass.

When we're getting to red, we're trying to set up a small achievable goal. We'll choose a simple test from our list, one that will help us towards our session goal (guiding test). This test should force us to address a weakness in our production code.

Starting with naming the test then writing the assert statement helps us to focus on what the missing functionality is. Then we can fill in the "act" and "arrange" parts of the test. I'm not sure who invented the "Arrange, Act, Assert" moniker for structuring tests, but the idea is that a test has three parts. In the "Arrange" part you set up the objects the system under test will interact with, in the "Act" part, you call the production code to do whatever it is, and in the "Assert" step, you check it did what you expected.

In a compiled language it helps to fill in a bit of production code while we're writing the test, but only just enough to keep the compiler quiet. Once the test executes, and is red, you can move on.

This is where we flip over to the production code (I've seen newbies presented with a failing test trying to edit the test to make it green!).

If we can easily see what the implementation should be, we might just write it, but often it helps to return some kind of fake value, until we work out what the code should be. Sometimes in this state we find the test we wrote is too hard, and we need to get back to green by removing or commenting out the failing test. This is a sign we understand the problem better than we did before, which is a good thing. In that case, we'll go back to "Getting to red" and write a better test. Otherwise, we get to green by making the new test pass.

The refactoring move is where we want to remove fake implementations, refactor away code smells and improve code readability generally. Don't forget there may also be duplication and readability problems in the tests as well as the production code. The trick is to do a series of small refactorings that taken together lead to a better design. Try to stay only a few keystrokes away from a running system (green tests).

While we're looking for refactorings, we'll probably spot weaknesses in the production code implementation - functionality that is missing or cases that are not handled. This is a cue to note new test cases, not to fix the code. If we find a hard coded return value, say, we should be able to think of a new test case that will force us to write a better implementation.

We can move on when we're happy the design of the code is good (for the test cases so far).

At some point hopefully we'll find we can get our guiding test to pass, and/or that we're out of time and the coding session is over. We'll look through the code a final time, (as we check it in, maybe), then take a few minutes to reflect on what we learnt during this coding session. In the coding dojo, we'll spend some time discussing what was good and bad about this dojo session, and what we might do differently next time based on what we've learnt.

The cycle begins again with the next coding task or the next dojo session.

DynCon, Scandinavian Developer Conference and XP2011

2011-02-28T21:53:00.000+01:00

The programme for DynCon has just been published, and the whole conference is about dynamically typed languages. There are talks about all sorts of languages, old and new, and I think it's going to be really interesting to get people together from all these different communities. I'm giving a talk with title "A Test-Driven Introduction to Python" where I'm hoping to show off some of the best features of Python. I'll also be demoing a new testing tool called "CaptureMock" which my husband Geoff has invented. I'll be interested to hear what all the afficionadoes of other languages think of both it and python.

The programme for Scandinavian Developer Conference has been up for a while now, and I'm very pleased with the way its looking. The conference will be held in Göteborg in April, and I'm responsible for a whole track called "Conversation Corner". I'm delighted so many people have agreed to take part, and I think we'll be discussing some really interesting topics. I'm hoping it will be a really interactive part of the conference, as a complement to the other 10 tracks which mostly comprise presentations.

The programme for XP2011 also came out last week, although it is not yet complete. I'm Industry Chair for this conference, which will be held in Madrid in May, and I blogged before about my long association with this series of conferences. For this year, I'm still talking to people about putting together panel debates and discussions, and we also have space for more demos and lightning talks. The programme of tutorials and workshops is pretty much complete though, and I think we've got a great lineup of people leading them.

So I've got a very busy spring ahead of me with all these fantastic conferences coming up, and I'm thoroughly looking forward to all of them :-)

Online resources for Coding Dojos

2011-01-30T22:28:00.001+01:00

If you're running a coding dojo, or if you're an individual who likes to practice code kata, there are a number of websites which aim to help. In this post I want to review some of what's out there.

http://codekata.pragprog.com/
The idea of the code kata was originally presented by Dave Thomas in his blog. This is the list of Kata exercises he originally suggested. The dates on the site say 2007 but it must have been at least a couple of years before that*. Some of these katas don't actually involve writing any code, such as kata three. The focus is on general programming skills rather than TDD in particular.

http://codingdojo.org
The idea of practicing code kata in a group and calling it a Coder's Dojo was presented by Laurent Bossavit and Emmanual Gaillot at XP2005. Codingdojo.org is their site for the community, and has some helpful information if you're looking to join or set up a dojo. There is also a catalogue of Kata descriptions. In the past I've personally contributed quite a bit of material to this site, but I've recently become frustrated with the amount of spam on it.

http://web.cs.wpi.edu/~gpollice/Dojo.html
This is an article rather than a whole site, but it gives one of the best summaries of a coding dojo that I've seen on the web.

http://katacasts.com
Corey Haines set up this site in 2009 and his original intention seemed to be to publish a screencast of a kata performance each week. Unfortunately the most recent screencast on the site is from July 2010. There is a lot of good stuff on there to watch, though - notably versions of the StringCalculator kata in almost any programming language you can think of. I really like the idea of screencasts of katas, since for me katas are all about practicing the moves of TDD and becoming expert with your language and editor/IDE. I'm not half as interested in the code you end up with than the route you took to get there. I like that Corey and others comment on the various performances and people learn from watching each other.

http://cyber-dojo.com
As I understand it, Jon Jagger created this tool to help development teams improve their collaboration skills. He's been round several conferences using it as a kind of game for learning about practices such as pair programming, clean code, TDD, and all the people issues related to working in a team. It's a fun activity for a group of programmers to do together, but to get the most out of it I think you need a facilitator who will help you understand what was happening and what there is to learn from it.

http://codingkata.org
This site still claims to be in beta, but there is quite a bit of material already. The philosophy seems to be to try to get people to have fun by playing with code, and also to learn new languages. There's no particular emphasis on TDD. There is a catalogue of katas, and for each one it provides starter projects you can download into your IDE. When you think you're done, it will check your solution for correctness and let you upload the code for public viewing. There doesn't currently seem to be any support for uploading screencasts, or giving people comments and feedback on their solutions.

http://codersdojo.org/
This site is also quite new, but seems very promising. The aim seems very much to encourage collaboration, feedback, and becoming better at TDD - key elements of a face-to-face coding dojo. It provides tools that analyse your performance of a kata, not at the level of 'does the code work by the end' but at the level of 'what were the moves you made to get there'. Each time you run the tests it records the code before and after, and whether the tests passed or failed. There are tools to let you go through a kata performance, look at the moves made and suggest improvements to the performer.

At present the only language supported is Ruby, but that is a great language for practicing TDD in :-) There is also no catalogue of katas to try - it just points to codingdojo.org.

What sites have I missed?
There are a number groups holding regular coding dojos in various parts of the world, and many have their own websites. Several of these are also full of helpful information, but they're not quite what I'm after. I'm looking for sites that are addressed to the whole online community. Please write me a comment and point out sites I should know about!

* Laurent and Emmanuel credited Dave Thomas with the idea in 2005 when they presented the coder's dojo, Jeff Attwood credits him in and article dated 2008, and wikipedia says he published code katas before Jan 2006.

Launch of my company website

2011-01-19T13:23:00.000+01:00

I’m very excited to announce the launch of my company website, at http://bacheconsulting.com. The site has information about the coaching and training I offer, links to this blog, my videos on YouTube, and my twitter feed. My hope is that it gives an indication of my areas of expertise, and what you can expect if I come to work with your development team.

The site was built for me by my friend James Pink, who was very helpful with ideas for site layout and content. He also created my company logo from some sketches I did, and a rather dodgy photo of me hanging my head upside down with one ringlet of hair sticking out. Quite a tricky shot to take by yourself, even if your phone does have two cameras!

The pictures on the site are mostly from conferences - happy memories of good sessions at Agile 2008, XP2009 and XP2010. I’m very grateful to all the photographers for giving me permission to use them. I enjoyed searching through all the conference pictures, these guys really know what they're doing with a camera, and seem to catch just the best moments. The profile shot I’ve been using for a couple of years now was taken by my friend Margaretha Schölin, when we were in China on a business trip together. More happy memories, thanks Maggan :-)

I’d also like to thank the people who agreed to be quoted saying nice things about the work I’ve previously done with them. I’ll return the favour sometime soon, I’m sure.

So now all that remains is to hope that some more companies (preferably those in or near to Göteborg) will notice my site and want to hire me to help them learn agile engineering practices!

Agile Coach Camp Norway

2011-01-17T15:18:00.006+01:00

I travelled to Oslo last weekend, to take part in Agile Coach Camp Norway. This was an open space conference organized by some enthusiasts, not for profit. I became interested in going to the conference when I heard some other agile coaches tweeting about it. I’ve just started my career as a kind of agile coach, and I’ve always enjoyed the open space parts of other conferences I’ve attended. I hesitated though, since I have quite a technical focus. What clinched it was when Johannes Brodwall signed up - an excellent programmer who shares my interest in using Code Kata for teaching and learning Test Driven Development.

I was surprised to see Bob Martin in the hotel reception when I arrived - he had come on a whim since he was in Oslo that day. He spent some time on the first evening telling the story of how the agile manifesto came about, and his involvement. He’s an impressive speaker, even when improvising. Bob didn’t stick around for the rest of the conference, and he missed out on some really good discussions.

We began the main part of the conference with a “coaching dojo”, which Rachel Davies invented by analogy with a coding dojo. It was fun practicing coaching one another, and getting feedback from people who are used to giving good feedback. It really set the tone for the whole weekend.

After lunch, we had the open space opening session, and loads of sessions were proposed. I suggested 4, and ended up being very pleased I'd done them. I got some great feedback about a short coding dojo I ran - being coached in my facilitation skills was very valuable for me, and the participants seemed to appreciate learning more about the coding dojo format I use.

It turned out that Johannes and I weren't the only technically-focused people there, and we shared lots of ideas about code katas and teaching TDD. Everyone agreed that success with agile needs developers to change the way they work, and most struggle with TDD. "Parachuting" a trainer in for a couple of days might help developers understand they could work differently, but getting them to actually make changes is much harder. I'm hoping for some success with repeated regular coding dojo sessions with a team. I'll have to report back when I have more experience of actually doing this.

Another highlight was discussing using games for teaching agile, and in particular teaching agile engineering practices. Jon Jagger has his “cyber-dojo” collaborative programming game that he has released open source, and a “Kanban 1’s game” which he uses for teaching teams about limiting work in progress, and keeping work items small. We talked about the fact that many games are released under the creative commons attribution license, and coaches share them with each other. The games in themselves may take time and effort to create, but Jon and many of the other coaches there felt they don’t lose by sharing them, quite the opposite. They get feedback from others and help to improve the games. I wondered if they were worried about losing business to cheaper rivals who just took their materials, but people seemed confident that the skill of the facilitator is so crucial in the success of a game in achieving learning goals for the participants, that they would not lose out.

It was an intense weekend, with a couple of lovely walks in the snow, and good food together with interesting company. I learnt a lot about coaching and made new friends. I’ll be looking out for similar conferences in future :)

Teaching programming

2010-12-16T12:57:00.008+01:00

The world need more and better programmers. Jason Gorman recently wrote this post encouraging people to start offering software apprenticeships, as an alternative to computer science degrees.

He writes:

"our computing education in [the UK] is preparing students for a career in a version of computing most of us don't recognise. Students devote the majority of their time learning theory and skills that they almost certainly won't be applying when they get their first proper job. Computing schools are hopelessly out of touch with the reality of computing in the real world. While employers clamour for TDD or refactoring skills, academics turn their noses up at them and focus on things like formal specification and executable UML and compiler design, along with outdated and thoroughly discredited "software engineering" processes." -- Jason Gorman

Jason ends his post with a call to arms - if you're a good software developer, get yourself an apprentice, and start training them. It's the same message I heard from Dave Hoover when he visited Göteborg recently. I think he also sees a multi-year apprenticeship as a better alternative for training programmers than a computer science degree.

I also recently came across this article, written by a computer science teacher in the US, with the following paragraph:

"I no longer teach programming by teaching the features of the language and asking the students for original compositions in the language. Instead I give them programs that work and ask them to change their behavior. I give them programs that do not work and ask them to repair them. I give them programs and ask them to decompose them. I give them executables and ask them for source, un-commented source and ask for the comments, description, or specification. I let them learn the language the same way that they learned their first language. All tools, tactics and strategies are legitimate. " -- William Hugh Murray

So clearly some academics are teaching in creative ways. Rather than abandoning computer science degrees, might it not be better to improve their content?

One of the things about the XP conference is that it brings together industry and academics, and lets them hear from one another. How to teach programming is a very important topic that is often discussed there. XP2005 for example was held at Sheffield university, where I remember chatting to one of the professors, and being impressed by the way they used eXtreme Programming as part of their undergraduate course.

Another thing that happened at XP2005 was the first coding dojo I attended, and I believe the first one ever held outside of France. It was presented by Laurent Bossavit and Emmanuel Gaillot, founders of the Paris dojo. I was excited to discover a context in which I could improve my practical programming skills, in regular short bursts, alongside a continuing paid job.

So one of the things I do in my new life as an agile testing consultant is to use the coding dojo format to teach people how to program better. We'll do code kata exercises and practice Test Driven Development, Refactoring, and discuss what Clean Code looks like. So far the reaction from professionals I've done this with has been very positive. Lots of people who have been coding for years appreciate the chance to learn new practical skills.

I'm also getting involved in more formal education, this spring I'm teaching a three week course in automated testing, as part of a "Kvalificerad Yyrkesutbildning" in software testing. This is a one year full time course for students wanting to learn a practical skill, as an alternative to going to university and studying a more academic subject. In Sweden you can get a student loan while you're studying this course, and part of the time is spent working in a company gaining on-the-job experience.

I'm starting to plan how I'm going to teach TDD, BDD, and how to use tools like Selenium, Fitnesse, TextTest and Cucumber. I think it's going to be very hands on and practical, but also go into the general principles behind tool choice and writing maintainable automated tests. I'm helping to write a formal syllabus and exam, with criteria for grades awarded.

I guess what I'm trying to say is that I don't like this strand of thought in the Software Craftsmanship movement that wants to abandon formal education. There are lots of ways to train software developers, and apprenticeship isn't without its problems.

I think this is just the sort of thing we'll be discussing at XP2011, where there will be a host of academics and experts from industry. Won't you join us?

XP2011

2010-12-09T10:27:00.007+01:00

I've just been appointed to the role of Industry Programme Chair for XP2011, which will be held in Madrid in May. I've been to 7 of the previous 11 XP conferences and I am so pleased to be asked to contribute to the success of the conference this year by doing this role.

Rachel Davies is the general chair, and I am really looking forward to working with her and the other organizers. Rachel is one of those people I have met repeatedly at conferences and always has something interesting to contribute. More recently, I read her excellent book on Agile Coaching. I can't remember exactly when I first met her, but I do remember meeting her former colleagues from Connextra, Tim MacKinnon and Steve Freeman. I can still picture them in the small minibus that picked us up from a tiny Italian airport in 2002. It was a hot summers day, and we were driven at high speed along small Sardinian roads to the lovely hotel Calabona by the sea and the historic walled city of Alghero. I remember being so impressed to meet some people who were actually doing eXtreme Programming for real.

There were so many inspirational people at that conference, it was really a turning point in my career. I just found the old conference programme online here, and it brings back so many memories!

I remember sitting by the pool discussing subjects like how to test drive refactoring with Frank Westphal and Steve Freeman. There was a firey keynote from Ken Schwaber encouraging us to start a revolution in software development world. I remember Joshua Kerievsky asking Jutta Eckstein to explain all about how she was doing XP with a team of over 100 people. Following David Parnas' keynote about using a formal test specification language to define requirements I remember Martin Fowler opining about its usefulness or lack of it, (do read his blog post about it).

The colourful personality of Scott Ambler demonstrated his ability to break a plank of wood in two with his bare hands, as some kind of lesson to do with dedication and focus. The conference dinner at Poco Loco really was a little crazy, with a bunch of uncoordinated geeks going for it on the dancefloor while the local band played very loudly. The morning after everyone was rather subdued when listening to Enrico Zaninotto reading his keynote in halting English, relating XP to the history of manufacturing and modern lean ideals. Half the audience was having trouble staying awake which in no way reflected the quality of what he was saying. It was truly inspiring, and Mary and Tom Poppendieck in particular were listening in rapt attention.

Michael Feathers wore a T-shirt saying "Save the LSF", and Geoff and I asked him why he was so interested in platform computing's Load Sharing Facility. It turned out Alan Francis had recently become unemployed and Mike was helping in the campaign to "Save the Lightly Scottish Fellow"!

Laurent Bossavit was going round trying to attract people to his Birds Of a Feather session on the writings of Gerald Weinberger. Erik Lundh was taking about his team in Sweden who had done a complete XP iteration in 2 days when faced with an unexpected deadline. Steven Fraser seemed to be videoing everything and anything, including someone demonstrating the correct way to twirl Italian Spaghetti on a fork. Mike Hill was (as ever) being loud but friendly. Charlie Poole seemed to be full of insightful analogies and comments. Dave Hussman was really friendly too.

It was just fantastic the way the XP community welcomed us in, and particularly Kent Beck's attitude was instrumental in that. My husband Geoff and I presented a poster at the conference with title "One suite of automated tests" based mainly on Geoff's experiences with the tool that was to become TextTest. We turned up on the first day for a workshop about "testing in XP", and Geoff was immediately controversial by saying that he didn't do any unit testing, only this weird text-based testing thing using log comparison. He said he found it so successful that he used it instead of both the XP practices of functional and unit testing. I remember several people being quite dismissive of his ideas.

Later in the conference, Kent Beck made a particular effort to talk to us and we took our picture standing by our poster. Apparently he had been asking people to try to be inclusive and friendly to us after the somewhat negative reaction to our ideas. I think he wanted the newly-forming XP community to be welcoming and to embrace diversity of opinion.

So now I should turn this around and look instead to the future. I'd love it if even half the people I've mentioned in this post found time in their diaries to come to Madrid in May for XP2011. I wouldn't want them to come alone though, there are so many fantastic and inspirational people who have joined the ever-expanding agile community since 2002.

I am every bit as keen now as Kent was then to see that the agile community embraces newcomers, and that the XP conference should provide a space where researchers and practitioners can freely discuss the state of the art. I hope we'll make new friends and business contacts, learn loads, and have fun. Would you like to join us there?

Django

2010-12-03T09:18:00.004+01:00

Last night at GothPy we had a play with Django, a web application framework for Python. I'm fairly familiar with Rails, so it was interesting to see a different take on solving the same kinds of problems.

I downloaded Django for the first time when preparing for the meeting, and spent about a day going through the tutorial and trying stuff out. At the meeting were a few people who have used Django before, notably Mikko Hellsing, who has worked with it daily for several years.

It was so much easier learning the tool from people who knew it than by reading the documentation. Constant code review and real time answering of questions is just brilliant for learning.

At the meeting we decided to implement a very very simple web application, similar to the one that Johannes Brodwall performed as a Kata at XP2010 together with Ivar Nilsen. He calls it "Java EE Spike Kata" since he does it in Java with no particular web frameworks, just what comes with Java. (There is a video of him doing it on his blog, and sample solution here on github).

I thought we should be able to implement the same little application in any web framework, and it might be interesting to see differences, so I though we should try doing it in Django. It just involves two pages. One page "Add User" which lets you create a new user and save it to the database, and another page "Search User" which lets you search for users, and presents results. So the scenario is to create a user, search for them, and see they are returned.

When I work on a problem in Rails I usually start with a Cucumber scenario for the feature, and I discovered there is a python version of Cucumber called Lettuce. We could have course have just used Cucumber with python, but given the big "WARNING - Experimental" notice Aslak wrote on this page, I thought we could give Lettuce a try.

So at the meeting we all worked together with one laptop and a projector, (me at the keyboard), and we started with a Lettuce scenario. We implemented step definitions using Django's test Client, which is a kind of headless browser that understands how to instrument a Django application. Then we spent a couple of hours writing Django code together until the scenario was all green.

The code we ended up with isn't much to write home about, but I've put it up on github here.

What we learned from this exercise
Of course since I know Rails much better, I found it interesting to compare the two web frameworks. Django seems similar in many ways. It was dead easy to get up and running, it gives you a basic structure for your code, and separates the model from the presentation layer.

The O-R mapping looks quite similar to ActiveRecord in the way you declare model classes backed by tables in the db. The presentation layer seems to have a different philosophy from Rails though. The html view part is rather loosely coupled to your application, and doesn't allow you to embed real python code in it, just basic control structures.

You hook up the html to the controller code using url regular expression matching. I was a little confused about exactly how was supposed to work, since what I considered controller code was put in a file called "views.py". Most of the code we wrote ended up in here, and I feel a bit unhappy with it. It seems to be a mixture of stuff at all levels of abstraction. The Django Form objects we used seemed quite powerful though, and reduced the amount of code we had to write.

The biggest difference I noticed compared with Rails was how explicit Python is about where stuff comes from. You always have to declaratively import or pass stuff before you can use it, so I found it straightforward to follow the connections and work out which code was executed and where it came from. I think that is because of Python's philosophy of strict namespaces, which Ruby doesn't have so much of.

I also liked the way Django encourages you to structure a larger web application into a lot of independent smaller ones, and lets you include and re-use other people's small apps. Rails has plugins too of course, but I thought Django's way made it seem very natural to contribute and re-use code.

Comparing Lettuce to Cucumber, they look almost the same, (by design). One small difference I found was that Cucumber step definitions don't care if you write "Given", "When" or "Then" in front of them, whereas Lettuce did. So I had steps like this:


Then I should see "results found"
And I should see "Name"

where the first step passed and the second step was reported as unimplemented by Lettuce. So Lettuce need a little more work to be really usable.

I was also pretty disappointed by the Django test client for implementing test steps. It seemed to interact with pages at an abstraction layer lower than I am used to - at the level of making post and get requests and parsing html as a dom. I missed Capybara and its DSL for interacting with web pages. I couldn't find any equivalent. I probably should have turned to Selenium directly, but since we had no client side javascript it seemed overkill. (Francisco Souza has written about using Lettuce with Selenium compared with the Django test client here).

When it comes to unit-level testing, Django provides an extension to the normal unittest tool that comes with python (unittest was originally based on JUnit). We didn't do much with it at the session, and it seemed to work fine. It's nothing like RSpec though, and I miss that expressiveness and structure for my tests whenever I work in Python.

Overall
All in all it was fun to look at Django with a group and to get some really helpful comments and insights from people who know it far better than I do. The Kata we chose seemed to work ok, but I should really do it again in Rails since I spent the whole time comparing Django with Rails in my head, not Django with Johannes' Java code :-)

My conclusions are basically that Django looks like a good alternative to Rails. It would take time to learn, and surely has strengths and weaknesses I can't really evaluate from one short session looking at it. However, I'd fairly sure I'd have to do some work improving the testing tools if I was going to be happy working with it for real.

KataMontyHall

2010-11-01T11:04:00.006+01:00

I was at the local Ruby User Group last night, and I coded up KataMontyHall (see below) as a prepared Kata in front of the group. I got some great comments and feedback while I was coding, and I think the solution I ended up with was better than any I had created by myself during my practice sessions. I also got some new ideas about different approaches which I plan to try out and see if they improve the code even more.

Dave Hoover was visiting from the US, on his way to a speaking engagement at Öredev. He and I were both surprised to discover a common interest in the Monty Hall Dilemma. Dave has previously worked on it, and he showed us some code that he wrote 5 or 6 years ago when he was still learning Ruby. He even wrote an online version of the game when he was first learning ajax, that you can play yourself!

The Monty Hall Dilemma
There is a gameshow hosted by Monty Hall where contestants try to win a big prize, which is behind one of three doors. The contestant begins by choosing a door, but not opening it. Then Monty steps forward and opens one of the other doors. He reveals a goat (!). Then the contestant has the choice of either sticking with the door they have already chosen, or switching to the other unopened door. Whichever door the contestant decides on will be opened, and if they find the prize, they get to keep it. (I'm not sure what happens if they get the second goat!) So what's the best strategy? Stick or switch?

People are biased towards sticking with what they've chosen, and the vast majority of people stick with the door they choose originally. Intuitively there should be an equal chance of the prize being behind any of the three doors, so it shouldn't matter if you stick or switch. However, in this case, your intuition is wrong. You are twice as likely to win the prize if you switch to the other unopened door.

I am not the only one to think this result is incorrect, apparently famous mathematicians have also refused to accept it. What finally convinced them, was a computer simulation. Hmm I thought, that sounds like an interesting piece of code :-)

Pigeons are smarter than Humans
I heard about the Monty Hall Dilemma listening to the quirks and quarks podcast. Apparently humans are strange, because they don't learn to switch doors. Some researchers set up the same problem for pigeons, with birdseed behind one of the doors, and found the birds quickly learnt to switch doors. You can read the research for yourself!

So if you, like me, are keen to prove yourself more intelligent than a pigeon, why don't you spend some time writing a little program that simulates the game? If you get it right, your version of KataMontyHall should clearly show that switching doors is the best strategy :-)

Agile Testing Days - day 2

2010-10-07T07:54:00.008+02:00

On the wednesday of Agile Testing Days it was my turn to speak, and together with Fredrik Wendt we presented "The Coding Dojo as a forum for teaching Test Driven Development". The talk was mostly aimed at developers, and the basic idea is to encourage them to learn TDD, and that going to a coding dojo might be a good way of doing that.

Michael Bolton
The first keynote of the day was by Michael Bolton, someone I've never met before. His talk really made me think. He presented himself as an "agile skeptic", and had some criticisms of agile practices like automated unit and functional testing. He talked about testing as something that humans do - it is a "sapient activity" requiring an engaged brain. He said "Automated acceptance tests do not answer questions about value" - that is whether the software will be valuable to the people who are going to use it. He preferred to call them "rejection checks" - that is they check whether the software will be rejected, but do not test whether it will be accepted. Only a human can do that. Michael went on to question the large level of investment that agile teams make in these kinds of tests. He thought that effort could perhaps be better invested, when studies show only 6-15% of problems are regression issues.

Michael emphasized the role of testers in projects as "skilled investigators" who provide a service giving you information about a software product. He drew on an analogy with a film critic - they don't tell you if the film has passed or failed, they tell you about the attributes of the film that will appeal more or less to certain audiences.

I liked the way Michael talked about testing as an investigative activity, and the role of testers as intelligent humans. I think he undervalues the feedback developers get from automated functional tests though. Agile teams do a lot more refactoring than other kinds of teams, and I think without automated tests they would have a lot more than 6-15% regression issues. I do think it is useful to evaluate investment in automated tests against other investments though. Some of the tools we have, particularly for functional/system level testing are not very cost effective to use.

I also think that testers can only start doing a "film critic" kind of role when the software is largely free of basic defects. These should be caught before a skilled tester gets their hands on the software, by developers properly checking their work, and automating those checks.

Agile Testing Days - first conference day

2010-10-06T09:14:00.004+02:00

Yesterday, Geoff gave his talk about agile GUI testing. For anyone who missed it, here is a video of him giving roughly the same talk earlier this year at Europython. Gojko Adzic has also blogged about what he said, which is exactly the kind of feedback we came to this conference for. In his post Gojko explains Geoff’s testing approach, and seems quietly positive about it, at least compared to the “sine of death” you get with other UI test automation tools. His conclusion that it looked more suitable for legacy code than greenfield development is a little uncomfortable though. We think it works there too :-)

Today I’m giving my talk about teaching Test Driven Development via Coding Dojos. I’m looking forward to some feedback from the community about that. In the meantime I’ve written a bit about the three keynote talks we listened to yesterday.

Lisa Crispin

The day started with a keynote from Lisa Crispin titled “Agile Defect Management”. The overall message was to “lower the bar!” and aim to reduce defect count as far as possible, even to the point where a defect tracking software becomes superfluous. There was a lot of talk about whether such a tool was needed, and in what situations, and she gave a good overview of the state of the art of thinking in this area.

This was a good talk, with audience involvement, by someone who knows what they are talking about. The thing is I have higher expectations from a keynote. I expect to come away inspired and challenged, with some new insight to take back to my daily life. For me, this talk didn’t really deliver that. Lisa concentrated too much on the specific question of whether to use an electronic defect tracking tool or not, and didn’t sufficiently put that question in to the wider context given in the title of the talk “agile defect management”. I was disappointed to find nothing really original or surprising in what Lisa said.

Linda Rising

This was a good talk to hold straight after lunch when everyone is a bit sleepy. Linda spoke very amusingly on the subject “Deception and Estimation: How we Fool Ourselves”. She began by inviting us to see this as “the weird talk” of the conference, and that she was going to go through some of the latest scientific research in the area of cognition and psychology and hoped to relate that to why we have such trouble making good estimates in the context of a software project.

A self-confessed scientific amateur, she stated up front that she wouldn’t provide references to the research she mentioned, although she could give them to you if you emailed her and asked. Linda then proceeded to relate a series of amusing anecdotes designed to illustrate how irrational and over-optimistic people can be. (Markus Gärtner has blogged about what they all were). Towards the end of the talk, Linda began to relate all this to the subject of estimation, and told a story about some conference where she met people who were trying to apply scientific methods, statistics and data mining to the problem of improving estimates in software projects. In my mind, a seemingly a rational response to the problem of irrational, over-optimistic people.

Linda then did what I saw as a complete about-turn in her argument. She quoted one proponent of this “scientific” approach as saying, “well we can’t just make up a number, can we?”. Well no, we can’t, Linda just spent the last half hour convincing us humans are over-optimistic and irrational, and you can’t trust them to make up numbers. Yet that seemed to be exactly what Linda then proposed we do in agile. The points about the way agile overcomes this natural human over-optimism by for example breaking down problems into thin slices, using the wisdom of the crowd and enforcing tight feedback cycles, all kind of got crammed in at the end with little or no explaination.

Quite apart from those specific criticisms of her argument, as someone with a scientific training I didn’t like the way Linda protrayed science and scientists. They initially appeared in Linda’s talk as white-coated oracles who make pronouncements of the truth. “80% of drivers think they are above average”. “You eat more at an all-you-eat buffet”. “Online daters lie about their age and weight”. She then attempted to shatter this illusion of scientific infalliability by quoting Planck, who pointed out that the scientific process doesn’t always proceed in an orderly manner, and sometimes new and better theories only really catch on when the older generation who invented the previous ones atually die off.

Yes, scientists are human too, and you do them a disservice when you only present their results as received truths, without references, and without explaining either the methods they used to reach the conclusions, or what they themselves think of the wider applicability of the results.

This could have been a far more interesting talk about actual recent research studies - what’s coming out of the latest brain imaging techniques, for exaple. Linda could also have spent more time explaining how agile works with human nature to provide better estimates and plans. For all that it made me laugh, all this talk left me with was a bunch of amusing anecdotes and an uneasy feeling that agile was anti-science.

Elisabeth Hendrickson

The last session of the day saw Elisabeth Hendrickson presenting “Lessons Learned from 100+ Simulated Agile Transitions”. With a huge amount of energy and panache, Elisabeth strode around the stage, explaining what happens in an exercise which she usually does with a group of 8-20 people over the course of a whole day. Within the framework of this simulation, she drew out stories and anecdotes to illustrate such diverse subjects as the Satir change model, how physical layout affects communication, the difference between status meetings and communication meetings, and tests as alignment tools.

This talk was definitely the highlight of my day. Elisabeth took some things I kind of knew about, and made me think about them in a different light, from a different angle, and in a new context. I was challenged to go back to my standup meetings and make sure they really are about communication, and that my task board really does make status visible. I have a additional way of explaining ATDD to people - in terms of aligning developers and other stakeholders and getting them moving in the same direction.

Having said all that, I do have a criticism (are you surprised?!). Elisabeth released her slides under the creative commons license, but she does not release the details of her simulation. This would effectively prevent anyone else from running it. I think this is rather like a tool vendor who presents a new testing approach, which by the way, you can’t use without either buying their tool, or spending a large amount of time and money developing your own version. Those kinds of talks don’t tend to get accepted at this kind of conference.

I was disappointed that Elisabeth didn’t release her simulation materials, and I’m not sure why she doesn’t want to. She is obviously a fantastic agile coach and facilitator, and has more invitations to speak than she has time or inclination to accept. It would surely only enhance her reputation to make the agile transition simulation game materials available.

Update: I talked to Elisabeth afterwards about her materials, and she related a story about another independent consultant she knows, who arrived at a client site ready to do a simulation exercise that he had designed, only to discover the participants had done the exact same exercise the week before with a different consultant! The other consultant had just taken the material without permission or acknowledgement. Elisabeth doesn't want to end up in the same situation, and I can understand that. She did say she could release more information about the simulation though, enough that you could understand how it is designed, and perhaps build your own similar one. I think that would be a reasonable compromise. I just felt slightly cheated after her keynote - I wanted to look at this simulation, poke at it, see how it works and understand why she could use it to generate so many great insights into agile transitions.

Tutorial with Lisa Crispin at Agile Testing Days

2010-10-05T08:03:00.004+02:00

I’m at Agile Testing Days this week, and yesterday I attended a tutorial with Lisa Crispin. I’ve never actually met her before, although I have read many of her articles, and the book she wrote together with Janet Gregory, “Agile Testing”. It’s an important book, covering in some detail the role of testers in agile teams, with lots of practical advice and anecdotes from real life.

So I was very interested to meet Lisa and hear what she had to say. She had lots of general advice and war stories about what kinds of tools are useful in an agile setting. From all the new insights and thoughts I gathered from the tutorial, there were two stories that I’d like to share with you here.

The Whole team decides
Lisa’s main message was that automated testing tool choice is a whole team decision, since everyone on an agile team will be affected. She told a story about when she joined a team of Java programmers and persuaded them to try Watir for web testing - a tool that lets you write tests in Ruby. Although the developers agreed to this and were initially keen to learn Ruby, it became clear after a while that they just weren’t comfortable with it, and Lisa found she just didn’t get the help she needed when extending and maintaining the tests. They switched to a tool where the tests were written in Java and things worked much better.

That depressed me a little, I have to say. I’d personally much rather be writing Ruby than Java! Someone else chipped in with another story though. On his team they were also developing a system in Java, with the difference that the developers were very keen to learn Groovy. They had started writing tests using it, and it was working very well. It made writing tests more fun, since they got to learn a language they were interested in. The test automation work was less effort than expected, since they felt much more productive in Groovy than Java. I guess the difference is that the developers were motivated to learn the new language because they had chosen it.

You can do ATDD with GUI testing tools
Lisa told an interesting story about GUI testing. She said she was working on some new features and realized that the only way to test them was was via a GUI testing tool. She was at first very skeptical that they would be able to do Acceptance Test Driven Development with a GUI tool - the GUI hadn’t been written yet, so how could they use this tool to write tests?

In the end she said it turned out really well. They worked from GUI mockups of the new features, and wrote tests with placeholders. When the test scripts needed to interact with GUI elements that didn’t exist yet, she just wrote them in terms of what she’d like there to be there, based on the mockups. When the programmers came to implement the GUI, they could fill in the placeholders and quickly get the new tests running.

This was encouraging since it’s basically the way you work with PyUseCase too. A criticism we get sometimes is that since PyUseCase is a capture-replay tool, you can’t use it to define the tests before the GUI exists - a problem if you’re trying to do Acceptance Test Driven Development. Our experience matches Lisa’s though - you can define the test in general terms, with placeholders, and parts that won’t execute at all at first. Some parts of the test of course can be recorded from the existing GUI. As the GUI is extended for the new feature, gradually you replace the placeholders with executable statements until the whole test passes.

And now for the rest of the conference...
Geoff is giving a talk this morning about PyUseCase and TextTest as part of the main Agile Testing Days conference. We’d really like to get some feedback from experienced testers. It’s a different approach to capture-replay that most people here, like Lisa, will not have seen before. There are lots of other interesting talks and things going on too, and I hope to find time to blog a little more about the conference later in the week.

Coding Dojo Survey Results

2010-09-24T12:27:00.017+02:00

A little while ago, Fredrik Wendt and I put together a little survey and sent it to all the people we know who have attended coding dojo meetings here in Göteborg. There are several groups in the city which run these kinds of meetings from time to time. We wanted to know what kinds of things people are learning from practicing code katas in a group, and get some feedback and comments to help us to develop the groups we run.

The survey got 29 responses - thankyou to everyone who participated! I was very encouraged to see that the overwhelming majority - 90% - said they would recommend the dojo to other people who wanted to improve their programming skills. There were lots of comments too - I won't include them all - but I particularly liked:

"Dojos make me relive the joy of red-green-refactor”

“you learn a lot from each other at these meetings”

“... planting seeds that have improved me as a programmer and a problem solver”

“I have started to think in terms of TDD”

The first question asked people which dojo(s) they had been to.

Fredrik and I set up JDojo@Gbg about a year ago, as an free coding dojo for Java programmers, sponsored by Iptor. We advertized it as a taught course - 5 sessions, once a month, come and learn TDD. We ran it twice together, and now Fredrik is continuing it together with Ola Berg.

The second sort of coding dojo going on in the town is various language user groups. It must be four years since I pestered Niclas Nilsson and CJ that we should do code Katas at Got.rb (Göteborg Ruby User Group). Inspired by the success of that group, and together with Andrew Dalke and Johan Lindberg, I set up GothPy (Gothenburg Python User Group) about two years ago. More recently, Jonas Nicklas set up Got.js (Göteborg javascript user group) and Jörgen Lundberg set up Scala Geats (Göteborg Scalaenthusiaster). So there are several small, language specific groups that meet and do dojo evenings occasionally, interspersed with other activities.

The third kind of coding dojo meetings going on is where people run them internally at their employer, which lots of people do from time to time. In addition, Fredrik and I are both facilitating these kinds of groups at clients, as part of our work coaching teams and encouraging them to be more agile.

I was pleased that people from all these sorts of groups filled in the survey, and that many people had been to more than one kind.

Most of the survey respondents had been to 4 or 5 dojo meetings:

We asked several questions about perceived skill level before and after participation in dojo meetings. We wanted to know what people thought they were learning, basically.

As you can see, people were fairly good at the programming language in question before the dojo(s), and only reported marginal improvements, 0.3 on average, on a five point scale.

When it comes to the IDE used in the dojo, again, we are looking at a modest improvement, also 0.3 on a five point scale.

Using Mock Objects is a topic that doesn't always come up in dojo meetings, I personally have certainly had more of a focus on classic TDD. The feedback shows that people didn't feel they were that good at it before the meetings, and not that much better afterwards - an average 0.5 increase on a 5 point scale. From some of the comments, I think this is an area to focus on more in future. To that end, we're having a GothPy meeting next week looking at Mockist TDD :-)

Refactoring is an essential part of Test Driven Development, and in fact any modern programmer's toolbox. I was pleased to see that people thought the dojo had helped them to improve this skill too - 0.5 on a five point scale.

So it looks like going to a dojo encourages you to write unit tests more often - 0.6 (on a five point scale) more often on average.

This result is the most pleasing to me, since I think TDD is such an important skill, and it can be so difficult to get going with. People are moving from a low level of skill up to a medium level of skill - a whole 1 point (on a five point scale) on average! No-one is claiming to be a TDD expert yet though, I will have to repeat the survey in a few years and see if anyone is brave enough to claim that by then ;-)

Fredrik and I are off to Agile Testing Days in a week or so, where we'll be presenting a bit about what we've been doing at these various groups, and what we recommend for others starting their own coding dojos. We've learnt a lot by running these meetings, and had fun too. Hopefully these survey results might encourage you to find a coding dojo and improve your programming skills!

What to do next

2010-06-19T21:33:00.010+02:00

I had fun for a few months programming Ruby at eLabs, but now I'm moving on*. What exactly I'll be doing next is not entirely clear. My plan, at least initially, is to work as an independent consultant specializing in automated testing and agile coaching. I'd also like to do some contract Ruby or Python programming. Hopefully I will find customers who are willing to hire me to do those things on a part-time basis, or with short term contracts, so I can do a mixture.

I have a long term dream to build some kind of product around PyUseCase and TextTest. I really believe in the approach Geoff has built for testing rich client python GUIs, and I'd like to see if it could be adapted for testing web applications. I have some ideas I'd like to try out, but I'll need to find real customers with real applications and problems to try them out on. I'm hoping that will be possible through the agile testing consulting that I'll be doing.

I'd also like to develop the idea of the coding dojo as a forum for teaching Test Driven Development and related agile engineering practices. I'm certain there is more that could be done to help people to get going with these skills. I'm looking into what courses are currently offered by local training providers, and hoping to both teach and develop those courses. I'm also working on my own formal training course based around the JDojo@Gbg meetings I led last year.

As you may have noticed from previous posts, I really enjoy going to conferences, and often speak at them. I don't expect that to change much :-) Geoff and I are both scheduled to speak at Agile Testing Days in Berlin in October, which I am really looking forward to. It'll be a chance for us to learn from some of the best in our industry, and share some of our ideas. Geoff's testing tools are developing all the time, and I'll be talking about what we've learnt from the many dojo meetings going on in Göteborg. I'll be speaking together with my friend and former colleague Fredrik Wendt, a stalwart member of GothPy and assistant leader of JDojo@Gbg.

So it's an exciting time for me, and I have several activities lined up to get me going with my new business. I'm also hoping to find a bit more time to spend writing articles for this blog. We'll see if I succeed!

* eLabs is a very young company with only about 8 employees, and after I agreed to join CJ and his team back in January the company strategy changed a little. After I started in March, my role didn't work out the way I'd anticipated. CJ and I had a good talk about it, and I think it's with no hard feelings on either side that I left the company at the end of June.

Programmer Conferences are like Games

2010-05-25T10:53:00.010+02:00

Why are there so few women programmers? That's a big question. How about a related one that's slightly smaller: Why do so few women go to programmer conferences?

Nordic Ruby on Twitter
Nordic Ruby was clearly appreciated by many of its attendees. See tweets like this:

ronge: #nordicruby - best conference ever, looking forward meeting you all next year ! Lots of food for thoughts. Really sad it's over.

skanev: #nordicruby was just awesome. Thank you guys

walming: Got so much inspiration. Big thanks @elabs for #nordicruby conference.

Very few Women
What I also noticed was, that of around 100 delegates, only 2 were women*.

I have to say, I go to a lot of conferences, which gives me plenty to compare it to. In addition to Nordic Ruby, in the past year I have been to: Scottish Ruby Conference, Scandinavian Developer Conference, JFokus, Smidig, Europython and XP2009. In general, I really enjoy conferences, and none of those I've mentioned had a huge proportion of females. Nordic Ruby was not exceptional in that respect. However, although I enjoyed Nordic Ruby, it does not feature in my all-time favourite list. I'll come to why in a minute. A lot of things about the conference were very good, of course. Some of the talks were excellent, and the venues, food and parties were absolutely top knotch.

The format of of the conference was 30 minute talks (all on one track) interspersed with 30-120 minute breaks. The last session of each day was open and any attendee could give a short "lightning" talk, and many people did so. Every speaker, lightning or otherwise, had a large audience, since there was nothing else on the programme.

Hampton Catlin's talk - the two kinds of Games
My favourite talk was one by Hampton Catlin, talking about how to make applications attractive to their users. He talked a bit about the different kinds of games that people prefer. Perhaps I can expand this idea to explain why I don't rate Nordic Ruby as highly as some of the other attendees clearly did.

Hampton explained that computer games lie on a scale from Male-Oriented to Female-Oriented. They are called by those names because your physical gender is a good predictor of which sort you will prefer. (He stressed that you should keep in mind that people are complex, defy easy categorization, and a given individual could have preferences anywhere on the scale.)

The Male-Oriented game will let you score points and rank yourself against opponents. The Female-Oriented game will let you build supportive social networks with collaborators, and become admired by your peers. Hampton said that most computer games are Male-Oriented. He highlighted some exceptions, including Farmville, which is a popular game on Facebook. In fact, he said Facebook itself can be seen as a Female-Oriented game.

Programmer Conferences are like Games
This got me thinking about the Nordic Ruby conference. If Facebook can be seen as a game, can you see a conference that way too? Do attendees play for "score" and "rank"? Is the programmer's conference game so Male-Oriented that most women just aren't interested in playing?

The Conference as a Male-Oriented Game
If a programmer conference is a Male-Oriented Game, it will provide you with opportunities to improve your rank and score compared to other attendees. For example, giving a talk will let you show off the cool software project(s) you have created/contributed to. You can improve your rank by criticising other people's code, and contrasting it with the beauty of your own. You can also score "geek points" by making gratuitous references to obscure programming languages, advanced mathematics and classic sci-fi films.

Your overall conference success is measured by how many people subsequently download your open source projects, and how many followers you gain on Twitter.

The Conference as a Female-Oriented Game
If a programmer conference is a Female-Oriented Game, it will provide you with opportunities to form supportive social networks and gain admiration. Lecture-style talks aren't so good for that, so the conference will schedule sessions for attendees to have conversations with each other, and collaborate. The conference programme will raise discussion topics that interest attendees, and encourage idea sharing. There may be organized group sessions where you share programming-related problems, pool your ideas and collectively come up with strategies to move forwards. You will gain admiration by being insightful, charming and subtly drawing people's attention to your open source projects, while also being admiring of others' projects.

Your overall conference success is measured by how many people subsequently contribute to your open source projects, and how many friendly messages you get on Twitter.

Who Won Nordic Ruby?
Ok, I'm stretching the analogy rather, (!) but I'd say the Nordic Ruby conference game was a little too Male-Oriented for my liking. The focus of the programme was on lecture-style talks, and, put it this way, the speakers made way too many references to Star Wars! There were long breaks, which gave many opportunities for conversation, but there were no formal network-building activities. There was lots of time for chatting, but no mechanism to draw people together around, say, a discussion topic, or a collaborative coding exercise.

The conferences I have enjoyed most have involved relatively few lecture-style talks, and largely comprised of workshops, coding dojos, tutorials, conversation corners and open space discussions. Next week I'm going to XP2010 (which will be my seventh XP conference :-D), and it's the first ever GothPyCon this Saturday. At both I am organizing coding dojo sessions - collaborative excercises in collective learning and mutual appreciation. Bring on the Female-Oriented conference games!

* There was also two other females there, but neither are programmers.

Python and Ruby and small methods

2010-04-30T21:33:00.003+02:00

I've been working full time in Ruby now for about a month, and I think I'm beginning to get the hang of it. In many ways it's not so different from Python.

I took some of the code I talked about struggling with in my last post, and set about translating it into Python. I wanted to see if the bugs were more obvious in a language I was more familiar with. Unfortunately before I was finished with the translation, my machine died and refused to restart, complaining about a disk error... so I may well have lost all my work. (ARRRGH!!) Anyway, before that happened, I was getting the feeling that the bugs weren't very obvious, even in a language I knew better.

What I did find though, was that it was quite hard to make the methods as short in Python as they were in Ruby. I could make them as short, the language has the necessary features to do it, but when I did so, they just stopped looking like good Python to me.

The other thing that I found was that RSpec lets you write really readable and well organized tests. Translating them into unittest made them just a travesty of their former selves.

I've just listened to this talk by Gary Bernhardt, who is experienced in both Python and Ruby, and who has clearly thought quite hard about these kinds of issues and knows both languages very well. He has even tried to write a RSpec clone for Python, called Mote. (He says himself that it isn't as good as RSpec, and that it is because Python lacks blocks, and won't let him monkeypatch core classes).

Anyway, about half way through the talk, Gary shows this code example, first in Python:


'\n'.join(obj.name
    for obj in (
        repository.retrieve(id)
        for id in ids)
   if obj)

Then the equivalent code in Ruby:


ids.map do |id|
 repository.retrieve(id)
end.compact.map do |obj|
 obj.name
end.join('\n')

Gary makes the point that the Ruby code is easier to read - you can follow it from top to bottom and see what it does. The thing is, I don't think many people would write code like that in Python. I might write it more like this:


objs = [repository.retrieve(id) for id in ids]
objs = filter(lambda x: x, objs)
names = [obj.name for obj in objs]
'\n'.join(names)

This code is four statements long, rather than one, and has two local variables ("objs" and "names") which the other two code snippets lack. In real code, you would probably be able to come up with rather more descriptive names, drawn from the problem domain. When I compare this code with the Ruby, I don't think it is any less readable. The filter(lambda x: x, objs) is not as nice as the Ruby call to "compact", but on the other hand, I think the two additional local variables make it clearer what is going on.

I'm wondering whether the trouble I was having locating bugs in these small methods was because they were cramming so much into one statement, and almost completely lacking in local variables. That seems to be the Ruby way of doing things - maybe I will just get used to it and learn to read it just as well eventually? I guess I am going to find out!

Anyway, I'm really hoping the friendly support technicians manage to save the contents of my hard disk, I want to use the code in an exercise at the upcoming Gothenburg Python Conference - GothPyCon. I am hoping to run a workshop where half the room gets the buggy code with small methods, and the other half gets the same code refactored into longer methods. You get half an hour to find the bugs, then swap to the other codebase and find them again. Then I was hoping to have a discussion about which codebase was easier to debug, and/or split into pairs and re-implement the code from scratch, and see if we could come up with other designs that solved the problem more elegantly and transparently.

If issues like this interest you - design, refactoring and testing -, I really hope you will come along!

Small methods, TDD and defects

2010-04-06T21:41:00.003+02:00

Last week at Scottish Ruby Conference I chatted with Brian Marick about software design. The week before that, he had been in Göteborg for Scandinavian Developer Conference, and had spent a morning pair programming with Geoff on TextTest. I took the chance to ask Brian what he thought about text-based testing now that he had seen it in action.

Brian's view seems to be that text-based testing may be effective as a testing technique, but it just doesn't offer the design benefits you get with standard TDD. It doesn't give you guidance about small-scale design decisions, or intice you to structure your code into really small methods and classes. He thought the TextTest codebase wasn't bad, but that the methods were larger than he would prefer, some classes were doing too much, and some ideas were not expressed clearly.

I've previously read about this design ethic of having really really small classes and methods in Bob Martin's book "Clean Code". Bob recommends one or two line methods. In contrast, I believe Steve McConnell's "Code Complete" advocates methods small enough to fit comfortably on one screen. Geoff's design for TextTest seems to land at about 5 or 6 lines for a typical method, which is somewhere in between.

Brian said the main drawback of code structured largely into small classes and one and two line methods is that it is harder for people who are unfamiliar with the codebase to get to grips with it. You get lost in the trees, and can't easily get an overview of the forest. The big benefit is that people who are familiar with the code can potentially make sweeping improvements through very small, localized changes.

I've had the opportunity to work on this kind of codebase recently, and my experience hasn't been entirely positive. Just as Brian predicted, I've found it hard to get into the code and grasp what it is doing. All the methods are one or two lines, and call each other. My pair and I ended up creating a temporary file where we pasted a whole call chain of about 6 methods so we could see them all at once, and read them in the order they called each other. There were 3 defects hidden in that 15 or so lines of code, and it took us a day or so to identify and fix them all. Yet, the code had been TDD'd, and the methods were well named. On the surface it looked very good. It actually took me some time to convince myself that we genuinely had found a defect, and that we hadn't just misunderstood what the code was supposed to do.

The trouble seemed to stem from the fact that almost all the tests were for the "happy path" and there were several edge cases they never considered. Also, in one case the test had stubbed out the answer that one of the lower-level methods would return, and provided an answer the real code never gave. It took a long time for us to add missing tests for edge cases, and localize the defects to particular methods in the long call chain.

I'm very interested in whether we would have found it easier to find the defects if the code had been structured as two or three 5 line methods instead of 6 one and two line methods. I'm also interested if we would have found the issues more easily if the code had been built with text-based testing, with fewer, more coarse grained tests, and a few log statements printing key intermediate values. I'm considering getting the original versions of the files out of git and refactoring them to see how else they could have looked.

I don't want you to conclude that I am against building designs with really small methods, or TDD, or using stubs or anything like that. I think there is value in all these techniques, each can be done well or badly, and you make tradeoffs when you choose your approach. You still need design skills and testing skills, whether you're doing TDD or text-based testing. If Brian Marick had built TextTest the design might well have turned out differently. I don't know how much of that would have been because of his use of TDD, and how much because of his skill, and views on design.

I'm actually relishing the prospect of working on more code with very small methods, and using TDD to build on it. I've got loads to learn about software design and testing :-)

Discussion on TDD at SDC2010

2010-03-17T21:10:00.004+01:00

As I mentioned in my last post I chaired a fishbowl discussion at SDC2010 with title "Should a professional developer always use Test Driven Development?". I was delighted that the invited panelists Michael Feathers, Geoff Bache and Andrew Dalke all turned up, along with a few dozen other conference participants. As I predicted, we had a lively and interesting debate.

Michael half-jokingly complained that Bob Martin goes around making these controvertial statements all the time, which Michael then gets to go around defending. Michael has a much more conciliatory attitude than Bob, and his take was that every truly professional developer must have at least given TDD a good try and learnt the technique, even if they then decide not to use it.

Geoff's main point was that we need to widen the definition of TDD to include any process that involves checking in tests at the same time as the code, and not restrict it to just the classic Red-Green-Refactor style with tests in the same language as the code.

Michael was largely receptive to this view, or at least that the soundbite description of "never write any code until you have a failing test" probably was a bit too brief description to encompass the whole of TDD. He did argue though, that the classic TDD style leads to code with good design characteristics of high cohesion, loose coupling, small classes and methods etc, and that he had not found other design techniques which led to better code than TDD. He was not keen to move to a TDD approach without unit tests, and lose these benefits, even if they result in good tests.

Andrew argued that TDD is not sufficient by itself to produce a good suite of tests, and that there are other, better ways to produce these tests. Andrew pointed out that he had examined Fitnesse, a codebase that Bob Martin, (and some others), has created using TDD, and that he found several bugs, including security holes in it. Michael's counterargument was that with TDD, you get as good tests as you are capable of - if you are not skilled/aware of security issues, then you won't test for security holes, whatever process you use to create tests.

Another argument of Andrew's was that he often likes to write tests that he expects to pass, to verify that his code works as expected, for example that he has implemented an algorithm correctly. In the narrow definition of TDD, you are only allowed to write tests you expect to fail. Michael's take was that this was indeed a too narrow definition of TDD. He said that he frequently writes tests as a way of asking questions of his code, and this often leads to tests that pass straight away.

Some of the "audience" also stepped up to the microphones and joined in. Brian Marick pointed out that forcing yourself to write the test first was a very good way of ensuring you do actually write the test, instead of being lazy and just writing more code. The counter to that was along the lines of that there are other processes for arriving at a good test suite, which took different kinds of discipline. Andrew quoted the sqlite project, which boasts 100% branch coverage of their code by their test suite. Publishing your coverage figures and refusing to let them slip is a way of preventing developer laziness too.

Brian Marick wrote an article about coverage and tests over a decade ago, so he summarized it for us, which was interesting, but I think slightly beside the point. I think he was trying to argue that measuring coverage alone is not enough to guarantee you have a good test suite, but I don't think that was what Andrew was trying to claim. Simply doing TDD is not a guarantee that you will end up with a good test suite either.

For me, the interesting outcome of the discussion was pointing out that the alternatives to TDD are not only "cowboy coding" or "test later, ie never", or "bad tests", but that there are other legitimate ways to come up with a good test suite, and professional developers may choose to use them instead of classic TDD. TDD is a discipline which all professional developers should perhaps have in their repertoire though. I think we agreed it is also a teaching aid for learning to write good tests.

Happily, we definitely all agree that creating a good automated test suite alongside code is important. The precise method a professional developer should always use to produce it was not agreed upon though.

Should a professional developer always use TDD?

2010-03-04T20:53:00.003+01:00

I'm really looking forward to Scandinavian Developer Conference, and in particular the fishbowl discussion I'll be moderating on the Tuesday at 10:30am. Presenting their views will be Michael Feathers, Andrew Dalke, and Geoff Bache, and the topic under discussion is the same as the title of this post: Should a professional developer always use TDD?

I've been enthusiastic about writing automated tests for my code since 2000 when I discovered eXtreme Programming, and started using JUnit. It's become a habit for me to write tests before code. Occasionly I decide not to, perhaps I am feeling lazy, or think a test would be too difficult to write. I find I usually regret it and end up writing a test afterwards anyway.

One of the things Bob Martin, (a colleague of Michael Feathers), says about TDD in his book "clean code", is that it is a matter of professionalism. Developers should be like doctors. Would you trust a doctor who didn't wash her hands because she didn't belive in it? Well, you shouldn't trust a developer who doesn't use TDD because she doesn't believe in it.

I've known Andrew Dalke since 2002, and we've worked together on and off since then. Recently he wrote this article criticising TDD. Andrew does not believe TDD is necessary for good development work to happen. Is he unprofessional? Far from it.

My experience of working with Andrew tells me that he is an excellent programmer, who produces high quality code and automated tests. However, the process by which he arrives at this code and tests is not TDD. Tests get written during development, but not in advance of the code they test. The tests do not in any way drive the design, in fact, he uses knowledge of the design of the code to inform what tests he writes.

Andrew says in his article "Once I have a good sketch of how the code is going to be, I often continue by filling in the details. At this point unit tests starts to be useful" he likens what he does to an XP spike solution, except that he does not throw away the spike code and start over when he starts adding tests.

The other person I know who has a complex relationship with TDD is my husband Geoff. Several years ago he was labelled a heretic and almost thrown out when he admitted to a room full of XP enthusiasts that he didn't write unit tests at all. Geoff does write tests - a lot of tests in fact - but they are not xUnit tests, and they don't drive the design of his code.

Geoff uses an approach he calls "text-based testing" which involves driving the program from the command line, (or some kind of script), and having his code write a plain text log file of what it is doing. A tool called TextTest picks up the log output and compares it to the saved version from a previous run. Differences are flagged as test failure.

It's a simple idea, but it is actually very effective and easy to use when you get the hang of it. The main advantage over ordinary TDD is that there is little or no code written per test, meaning less code to maintain overall. The fact that the tests are independent of the design of the code makes refactoring easier, and writing tests for legacy code relatively risk-free.

TDD is a bit different with the text-based approach though. Geoff thinks of what he does as TDD, but actually, only half of the test is nailed down in advance of the code - only the part that tells the program which features to exercise. The part that asserts that it did the right thing is simply recorded after the code is written.

So I expect a fascinating and lively discussion to ensue when I get these guys together! Perhaps you'll join us?

developer-in-test role and tester role

2010-02-21T21:04:00.008+01:00

In my current assignment, I'm taking the role of "developer-in-test". I'm working in a large distributed development project, which is building new functionality on a large existing codebase. In practice, I work closely with the developers in the project and build automated tests for subsystems that previously had only manual tests. The developers can use these tests to support their work, and add new tests as they build new features.

My background is basically as a developer, so I have been reading up on testing. I found "Lessons Learned in Software Testing" by Kaner, Pettichord and Bach very helpful, and "Agile Testing" by Lisa Crispin and Janet Gregory helpful and also very thorough. I find it interesting that the authors of the first book started out as developers and now classify themselves as testers, while Lisa and Janet apparently always have called themselves testers, although they clearly write a fair amount of code as part of their work.

Dave Nicolette recently made a blog post "Merging the developer and tester roles" where he argues that Tester is just a specialization of Developer in the agile world, like DBA (DataBaseAdministrator) is a specialization of Developer. He argues that agile teams need to be staffed with generalizing specialists. That means anyone can turn their hand to any task that is currently needed, while still having some tasks they perform with more skill than others.

I like Dave's viewpoint, it fits my experience. I can only write effective 2nd Quadrant tests, (business facing, support the team), if I understand what the developers need, and I do that best if I have done some development on that part of the system myself. To put it another way, I need to be just as competent at writing code as the other developers in the project I'm working in, but I also need additional skills to do with testing.

I like the term "developer-in-test" to describe a role writing and enabling 2nd Qudrant tests.

Having said all that, I'm not sure I agree with Dave that the Developer and Tester roles should always be merged. In my current assignment I'm also helping a group of testers, usability experts, technical writers and product owners to get going with exploratory testing. This testing falls into Q3 of the agile testing quadrants, and is quite different. You still need testing skills, but developer skills are mostly irrelevant. It's much more about understanding what the user is trying to achieve with the system, and how they view it.

I think there is a role for non-coding testers in Q3 testing. However, I don't think you'll get far with Q3 unless you have the other quadrants well covered with automated tests. So I think the majority of work for a tester in an agile environment is still going to involve test automation. Only the biggest projects will be able to afford to have non-coding testers.

XP2010 workshop and lightning talk

2010-02-14T20:27:00.003+01:00

I've just heard that two of my proposals for XP2010 have been accepted, which means I will definitely be off to Trondheim in early June. I've heard Trondheim is very beautiful, and the XP conference it usually excellent, so I'm really looking forward to it. It will actually be my 8th XP conference!

I'm going to be running a half day workshop "Test Driven Development: Performing Art", which will be similar to the one I ran at XP2009, (which I blogged about here). I've put up a call for proposals on the codingdojo wiki, so do write to me if you're interested in taking part.

The other thing I'll be doing is a lightning talk "Making GUI testing productive and agile". This will basically be a brief introduction to PyUseCase with a little demo. Hopefully it will raise interest in this kind of approach.

Perhaps I'll see you there?

code coverage and tests

2010-02-05T20:43:00.004+01:00

At GothPy yesterday, Geoff talked about code coverage and tests. Geoff has spent a lot of his evenings lately working on PyUseCase, and getting the test coverage up to 100%, (statement coverage), a feat which he achieved last week. The evidence for this is available for all to see on the texttest site, (which is updated daily, btw, so if it is not green and 100% the day you read this post, then clearly Geoff had a bad day yesterday).

I have limited experience of using coverage statistics to evaluate my tests, so it was interesting to hear Geoff summarize his findings. He thought it had been well worth the effort to get coverage to 100%, he'd found some bugs, some dead code, and improved his design along the way. Actually, saying he has 100% coverage is a statement that needs qualification. The tool he's been using - coverage.py - has a feature whereby you can mark lines of code as # pragma: no cover, ie I don't want this line counted for coverage purposes. So he's marked 37 of 3242 lines like this.

The reason for excluding these lines is mostly practical - due to the nature of the tool you can't test it automatically when it is in "interactive" mode without physically pressing the buttons yourself - so automated tests for that part are impossible. Some excluded lines are for error cases which should never occur, but for which it would be useful to have a good error message if they ever did.

Overall, Geoff thinks coverage is very useful to help you to identify

poorly tested areas of your code
mistakes in your tests
dead code
refactoring opportunities

The first one is obvious, but the others might take more explaination. Generally, each test is for a specific feature. If you think you have a test for a feature, but the code coverage shows the implementation of that feature not to be covered, then there is probably a mistake in your test.

Similarly, if your tests cover all your features and some code is not covered, maybe it's not that important code at all, and could be safely removed. Geoff's tests are not unit tests, they are testing the whole of PyUseCase, and that maybe makes a difference with this particular point. If I just had unit tests, and a piece of code wasn't covered, I'm not sure I could as easily infer that it wasn't needed as a part of a larger feature.

Refactoring opportunities can be identified from gaps in coverage too. The idea is that poorly tested code is a clue that it has other problems too. Perhaps you find two pieces of code are similar, and one copy has a gap in coverage. This could indicate they originate from copy-paste programming, and could be combined into one routine, with full test coverage.

Geoff had some tips for people who wanted to use coverage statistics to improve their tests.

Don’t design your tests around coverage. Write appropriate tests, and then measure coverage.
This applies even when working with coverage results. See the coverage report as containing clues for new tests, not commands.
Use “#pragma : no cover” in your code to be explicit about code that you decide not to try and cover. Review these periodically.
Don’t be fanatical about absolute numbers. Commands like “Aim for at least 85% coverage” are counterproductive. (You get what you measure).
It’s always good to increase feasible coverage. It’s sometimes better to spend your limited time on other things. But if you don’t measure, you can’t make that decision effectively.

These last points are mostly also made in an article by Brian Marick which is quite old (1997). Geoff found the article when he was researching the talk for GothPy, and thought it was very good, and fits his experience.

Inspired by Geoff's talk, I spent some time today trying to get some coverage numbers for the code and tests I'm working on at present. Unfortunately it seemed to be a bit tricky to get the coverage tool to work. It's not python, of course, and that may have something to do with it. Hopefully I'll sort it out and be able to write a new blog post about my own experiences with coverage statistics sometime soon.

Domain Specific Languages for Selenium Tests

2010-01-27T21:00:00.005+01:00

I gave this talk at JFokus this week in Stockholm. I thought people might be interested in a summary of my main points.

I've been using Selenium for web application testing for over a year now, on a couple of different projects. This talk is based on my experiences.

What is Selenium?

Selenium is actually an umbrella term for a suite of tools. The two tools in the suite I have been using are Selenium Remote Control (RC) ,which allows you to test your webapp as it runs in a broswer, from Java code., and Selenium IDE, which is a Firefox plugin that allows you to record tests.

Selenium's killer feature is that it allows you to test your app while it is running in a browser, with a real browser javascript engine. This is particularly important for web applications with a lot of javascript and ajax. Selenium is also actively maintained, with version 2.0 having recently arrived at alpha release status.

I showed a demo of how to write a test using Selenium IDE to record browser interaction, then pasting that into Java code. The test doesn't pass the first time you execute it, you have to tweak the code to replace xpaths with ids, and add a "wait" for the page to load at one point in the test. I find this is typical - Selenium IDE helps you to get started with your test, but there is still a lot of manual work to get it to pass.

The code you end up with is rather widget-oriented and low level, this is what I end up with in my example:


@Test
public void createNewPublisher() {
        selenium.click("menuItemPNewPublisher");
        selenium.waitForPageToLoad("30000");
        selenium.type("name", "Disney");
        selenium.type("address", "24 Stars Ave");
        selenium.type("zipCode", "91210");
        selenium.type("city", "Hollywood");
        selenium.type("country", "USA");
        selenium.type("contactPersonName", "Emily");
        selenium.type("contactPersonEmail", "emily@test.com");
        selenium.type("contactPersonPassword", "123456");
        selenium.type("contactPersonRetypePassword", "123456");
        selenium.click("save");
        selenium.waitForPageToLoad("30000");
 
        verifyEquals(selenium.getTable("Users.1.1"), "Emily");
}

This is all very well, you can basically read what it is doing, (open the "New publisher" page, fill in a form, then check the user table displays correctly), but I think we can do better.

Agile Testing Theory

Brian Marick came up with this idea of "Testing Quadrants", which helps us to reason about what kinds of tests we need in an agile project. Selenium tests generally fall into the second quadrant - business facing tests that support the team. This implies they should be written in the language of the business, to help developers to understand what they are building. This is in contrast to the low-level, widget oriented script that selenium IDE produces.

It is better to discover a bug as soon after insertion as possible, and the faster the tests run, the more often you will run them. The usual rule of thumb says your tests must take less than a minute for you to run them as part of a TDD cycle, and less than 10 minutes for you to run them in the CI server. For a suite of selenium tests, even 10 minutes can be ambitious.

Selenium tests are fundamentally slow. They are slow because they run inside the browser using its javascript motor.

WebDriver

WebDriver (new in Selenium 2.0) uses a different model of interacting with your application under test. It uses the browser's api instead of its javascript motor. This means tests execute faster and more reliably, at the cost of supporting fewer browsers. In addition, WebDriver has a well thought out, clean api, and built in support for the PageObject pattern. Having said that, WebDriver is a very recent addition to selenium, and currently has poor or no integration with Selenium IDE and Selenium Grid.

the Page Object pattern

The PageObject pattern is a way of organizing your test code. It tells you to model your test code after the page structure of your application. The test I listed earlier could be rewritten using this pattern, and might look something like this:


   @Test
   public void createNewPublisher() {
           PublisherData newPublisher = new PublisherData("Disney")
           .withAddress(
                           new AddressData("24 Stars Ave",
                                           "91210", "Hollywood", "USA"))
           .withContactPerson(
                           new UserData("Emily", "emily.bache@test.com",
                                           "123456"));
       
           NewPublisherPage page = new NewPublisherPage(selenium);
           page.enterPublisherDetails(newPublisher);
           ViewPublisherPage viewPage = (ViewPublisherPage)page.save();
           viewPage.verifyPublisherDetails(newPublisher);
   }

Here we are using a data struct to hold the form data, which tells you quite obviously that a PublisherData has a name, address and contact person. Then we have the Page Object for the NewPublisherPage, which uses selenium to navigate to the relevant page in the constructor, then has methods which allow us to interact with that page. When we as it to "save", we navigate to a new page, in this case the ViewPublisherPage, which we can ask to validate the new publisher is displayed correctly.

This is an improvement over the original test in several ways. I think it is much more readable, we have a certain amount of type safety from the data struct, and if the page flow, or form data changes, there are obvious central places in the code to update all the tests. We can easily vary the form data in different tests in order to do data driven testing.

Scenario classes

However, in the application I've been working on, we havn't used this pattern in quite this way. The application uses a lot of frames and ajax, and a page based model didn't really fit. So we've been using the idea of "Scenario" classes instead of Page Objects. They fulfill the same purpose, but instead of modelling pages in your app, these classes group together domain actions, or services that your application provides. The Scenario classes hide all the details of how to use selenium to interact with the GUI and achieve an outcome a user is interested in. In this case, creating a publisher.


    @Test
    public void createNewPublisher() {
            PublisherData newPublisher = new PublisherData("Disney")
                   .withAddress(new AddressData("24 Stars Ave",
                                    "91210", "Hollywood", "USA"))
                            .withContactPerson(
                                    new UserData("Emily", "emily@test.com",
                                                            "123456"));

            PublisherScenarios scenarios =
                             new PublisherScenarios(selenium);
            scenarios.createPublisher(newPublisher);
 
            scenarios.verifyPublisherDetails(newPublisher);
    }

Domain Specific Languages

So with the PageObject or Scenario patterns, you could say that my tests are written in a kind of Domain Specific Language, in that they are written in terms close to the domain of the application they are testing. The trouble is, this is still Java code, and business people generally can't read Java. A more interesting DSL would enable communication between developers and business people.

This is where I turned to Fitnesse to help me. I found it pretty straightforward to put some Fitnesse tables over the top of this kind of Java code. Since the Java code is already organized in terms of the domain, it becomes natural to offer the same functionality in tables with meaningful names.

I chose Fitnesse because I wanted to try it out, but I think it would be equally easy to put Cucumber or Robot Framework or something like that on top, too. The whole point of these tools is that they allow you to easily write executable tests in a language anyone with knowledge of the domain can read. This is a huge benefit to developers when talking to business people.

Closing advice

Having said all this about how to make your Selenium tests more readable, robust and faster, I still find my Selenium test suite frustratingly slow and fragile (I havn't used WebDriver enough yet to know if that is the case there too). Compared to PyUseCase, it is in the dark ages. (Unfortunately PyUseCase has no support for web applications, so there's probably no point in mentioning it, actually. But it is a great tool!).

The difference between PageObjects and Scenario classes is not huge, but I like the latter, because they allow me to easily exchange Selenium for a WebService. My tests are written in terms of the services the application offers, and if I indeed implement those services as WebServices, I can call them directly from the tests. Using a WebService instead of selenium immediately makes my tests much faster and more robust.

The problem with testing against a WebService is the reason we chose Selenium in the first place - ajax and browsers are not covered.

So for web 2.0 application testing, I recommend both API tests and Selenium tests. Use Selenium to test the crucial parts of your GUI, but write most of your tests against some kind of WebService or API. Write your tests in terms a business user would understand, even in the Java code, and then it is easy to create a Domain Specific Language on top using another tool.

Testing PyTDDmon

2010-01-10T19:53:00.003+01:00

One of the things I like about GothPy is that lots of the people in the group enjoy writing code in their spare time, and like to share with us what they're up to.

A little while back, Olof came up with this little tool, PyTDDmon, which is to help you when you're doing TDD. Instead of your running your tests by hand, PyTDDmon sits in the background and runs them for you. When they are green, it has a little green blob, when they are red, it tells you how many are failing, and clicking on it gives you the stacktrace. Olof put together a screencast to show how it works.

Following Geoff's presentation of PyUseCase at GothPy in December, he and Olof started to discuss whether it could be used to test PyTDDmon. Since it's using the GUI library Tkinter instead of pyGTK, it didn't look all that straightforward.

Of course, Olof developed the app using TDD in the first place, (definite own dog food eating going on!), and his unit tests have about 48% statement coverage. The parts with least coverage are GUI-related, so there seemed to be scope to improve matters by adding tests via the GUI.

Geoff sat down a few days ago with a branch of the PyTDDmon code, started trying to generalize PyUseCase to work with Tkinter, and to write some tests for PyTDDmon. (Geoff also likes writing code in his spare time :-)

As I write, he's just checking in his changes and a new suite of tests for PyTDDmon that use the new, improved PyUseCase, with (basic) Tkinter support! He says the hardest part was understanding Tkinter, and after a spot of refactoring, only an extra couple of hundred lines of code were needed to support it.

Subsequently adding tests for PyTDDmon was very easy (Geoff wrote most of them while I made biscuits with the children this afternoon :-) All he had to do to Olof's code was assign names to some of the widgets, and sort out a problem with closing a window. (There was a listener for a mouse click that would destroy the window, before other listeners got a chance to do anything, such as record the click in a use case log...)

So now the statement coverage of the PyTDDmon tests is at 98%. I look forward to future, equally productive GothPy meetings and discussions!

joining eLabs

2010-01-08T19:56:00.003+01:00

I've enjoyed my time working for Iptor, but I found I just couldn't refuse Carl-Johan when he offered me a job at eLabs. I first med C-J a few years ago at Got.rb, the local Ruby User Group, and I know he has a great entrepreneurial spirit and deep technical expertise. eLabs is his company, (a startup he co-owns with Edithouse), and he's attracted a really competent, friendly bunch of coders to join him. This a chance for me to get to learn Ruby and Rails properly, and work in a truly agile team. Hopefully I'll be able to contribute some insights from my years working with agile advocacy, automated testing, and development in Python and Java. I'm looking forward to starting at eLabs in April.

JUseCase, dreams of resurrection

2010-01-04T22:03:00.008+01:00

JUseCase is the Java version of PyUseCase, for testing GUIs written in Swing. It was originally written as a master's thesis by Claes Verdoes in 2005, under Geoff's supervision. Since then it hasn't been used much, and has lain idle and unmaintained for a while. In the meantime, Geoff has made some major changes to PyUseCase, culminating in the recent release of version 3.0, which I think is hugely better than any competing tools. But then I am biassed :-)

I would love to see JUseCase resurrected and to support more of the features of PyUseCase 3.0. We originally got a lot of criticism of JUseCase that it required too many changes in application code; many developers are leery of changing their code to put in hooks "just for the tests". PyUseCase 3.0 removes the need for much of that, and I think JUseCase could do the same.

In JUseCase, you have to connect widgets to domain actions by adding bits of code like this:


JTextField originField = new JTextField(“ANY");
ScriptedTextField.connect("choose origin", originField, ScriptedTextField.EDIT);

i.e. the text field "originField" should record a domain action "choose origin" when it is edited. This enables JUseCase to record and replay user actions in a domain language, at a higher level of abstraction than just widget names.

In PyUseCase 3.0 these kinds of code changes are replaced by the UI map file. Widgets are identified by name, something like this:


[Name=originField]
edited = choose origin

So all you have to do in the code is make sure all your widgets have unique names. Good names are useful for accessability, (blind people etc), and for internationalization, so you can argue you're not just doing it for the tests.

The second thing that PyUseCase 3.0 does to reduce code changes is to automatically generate the UI log, rather than you having to insert log statements by hand. The UI log is the part of the test definition that TextTest uses to assert the application is behaving correctly. It should be a low-fidelity rendering of what the UI looks like, in plain text.

For example, for the simple application in my last post, the ui log might look like this:


---------- Window 'Book Animals for Procedures' ----------
Focus widget is 'available procedures'
Showing available procedures with columns: available procedures
-> abdominocentesis
-> haircut
-> re-shoe
-> milking ,
Showing available animals with columns: available animals , animal type
-> Good Morning Sunshine | mare
-> Goat 3 | goat
-> Goat 4 | goat
-> Guicho | gelding
-> Misty | mare
Button 'book'

This log is created just by inspecting the GUI elements in turn, and writing out a sketch of their contents.

In order to add to this log as the user interacts with the application, PyUseCase attaches itself as a listener to each widget, so it finds out when they change. Then after the user has done some actions, when the GUI event queue is empty, it takes the opportunity to write a few log statements about what has changed since the last time it logged something. In this way it produces a neat summary of what the user does and what the UI looks like after each action. I should think JUseCase could do something similar.

Then all that is left to hand code is to put in the application events - basically writing a log statement that you're doing something in another thread of execution, that the tests should wait for before proceeding. There shouldn't be too many of those calls, so hopefully they can slip under the radar.

Anyone looking for a masters thesis topic fancy giving it a go?

big UI changes and their effect on tests

2009-12-28T21:04:00.007+01:00

I recently read this post in Brian Marick's blog, and it set me thinking. He's talking about a test whose intention in some way survived three major GUI revisions. The test code had to be rewritten each time, but the essence of it was retained. He says:

I changed the UI of an app and so… I had to rewrite the UI code and the tests/checks of the UI code. It might seem the checks were worthless during the rewrite (and in 1997, I would have thought so). But it turns out that all (or almost all) of those checks contained an idea that needed to be preserved in the new interface. They were reminders of important things to think about, and that (it seemed to me) repaid the cost of rewriting them.

That was a big surprise to me.

I'm not sure why Brian is so surprised about this. If the user intentions and business rules are the same, then some aspects of the tests should also be preserved. A change in UI layout or technology should mean superficial changes only. In fact, one of the main claims for PyUseCase is that by having the tests written in a domain language decoupled from the specifics of the UI, it enables you to write tests that survive major UI changes. In practice this means when you rewrite the UI, you are saved the trouble of also rewriting the tests. So Geoff and I decided to write some code and see if this was true for the example Brian outlines.

In the blog post, there is only one small screenshot and some vague descriptions of the GUIs these tests are for, so we did some interpolation. I hope we have written an application that gets to the gist of the problem, although it is undoubtedly less beautiful and sophisticated than the one Brian was working on. All the code and tests is on launchpad here.

We started by writing an application which I hope is like his current GUI. You select animals in a list, click "book" and they appear in a new list below. You select procedures from another list, and unsuitable animals disappear.

In my app, I had to make up some procedures, in this case "milking", which is unsuitable for Guicho (no udders on a gelding!), and "abdominocentesis" which is suitable for all animals, (no idea what that is, but it was in Brian's example :-). Brian describes a test where an animal that is booked should not stay booked if you choose a procedure that is unsuitable for it, then change your mind and instead choose a procedure that it is suitable for.

select animals Guicho
book selected animals
choose procedure milking
choose procedure abdominocentesis
quit

This is a list of the actions the user must take in the GUI. So Guicho should disappear when you select "milking", and reappear as available, but not as booked, when you select "abdominocentesis". This information is not in the use case file, since it only documents user actions.

The other part of the test is the UI log, which documents what the application actually does in response to the user actions. This log is auto generated by pyUseCase. For this test, I won't repeat the whole file, (you can view it here), but I will go through the important parts:

'select animals' event created with arguments 'Guicho'

'book selected animals' event created with arguments ''

Updated : booked animals with columns: booked animals ,
-> Guicho | gelding

This part of the log shows that Guido is listed as booked.

'choose procedure' event created with arguments 'milking'

Updated : available animals with columns: available animals , animal type
-> Good Morning Sunshine | mare
-> Goat 3 | goat
-> Goat 4 | goat
-> Misty | mare

Updated : booked animals with columns: booked animals ,

So you see that after we select "milking" the lists of available and booked animals are updated, Guicho disappears, and the "booked animals" section is now blank. The log goes on to show what happens when we select "abdominocentesis":

'choose procedure' event created with arguments 'abdominocentesis'

Updated : available animals with columns: available animals , animal type
-> Good Morning Sunshine | mare
-> Goat 3 | goat
-> Goat 4 | goat
-> Guicho | gelding
-> Misty | mare

'quit' event created with arguments ''

ie the "available animals" list is updated and Guicho reappears, but the booked animals list is not updated. This means we know the application behaves as desired - booked animals that are not suitable for a procedure do not reappear as booked if another procedure is selected.

Ok, so far so good. What happens to the test when we compeletely re-jig the UI and it instead looks like this?

Now there is no book button, and you book animals by ticking a checkbox. Selecting a procedure will remove unsuitable animals from the list in the same way as before. So now if you change your mind about the procedure, animals that reappear on the list should not be marked as booked, even if they were before they disappeared. There is no separate list of booked animals.

What we did was take a copy of the tests and the code, updated the code, and see what we needed to do to the tests to make them work again. In the end it was reasonably straightforward. We didn't re-record or rewrite any tests. We just had to modify the use cases to remove the reference to the book button, and save new versions of the UI log to reflect the new UI layout. The use case part of the test looks like this now:

book animal Guicho
choose procedure milking
choose procedure abdominocentesis
quit

which is one line shorter than before, since we no longer have separate user actions for selecting and booking an animal.

So updating the tests to work with the changed UI consisted of:

remove reference to "book" button in UI map file, since button no longer exists
in use case files for all tests, replace "select animals x, y" with a line for each animal, "book animal x" and "book animal y".
Run the tests. All fail in identical manner. Check the changes in the UI log file using a graphical diff tool, once. (no need to look at every test since they are grouped together as identical by TextTest)
Save the updated use cases and UI logs. (the spurious line "book selected animals" is removed from the use case files since the button no longer exists)
Run the tests again. All pass.

The new UI log file looks like this:

'book animal' event created with arguments 'Guicho'

Updated : available animals with columns: is booked , available animals , animal type
-> Check box | Good Morning Sunshine | mare
-> Check box | Goat 3 | goat
-> Check box | Goat 4 | goat
-> Check box (checked) | Guicho | gelding
-> Check box | Misty | mare

'choose procedure' event created with arguments 'milking'

Updated : available animals with columns: is booked , available animals , animal type
-> Check box | Good Morning Sunshine | mare
-> Check box | Goat 3 | goat
-> Check box | Goat 4 | goat
-> Check box | Misty | mare

'choose procedure' event created with arguments 'abdominocentesis'

Updated : available animals with columns: is booked , available animals , animal type
-> Check box | Good Morning Sunshine | mare
-> Check box | Goat 3 | goat
-> Check box | Goat 4 | goat
-> Check box | Guicho | gelding
-> Check box | Misty | mare

'quit' event created with arguments ''

It is quite explicit that Guicho is marked as booked before he disappears, and not checked when he comes back. Updating the UI map file was very easy - we viewed it in a graphical diff tool, noted the new column for the checkbox and the lack of the list of booked animals were as expected, and clicked "save" in TextTest.

I only actually had like 5 tests, but updating them to cope with the changed UI was relatively straightforward, and would still have been straightforward even if I had had 600 of them.

I'm quite pleased the way PyUseCase coped in this case. I really believe that with this tool you will be able to write your tests once, and they will be able to survive many generations of your UI. I think this toy example goes some way to showing how.

PyUseCase 3.0

2009-12-16T19:42:00.006+01:00

Geoff has been working really hard for the past few months, writing pyUseCase 3.0. It has some very substantial improvements over previous versions, and I am very excited about it. He's written about how it works here.

It's a tool for testing GUIs with a record-replay paradigm, that actually works. Seriously, you can do agile development with these tests, they don't break the minute you change your GUI. The reason for this is that the tests are written in a high level domain language, decoupled from the actual current layout of your GUI. The tool lets you create and maintain a mapping file from the current widgets to the domain language, and helps you to keep it up to date.

In a way it's a bit like Robot, or Twist, or Cucumber, that your tests end up being very human readable. The main difference is the record-replay capability. Anyone who can use the application GUI can create a test, which they can run straight away. With these other tools, a programmer typically has to go away and map the user domain language of the test into something that actually executes.

The other main way in which pyUseCase is different from other tools, is the way it checks your application did the right thing. Instead of the test writer having to choose some aspects of the GUI and make assertions about what they should look like, pyUseCase just records what the whole GUI looks like, in a plain text log. Then you can use TextTest to compare the log you get today with the one you originally recorded when you created the test. The test writer can concentrate on just normal interaction with the GUI, and still have very comprehensive assertions built into the tests they create.

pyUseCase, together with TextTest, makes it really easy to create automated tests, without writing code, that are straightforward to maintain, and readable by application users. Geoff has been developing his approach to testing for nearly a decade, and I think it is mature enough now, and sufficiently far ahead of the competition, that it is going to transform the way we do agile testing.

:-D

Jens Östergaard on Scrum

2009-12-10T20:36:00.003+01:00

Today I listened to a presentation about "Scrum for Managers" from Jens Östergaard. He's a big, friendly Dane who grew up in Sweden, and now lives in the UK. I first met Jens at XP2003 in Genoa, when he had just run his first successful Scrum project. These days he spends his time flying around the world, teaching Scrum courses and coaching Scrum Masters. (He'll be doing 2 more CSM courses in Göteborg in the next 6 months, and speaking at Scandinavian Developer Conference).

One thing I noticed about his talk was that most things about Scrum hardly seem to have changed at all. Jens was largely using the same language and examples that are in the original books. The other thing that struck me was that Jens said nothing about the technical practices that are needed to make agile development work. In my world, you can't possibly hope to reliably deliver working software every sprint/iteration if you havn't got basic practices like continuous integration and automated testing in place. I asked Jens about this afterwards, and he said it was deliberate. Scrum is a project management framework that can be applied to virtually any field, not just software development. Therefore he didn't want to talk about software specific practices.

When I first heard Ken Schwaber talk about Scrum (keynote at XP2002) I'm farily sure he included the XP developer practices. I can't find my notes from that speech, but I remember him being very firey and enthusiastic and encouraging us to go out and convert the world to Scrum and XP (the word agile wasn't invented then).

Scrum has been hugely successful since then. Today we had a room full of project managers and line managers who all knew something about Scrum, many of whom are using it daily in their organizations. Scrum is relatively easy to understand and get going with at the project level, and has this CSM training course that thousands of people have been on. These are not bad things.

I do think that dropping the XP development practices entirely from the description of Scrum is unhelpful. I chatted with several people who are having difficulty getting Scrum to work in their organizations, and I think lack of developer practices, particularly automated testing, is compounding their problems. I think a talk given to software managers needs to say something about how developers might need coaching and training in new practices if they are going to succeed with Scrum.

Scandinavian Developer Conference 2010

2009-12-04T19:34:00.005+01:00

The programme for Scandinavian Developer Conference has just been published. I think we have a fantastic line up of speakers this year. I am particularly pleased Michael Feathers, Brian Marick and Diana Larsen have agreed to join us, and that this year my husband Geoff is also a speaker.

I have met Michael and Diana at many XP conferences over the years, but I missed Brian Marick the one time I was at the agile conference in North America, so I'm particularly interested to hear what he has to say. He has been very influential in the testing community, and invented the idea of testing quadrants, which I think is a very helpful way of thinking about testing.

Michael Feathers is known for his book "Working Effectively with Legacy Code", which I reviewed early drafts of back in like 2004. He and I also competed together in "Programming with the Stars" at agile2008. Michael works for Object Mentor, coaching teams in all things agile.

Diana Larsen is chairman of the agile alliance, and has written a book about retrospectives together with Esther Derby. I think I first met her at XP2005, when I attended her tutorial, which I remember as outstanding. It was very interactive and all about communication skills and teambuilding. Her job seems to be all about teaching the people skills needed for agile to work.

Geoff is going to be talking about texttest, which goes from strength to strength, and productive GUI testing with pyUseCase. Geoff has been doing an awful lot of work on this tool lately, and I am really excited about the possibilities it opens up for agile testing. I will have to write a separate post on that though, so watch this space :-)

Many of the other speakers are familiar faces who I look forward to meeting up with again - Bill Wake, (books about refactoring, XP and Ruby), Erik Lundh, (the earliest Swedish XP coach), Niclas Nilsson (ruby, programming guru), Jimmy Nilsson (Domain Driven Design book), Neal Ford (Thoughtworks, productive programmer book), Thomas Nilsson, (CTO, Responsive, linköping), Ola Ellnestam (CEO, Agical, stockholm), Marcus Ahnve (programming guru), Chris Hedgate (programming guru)...

I'm also very pleased that I'm going to be speaking again this year, after the success of my previous presentation on "clean code". This year I hope to talk about agile testing and how best to approach it.

One of the reasons I keep going back to the XP conference is the amount of interaction and discussion generated by the many workshops and open space sessions. There are very few straight talks, and all are either presentations of academic papers, or keynotes. When I saw the proposed programme for SDC a couple of weeks ago, I felt it was lacking something. Eight parallel tracks of presentations is all very well, but where is the interaction, the whole reason to go to a conference and not just watch presentations on infoq? So I proposed a ninth "track", devoted to discussion, called "conversation corner". Luckily my colleagues at iptor, who are organizing the conference, liked my idea.

To get the conversations going, I am organizing four "fishbowl" style discussions, seeded by conference speakers. I've picked topics that interest me, and invited other conference speakers, who I think are also interested in these topics, to join me.

I am hoping that after participating in one or two of my fishbowls, some conference attendees might feel comfortable proposing discussions of their own. To that end there will be a board with timeslots and index cards, so people can write up their topic, assign it to an empty timeslot, and hence invite more people to join them.

It won't be full blown open space, there will be no opening meeting with everyone, or two minute pitches proposing sessions. I won't be explaining the law of two feet or the open space rules. But it is a step in that direction, and I hope a complement to the organized speeches going on in the rest of the conference.

Perhaps you'd like to join us at the conference? Register here.

Iptor

2009-11-26T20:43:00.003+01:00

It occurred to me that I should mention that I now work for Iptor Konsult AB rather than IBS JavaSolutions. This is not due to my changing jobs, rather that IBS decided that since we don't do the same things as the rest of the company, we should have a separate name and image. We are even going to be a separate legal entity, although still wholly owned by IBS.

I think it's a very positive development for both parties, and I personally am much more comfortable standing up and presenting myself as from Iptor than I ever was when it was IBS JavaSolutions. For a start it's not also the name of a rather unpleasant illness, and secondly it means I can avoid mentioning Java. A language I now work with daily, but don't enjoy nearly so much as python.

In practice though, the name change probably won't make that much difference in my daily life.

TextTest progress

2009-11-26T19:43:00.005+01:00

When I wrote this post about the public Texttest nightjob statistics, I thought they were a bit confusing and hard to understand. Geoff has now rewritten the page to contain fewer numbers, and just report the passed and failed tests from the previous night. I think it's a bit easier to read now. He has also ditched about 500 tests that were running on Solaris, since that platform is not used often, and these tests never found bugs that weren't also found on Linux.

The statistics are still pretty impressive though, don't you think?

TestNG - my opinions

2009-11-22T21:10:00.006+01:00

It's Java Forum next week, here in Göteborg. I'm giving a short talk about TestNG, a tool I've been using lately.

My basic conclusion is that TestNG is a very easy step from JUnit, and one you don't need to take if all your tests are true unit tests (ie fast and independant). TestNG has some nice features which help when your tests are slow and/or have external dependencies, especially if they are mixed together in the same test classes as true unit tests. I think it's pretty useful for unit and integration tests. (aka quadrant 1, technology facing).

Having said that, what bothers me about TestNG is that it means your test code is written in Java. For me, that makes it unsuitable for for system tests, (aka quadrant 2, business facing). If you have anything resembling an involved customer, you're going to at least want to encourage them to read the system tests to verify they are correct, and to gain confidence that the system is working. Truly agile teams have these people helping write tests. Many customer types won't be happy working with Java. You might be able to get by, though, if you have descriptive test names, good javadoc, and test data in separate files that they can read.

Rather than spending time learning TestNG, I think you may get more payback from tools such as Fitnesse, Robot or TextTest, which all allow you to get customers involved in reading and even writing tests. I think it could be a perfectly sensible choice to stick with JUnit for unit tests, and use one of these tools for both integration and system tests. What you choose will of course depends on the situation, for example the size of the system, the nature of the test data, and how many tools your team is willing to learn.

Video of "Varför går man till en Coding Dojo?"

2009-11-18T21:50:00.005+01:00

I spoke at Smidig2009 about a month ago, and they have now put up videos of all the talks. So I just had the uncanny experience of watching myself speak (here is a link to it). I'm sure my swedish accent sounds better in my head when I'm talking, but I do apparently get my point across, since about a dozen people turned up to do a code kata with me in the open space in the afternoon.

JFokus

2009-11-01T20:52:00.002+01:00

I've just heard that I've been accepted as a speaker at JFokus, in Stockholm in January. I'll be saying something about how to write good tests using Selenium, a tool I've been using a fair amount lately. I'm looking forward to the chance to meet up with the wider Java community in Sweden and find out what's new and what's hot.

Smidig 2009

2009-10-19T20:56:00.002+02:00

I'm off to Oslo on Wednesday for Smidig 2009. They've just announced the programme, which consists of lightning talks in the morning, and open space in the afternoons. I'll be giving a lightning talk on Friday morning about why you might want to go to a coding dojo. I'm hoping there will be enough interest to run a Randori/dojo in the afternoon. Someone commented that there have been dojo meetings in Oslo before, so I'll be interested to find out if they do them the same way I've been doing them.

The conference talks are mostly going to be in Norwegian, but mine isn't the only item in Swedish. I spotted Ola Ellnestam (agical) and Thomas Nilsson (responsive) on the list too. So if it turns out that I find spoken Norwegian totally incomprehensible, there will be a few people I can talk to!

JUnit and TestNG

2009-10-18T22:07:00.001+02:00

I wrote a blog post about these tools on my company blog. In swedish.

testing through the GUI costs less with the right tools

2009-10-02T20:32:00.006+02:00

Bob Martin has just written a post in his blog where he tells the story of a test manager who has 80 000 manual tests, and wishes they were automated instead. Bob writes:

"One common strategy to get your tests automated is to outsource the problem. You hire some team of test writers to transform your manual tests into automated tests using some automation tool. These folks execute the manual test plan while setting up the automation tool to record their actions. Then the tool can simply play the actions back for each new release of the system; and make sure the screens don’t change."

Bob then goes on to explain why this is such a terrible idea - and blames it all on coupling. That the tests and the GUI are coupled to the extent that when you change the GUI, loads of tests break. Wheras humans can handle a fair amount of GUI changes and still correctly determine whether a manual test should pass or fail, machines fall over all too easily and just fail as soon as something unexpected happens. So you end up re-recording them, which can cost as much as just doing the tests manually in the first place.

These problems are of course bigger or smaller depending on the GUI automation tool you choose. Anything that records pixel positions will fall over when you simply change the screen resolution, let alone when you add new buttons and features in your GUI. More modern tools record the names or ids of the widgets, so they don't break if the widget simply moves to another part of the screen. In other words, you reduce your coupling.

Geoff has been working on PyUseCase which takes this to another level. Instead of coupling the tests to widget names, you couple them to "domain actions". This makes your tests even more robust in the face of gui changes. A drop down list can turn into a set of radio buttons and your tests won't mind, since they just say something like "select airport SFO". This doesn't isolate you from the big changes, like moving the order of the screens in a wizard around, but since the tests are written in plain text, in a language any domain expert can read, they are relatively cheap to update.

There is another respect in which machines under-perform compared to manual testers. An intelligent human will usually do a certain amount of exploration beyond the scripted test steps they have infront of them. They try to understand the purpose of the test, click around a bit and ask questions when parts of the system peripheral to the test in hand start to look odd. Machines don't do any exploration, and in fact often don't even notice errors on parts of the screen they havn't been told to look at.

Geoff's PyUseCase can partly address this kind of a problem. Used together with TextTest, it will continually scan the log the System Under Test produces, and fail the test for example if any stack traces appear. PyUseCase also automatically produces a low fidelity ascii-art-esque log of how the current screen looks, and can compare it against what it looked like last time the test ran. Changes are flagged as test failures, which will bring to your attention the change in an unrelated corner of the screen which says "32nd December" instead of "1st January".

I know that sounds like we just introduced a huge amount of coupling between the tests and the way the GUI looks, and yes, we have. The difference is that this coupling is very easy to manage. If 1000 tests all fail saying "expected: 1st January, found: January 1st", TextTest handily groups all the test failures and lets you accept or reject the change en-masse. So it is very little work to update a lot of tests when the GUI just looks different, but you don't care.

There is still a problem though, that the machine will not explore outside of the scripted steps you tell it to perform. So you will have to do some manual exploratory testing too, not everything can be automated.

So a simplistic lets-just-automate-our-manual-tests is a bad idea because machines can't handle GUI changes as well as humans can, and because machines don't look around and explore. Potentially your automated tests will cost more than your manual tests, and find fewer bugs.

So should we stick with our manual test suite then? No, of course not. The value of automated tests is not simply that you can run them more cheaply than manual tests, it is that you can run them more often - at every build, constantly supplying developers with valuable feedback rather than just at the end of the release cycle. It is this kind of feedback that enables refactoring, and lets developers build quality code from the start. That is their real gain over manual tests.

Bob Martin's suggestion is that you shouldn't rely on expensive GUI tests for this kind of feedback - only perhaps 15% of your tests should be GUI reliant. The rest run against some kind of api, which is less volatile and hence cheaper to maintain. With the kinds of tools Bob I suspect has been using for GUI testing I'm not surprised he says this. I just think that with tools like PyUseCase and TextTest the costs are much reduced, and call for reconsideration of this ratio. Looking at Geoff's self tests for TextTest (a GUI intensive tool), around half are testing through the GUI, using pyUseCase. Basically I don't think GUI tests have to be as bad and expensive as Bob makes out.

First JDojo@Gbg meeting

2009-09-03T20:02:00.003+02:00

A little while ago we had the first meeting of our new coding dojo here in Göteborg. We are focussing on learning Test Driven Development using Java and Eclipse. I was very encouraged that two of my colleagues, Fredrik and Martin, volunteered to help organize the group. There was actually quite a lot of interest generally, and we filled all 12 places and even have a (small) waiting list. I didn't want the group to grow too big, since the dojo style of learning should be quite participatory, and the time slot is only 2 hours. Everyone should get a chance to be heard, and to take the keyboard.

At the meeting I introduced the dojo concept with a set of slides I have used before. At dojo meetings our focus should be on deliberate practice, aquiring good coding habits, mutual encouragement and feedback.

We then took on KataFizzBuzz which went very smoothly. I started by introducing the Kata, using this picture of the "teacher" pointing at you, asking you to say the next number in the FizzBuzz sequence. She is sufficiently scary looking that you definitely need to write a program to print a FizzBuzz cheat sheet before the next lesson!

I also introduced something I havn't done before at a dojo meeting - starting with some code rather than a blank editor. I had the acceptance test for the Kata already coded up and failing. When I practiced this Kata I realized the hardest part was writing the acceptance test, which captures the sequence that is written to System.out. I could have begun the meeting by written it in front of the audience, but I really wanted to get them coding, not just watching me.

Martin wrote the first unit test, fizzbuzz(1) -> [1] and I noticed that his style is slightly different from mine. He fixed all the compiler errors as he went along, whereas I would tend to leave them all until I finish the test, or at least until I want to run it. Maybe that is because he has worked in Java/Eclipse longer than me, and that is the way Eclipse likes you to work. Anyway, I then implemented the code to make the test pass (fake it!) and wrote the next test fizzbuzz(2) -> [1,2]. So then he had to write just enough code to make it pass (a simple loop).

Then we handed the keyboard to two members of the audience, and Martin and I sat down in their chairs, and the Randori was really underway. We continued with this pair and two others using this ping-pong style until after about an hour we had completed the first part of the Kata - printing out the basic fizzbuzz sequence up to 100.

I suggested that the pair at the front try to run the acceptance test, which they did, and it failed. The reason was that the unit tests had been testing an internal method fizzbuzz() and the acceptance test checked that when you call main() you get the right sequence written to System.out. It was at this point I wondered if I had made the right decision when I wrote the acceptance test in advance, since that meant the guy at the keyboard clearly didn't really understand what it was for. His first thought of how to make it pass was to change it to call fizzbuzz() instead of main(), until I stopped him - "No! don't change the test! Fix the code!". I felt like I was rapping him over the knuckles with a ruler (something I am thankful my Maths teacher never did).

Towards the end of the meeting so we held a 10 minute retrospective. People seemed cautiously positive towards TDD and the dojo in general, but I think they maybe still getting used to the format and working out whether it is "ok" to be openly critical. I hope for more dissent, discussion and group learning next time.

Testing TextTest

2009-08-28T19:57:00.004+02:00

Geoff has just put up a couple of new pages on the texttest website, with some coverage statistics for his self tests. He uses coverage.py to produce this report which shows all the python modules in texttest, and marks covered statements in green. I think it's pretty impressive - he's claiming over 98% statement coverage for the over 17 000 lines of python code in texttest.

I had a poke around looking for some numbers to compare this to, and found on this page someone claiming Fitnesse has 94% statement coverage from its unit tests, and the Java Spring framework has 75% coverage. It's probably unwise to compare figures for different programming languages directly, but it gives you an idea.

Geoff also publishes the results of his nightly run of self tests here. It looks a bit complicated, but Geoff explained it to me. :-) He's got nearly 2000 tests testing texttest on unix, and about 900 testing it on windows. As you can see, the tests don't always pass, some are annoying ones that fail sporadically, some are due to actual bugs, which then get fixed. So even though he rarely has a totally green build, the project looks healthy overall, with new tests and fixes being added all the time.

Out of those 3000 odd tests that get run every night, Geoff has a core of about 1000 that he will run before every significant check-in. Since they run in parallel on a grid, they usually take about 2 minutes to execute. (When he has to run them at home in series on our fairly low spec linux laptop they take about half an hour.)

Note that we aren't talking about unit tests here, these are high level acceptance tests, running the whole texttest system. About half of them use PyUseCase to simulate user actions in the texttest GUI, the rest interact with the command line interface. Many of the tests use automatically generated test doubles to simulate interaction with 3rd party systems like version control, grid engines, diff programs etc.

Pretty impressive, don't you think? Well I'm impressed. But then I am married to him so I'm not entirely unbiased :-)

Domain Specific Languages for Selenium tests

2009-08-17T20:44:00.004+02:00

I've been doing some work lately creating automated functional test suites using Selenium RC to simulate user interaction with a web GUI. I discovered quickly that the tests you record directly from selenium are rather brittle, and hard to read. In order to make the tests more robust and readable, I have been extracting reusable chunks of script that make sense from the user perspective, into separate methods. For example when testing a page for registering a new provider, you might have a ProviderPage domain class, with method "createNewProvider". This method encapsulates all the selenium calls that interact with the page, and lets your test be written in terms of the domain.

I just saw this article from Patrick Wilson Welsh basically saying the same thing, only his DSL has three layers of indirection instead of just two. As well as encapsulating page operations in a Page class, he encapsulates operations on widgets within a page. I hadn't thought of doing that. It makes the code in the Page class more readable. I might try that, and see if it improves my code.

What other people have written about new dojos

2009-08-05T21:03:00.003+02:00

Gathering ideas for my new dojo :-)

Ivan Sanchez wrote about starting a coding dojo, and he rekons a Randori is best with 10 people or less. We will be more than 10 at JDojo@gbg. He suggests a prepared kata in that case. That might be possible. His favourite starting kata is KataMinesweeper.

Danilo Sato wrote about how to find suitable Katas, and suggests several for beginning dojos, including Ka taMinesweeper.

Gary Pollice wrote an article about what a coding dojo is, which is quite well explained, but doesn't give any specific advice for new dojos.

The guys running the finnish dojo have a similar article about what a coding dojo is, and some rules. They put a maximum of 15 participants on their randori. They also introduce "iterations" of 30 minutes, and spend 5 minutes planning in between.

Lots of ideas to think about, anway.

a new dojo - JDojo@Gbg

2009-08-03T19:59:00.003+02:00

I'm planning to start a new dojo this autumn, called JDojo@Gbg. I was inspired by the guys at Responsive in Linköping, who I met at XP2009. They have been running a dojo for some time now, and find it is an excellent way to introduce programmers from their clients to the ideas of Test Driven Development. I think we could do with more test infected programmers about the place in Göteborg, too.

I already run a dojo as part of GothPy, and Got.rb also runs regular Kata/dojo evenings, but because those programming languages are not mainstream, many developers wouldn't consider coming along. That is why the new dojo is explicitly going to use Java, or at least, the JVM platform.

I'm thinking about what Katas we are going to tackle at the new dojo, and last night I had a go at KataFizzBuzz in Java. It is an extremely simple problem to solve, and initially I thought it was too easy to be a Kata actually. Then at agile2008 I was looking around for a Kata that Michael Feathers and I could perform in 4 minutes for the "Programming with the Stars" competition, and it seemed to fit the bill. I was quite pleased we got done in that short amount of time (in python of course :-)

A couple of people have commented that this Kata is actually quite good for teaching TDD, just because it is so simple to solve. People are forced to think about TDD instead of the problem. It can easily be made more interesting by adding new requirements too. So I think I might try it out at JDojo@Gbg.

europython

2009-07-04T10:33:00.001+02:00

I just wrote a report about europython on my company blog.

Programming, History and Bletchley Park

2009-07-02T11:29:00.001+02:00

Today at europython we listened to a keynote about Bletchley Park. This was the centre of British and allied codebreaking activities during the second world war, and where the first digital, programmable computer was built, Colossus. We heard about the current financial plight of the museum there, and the need for investment to renovate the huts that amongst others Alan Turing worked in. Dr Sue Black told us about her experiences trying to help lobby the government for more money for Bletchley park, using social networking, blogs and twitter. She recounted that she had recently met an elderly gentleman, one of the surviving codebreakers. She told us how close she felt to history when he related a story about when he was decoding a nazi message during the war, and his shock when he got to the end and discovered the message was signed “Adolf Hitler, Fuhrer”.

As a professional programmer, I think the site where the first digitally programmable computer was built has to be a place worth preserving. I hope that people will be able to visit there and see the reconstructed Colossus computer and be inspired by the stories of innovation and codebreaking that it enabled.

It was particuarly poignant for me to think about this when in the next session I checked my email and found a message from my mother saying that my grandmother died this morning. She was a living link to the history of the second world war for me. During the war she was a wireless operator, transmitting and receiving messages in morse code. And now she is not there any more. I am kind of in shock. But it just confirms for me that we need museums like the one at Bletchley Park to retain contact with our history.

(I wrote this post yesterday)

XP2009

2009-06-03T22:15:00.002+02:00

I had a fantastic time at XP2009 in Sardinia, but I didn't find time to blog much about it until now. I just wrote a report of my TDD workshop on jsolutions.se.

Lean with lego

2009-05-25T12:32:00.002+02:00

I'm at XP2009 this week, the sun is shining, the sea is blue and the italians are disorganized. I'm having a great time so far. This morning I was at a workshop led by Danilo Sato and Francisco Trindade - 'The lego lean game'. The idea was that we should learn about lean principles by playing with lego. I thought it was good fun, and we did learn quite a bit about pull, kanban and continuous improvement. I hope I will be able to run this simulation for some of my colleagues, I think it is a good practical way of learning using all the senses, not just reading books or listening to presentations. Much more kinesthetic.

caffeine, the science and the propaganda

2009-05-13T20:46:00.003+02:00

I usually follow the news in the agile world on infoq, and I like the feature whereby you can listen to selected conference presentations online. This week I was making some biscuits one evening, so I took the chance to listen to Linda Rising talking about "agility: possibilities at a personal level". I have to say I was rather disappointed. I think her material was not that relevant to agile in the first place, many of her claims lacked credibility, and although the talk was superficially entertaining, it did not supply useful insights or conclusions. This provoked me into leaving a comment on the infoq site. I wonder if anyone will notice.

Europython

2009-05-11T20:28:00.002+02:00

I'm looking forward to Europython in Birmingham at the end of June. Geoff and I are going to be rather busy at it. They've just published the programme, and between us we are holding 5 sessions. I'm running a "coder's dojo", a "clean code challenge", and Geoff and I are doing a tutorial on texttest together. Geoff is also giving talks about texttest and pyUseCase.

The coder's dojo session is a copy of the original XP2005 workshop by Laurent Bossavit and Emmanual Gaillot, only in python with different Katas. The structure is the same though - introduction, prepared Kata, randori, retrospective. I thought it worked really well in 2005, so why change a winning format?

The clean code challenge is an idea I came up with. I've written on this blog before about KataArgs, and my dodgy python translation of Bob Martin's code. I'm interested to know what the python community will make of it. I'm basically planning to throw this code out to anyone who turns up, and ask them to refactor it into better python. I'm of course hoping they will produce some innovative, beautifully pythonic solutions, and show me what clean code looks like in python.

The tutorial on texttest is essentially similar to the one Geoff and I did at Europython in 2005. It's longer though, a half day, and builds on all the experience we have had since, doing tutorials at XP2006 and agile2008 for example.

All in all, I hope we'll have some time and energy left to go to the other items in the programme. It looks like being a busy conference.

TDD performer artists announced

2009-05-06T20:30:00.003+02:00

As I wrote in a previous post, I am organising a workshop at XP2009 called "Test Driven Development: Performing Art". I am very pleased to announce that I have four pairs of expert programmers willing to perform prepared Katas at it! You can read about it here. I am especially pleased that all the performers are experienced coders with previous involvement in coding dojos in places such as Stockholm, Linköping, London, São Paulo and Helsinki. I think we're going to have a great afternoon on 27th May.

They learn so fast and they are so cheap

2009-04-21T19:34:00.004+02:00

Recently I've had the priviledge of working with a team of developers where I sit in the same room as half of them, and the other half are in China. My role is to help them to develop a suite of automated system tests alongside the production code. After a few month's work, we now have quite a substantial product, with quite a substantial test suite.

When we started, very few of the developers had written much in the way of system tests, and even fewer knew how to write good, maintainable ones. Over the weeks, I have been promoting practices to enhance test readability, reviewing test code, and pointing out areas that need better coverage.

I've noticed that with the local developers, reviews and feedback are usually conducted face to face, informally, whereas with the offshore developers, it all goes via email, with a substantial time delay. This has meant that the Swedish developers have learnt faster, since they benefit from shorter feedback cycles, and a richer form of communication. Having said that, the Chinese developers are doing nearly as well. They seem really motivated to deliver what I ask for, and keep requesting and responding to feedback until they have written what I consider to be some pretty good tests.

It's not all sweetness and light, however. As much as learning the technical skills of writing tests, the team needs to learn the culture of maintaining them. The CI server complains the build is broken far too often, and it is because the developers generally are not running the tests before they check in. My perception is that the offshore developers are worse at this, and my interpretation is not that they are somehow less good developers, far from it. I think that they just don't have the same management support to spend time on maintaining the tests as the onshore ones.

Management in Sweden has really bought into the idea that investing in automated tests pays off over the long term, and vigorously support me in discussions with recalcitrant developers. Management in China has not. My impression is that they see only the costs associated with writing, running and maintaining automated tests, and would rather hire some (ridiculously cheap) Chinese students to run manual tests instead.

I would like to believe that this automated test suite is a really good investment for the future of this product. My experience tells me it should enable regression bugs to be found very soon after insertion, and enable much more frequent product releases. (You don't have to wait for a 6 week manual test cycle before each release). Over the many year lifetime of the product, this should significantly outweigh the initial investment we have made creating it, and the ongoing costs of keeping it running.

The reality may be quite different. Future versions of the product will likely be developed entirely in China, and I suspect that without their Swedish colleagues' enthusiasm, the Chinese management might decide the test suite should be quietly dismantled and left to rot. That may be the right economic decision, although it makes me weep to think of it. All I can do is console myself with the thought that at least the tests are so readable they will be easy to convert into manual test cases detailed enough for dirt cheap unskilled Chinese students to perform.

Call for participation in workshop at XP2009

2009-04-02T21:12:00.003+02:00

I'm looking for some really good coders. People who can write outstanding code, and yet know that however good they are they can always get a little bit better with a little practice, feedback and reflection. The kind of coders that attend a coding dojo and practice on code katas.

Interested? Could be persuaded to attend XP2009? Take a look at this call for participation.

Scandinavian Developers Conference

2009-03-31T19:57:00.005+02:00

At the speakers dinner the night before the conference:

Ola Bini: "Do you have any actual code examples in your talk about clean code tomorrow?"
Me: "No"
Ola Bini: "Well, I'm sorry but that means I can't come and listen to it"

Not such an auspicious start perhaps, but fortunately about 125 other conference participants didn't seem to mind the lack of actual code, and did turn up for my talk. Some of them even blogged favourably about it. To my surprise, some guy came up to me afterwards and said he helped organize the JFokus conference, and did I have a Java talk I could give at it?

It was a lot of work preparing my presentation, and I got some really useful feedback from the two practice runs I did, at GothPy and for my colleagues at IBS. It was this feedback that prompted me to take out all the code examples I originally had in the presentation, actually.

Overall the conference seemed to go really well. There were about 450 participants, about 40 speakers, and 6 parallel tracks. I attended some great sessions, too but I'll leave a summary of them to another post.

Just in case you were wondering, I didn't go to Ola Bini's talk either ;-)

Java-ish python

2009-02-25T21:56:00.003+01:00

I am really interested to find out more about this concept of "clean code", and in particular how it relates to programming language. To this end, I'm still chewing on KataArgs.

My latest idea is to start from Bob Martin's Java implementation, and translate this as directly as possible into python. My idea is to then refactor it to be more pythonic, and see if it turns out looking anything like his Ruby implementation.

I have put up some code on launchpad, which is my attempt at a direct translation of the Java. It was really interesting to do, actually. Of course I had read the Java before, and followed along in the book all the steps to create it, but actually translating it made me understand the code on another level. When I tackled this Kata from scratch, I also got a much better understanding of it, but this was different.

One thing that jumped out at me was the error handling. It's much more comprehensive than anything I've produced in my own solutions, and also compared with his Ruby solution. So I think it's a bit misleading of him to say "I recently rewrote this in Ruby and it was 1/7 the size". Of course it is smaller. It does less. Although to be fair, in a way it does more too...

One thing I found awkward to translate was the use of the enum for the list of error codes. Python doesn't have a direct equivalent, being dynamic as it is. The other awkwardness was the Java iterator. In python iterators are built into the language, but don't let you backtrack, or get the current index, unlike Java ones. I was surprised to find how extensively the tests rely on this functionality. To my mind, they probe the internals of the args parser too much.

By far my most interesting observation, though, is the one I want to explore more. This code is well written Java, but directly translated, it makes pretty poor python. Why is that? What, specifically, are the smells, and what are the antidote refactorings?

I will no doubt post more on what I find, (with the help of my friends at GothPy, of course)

fun with KataArgs

2009-02-25T21:24:00.004+01:00

I'm having fun with this KataArgs. In my last post, I took a closer look at Bob Martin's Java and Ruby solutions to it. Since then, we have tackled this Kata at a couple of GothPy meetings. (My coding dojo; the code is here.)

Several of us did some more work on the kata individually after the meetings, and a lively discussion on our mailing list ensued. I also challenged the local Ruby user group Got.rb to have a go at it, and one person posted his solution there too.

It's all good fun, anyway, and hopefully we're all learning something about what we mean by "clean code" along the way.

KataArgs and clean code

2009-01-21T10:09:00.006+01:00

Over Christmas I finished reading the book "Clean Code" by Robert C. Martin. I thoroughly recommend the book, which is highly practical, technical and well written. In it, Bob seeks to present the "Object Mentor school of clean code", as he puts it, "in hideous detail".

The book is full of code examples, clean and less clean, and detailed advice about how to transform the latter into the former. All the examples are written in Java, though, which leaves me wondering a little if "clean code" in the Object Mentor meaning of the word, looks the same in other languages.

In Chapter 14 of the book, there is a fully worked example of a little coding problem that I would call a code Kata. It's a little program for parsing command line arguments. I know, there are loads of libraries that do this already. But never mind. It's a non trivial problem yet small enough to code up fairly quickly. One thing that caught my attention was the footnote on page 200, just after he has presented his best Java solution to the Kata. "I recently rewrote this module in Ruby. It was 1/7th the size and had a subtly better structure." So where is the code, Bob? What is this subtly better structure?

I had nothing better to do on Boxing Day than sit around and digest leftover-turkey-curry, so I sent a little mail to Bob asking him for the code. To my delight, I got a mail back only a few hours later, with a message that I was welcome to it, and the url to where he'd put it on github. Evidently Bob also had time on his hands on Boxing Day.

I have had a look at the Ruby code, and although my Ruby is fairly ropey, I think I can follow what it does (surely a sign of clean code?). The design is very similar to the Java version presented in the book, with a couple of finesses. (The next part of the post will make most sense if you first look at Bob's Java version and Ruby version).

The first finesse I spotted, is that the Ruby version defines the argument "schema" in a much more readable fashion. Rather than "l,p#,d*" as in the Java version, it reads


parser = Args.expect do
   boolean "l"
   number "p"
   string "d"
 end

ie the program expects three flags, l,p, and d, indicating a boolean, number and string respectively. You can do this in Ruby but not Java because the language allows you to pass a code block to a method invocation. (the stuff between "do" and "end" is a code block, and the class "Args" has a method "expect") I think the Ruby version is rather more readable, don't you?

The second finesse I can see is that the argument marshallers dynamically add themselves to the parser, rather than being statically declared as in the Java version. This means that if you discover a new argument type that you want to support, in the Java version you have to crack open the code for Args.java and add a new case statement in the "parseSchemaElement" method, as well as adding the new argument marshaller class. In the Ruby version, you just add the new class, no need to modify an existing one. Bob invented the Open-Closed principle, so I guess it's not so surprising to see him following it :-)

So in Args.java:


private void parseSchemaElement(String element)
 throws ArgsException {
char elementId  = element.charAt(0);
String elementTail = element.substring(1);

// long if/else statement to construct all the marshallers
// cut for brevity
[...]
 else if (elementTail.equals("#"))
   marshallers.put(elementId, new IntegerArgumentMarshaller());
 else if (elementTail.equals("*"))
[...]

or in the Ruby code, each marshaller just tells the parser to add itself:


class NumberMarshaler
   Parser.add_declarator("number", self.name)
[...]

in the Parser class:


   def self.add_declarator(name, marshaler)
     method_text = "def #{name}(args) declare_arguments(args, #{marshaler}) end"
     Parser.module_eval(method_text)
   end

   def declare_arguments(args, marshaler)
     args.split(",").each {|name| @args[name] = marshaler.new}
   end

You can do this in Ruby but not Java, since in Ruby you can dynamically construct and execute arbitrary strings as code, and add methods to classes at runtime. (The string declared as "method_text" is constructed with the details of the new marshaler, then executed as Ruby code in the next line, by Parser.module_eval) This is an example of metaprogramming.

So it seems to me that the "subtly better structure" that Bob refers to in his footnote, is made possible by powerful language features of Ruby, such as metaprogramming and closures.

Of course my favourite programming language is Python, which also has these powerful language features. I am rather interested to see if I can come up with an equally clean solution in Python. I am also interested if any hotshot Java or Ruby programmers out there can improve on Bob's solutions. To this end, I have added a description of this Kata to the catalogue on codingdojo.org. We had a go at it at our last GothPy meeting, without any great success, although I hope we might do better at a future meeting.

So please have a go at KataArgs and see if you can write some really really clean code. Do let me and the community on codingdojo.org know how you get on!

Behaviour Driven Development at agile2008

2009-01-14T20:03:00.004+01:00

At agile2008 I attended a session with Dan North about Behaviour Driven Development. Someone on the agile sweden mailing list was asking about it, so I decided to write up my notes here.

Most cellphone and computer software is delivered late and over budget. The biggest contributing factor to cost bloat is building the wrong thing. So what software and business people need is "a shared understanding of what done looks like".

Test Driven Development is about design, conversations, and writing examples for a system that doesn't yet exist. It's not really about testing. However, once the system exists, your examples turn into tests, as a rather useful side effect.

A User Story is a promise of a conversation, and it is in that conversation that things go wrong. The customer and developer rarely agree what "enough" and "done" look like, which leads to over- or under- engineering.

Dan suggests a format for User Story cards which aims to prevent this communication gap.

On the front of the User Story index card, you have the title and narrative. The narrative consists of a sentence in this format:

As a stakeholder
I want feature
so that benefit

where benefit is something of value to stakeholder.

On the back of the card, you have a table with three columns

Given this context | When I do this | then this happens

Then you have 4 or 5 rows in the table, each detailing a scenario. (If you need more than that then the story is too big and should be split)

Dan finds that in his work, this leads to conversations about User Stories where "done" and "enough" are discussed, and defined.

User Stories should be about activities, not features. In order to check that your User Story is an activity, you should be able to do a thought experiment where you implement the story as a task to be performed by people on rollerblades with paper. You must think about it as a business process, not a piece of software.

When creating the story cards, the whole team should be involved, but it is primarily the business/end user stakeholders and business analysts who write the title and narrative on the cards. They then take in a tester to help them to write the scenarios.

Are people familiar with the V model of software testing? When this was conceived, they thought that the whole process would take 2 years, and span the whole project. Dan ususally does it in 2 days. Many times for each project.

Then Dan offered to show us how to do BDD using plain JUnit. He requested a pair from the audience, so I volunteered. At this point my notes dry up, and I am working from memory, but I think the general idea is like this.

You talk about "behaviour specs" not tests. The words you use influence the way you think, and "behaviour specification" gives much better associations than "tests".

Each behaviour specification should be named to indicate the behavour it is specifying. Not "testCustomerAccountEmpty" rather "customerAccountShouldBeEmpty".

In the body of the spec, you can start out by typing in the prose of one of the scenarios you have on the user story, as a comment.

//given we have a flimble containing a schmooz
// when we request the next available frooble
// then we are given a half baked frooble and the schmooz.

Then you can fill in code after the "given" comment. When you have code that does what the comment says, delete the comment. Repeat with the "when" and "then" comments.

In this way, you build up a behaviour specification that drives your development of the system. A few minutes later (hopefully) you have a system which implements the specification, and at that point your spec helpfully turns magically into a regression test which you can run. At that point you can start calling it a test if you like. But actually it is more helpful to your brain to continue to think of it as a behaviour specification. It leads to much more constructive conversations about the system.

'Agile'? or just 'more agile than ...'?

2009-01-10T20:58:00.003+01:00

The project manager was obviously a little irritated. "By this stage of the pre-study, we really should have the requirements a little more nailed down than this. That's two new requirements since last week. Or what does everyone think?" he looks around the table, expecting support. The business representative looks disappointed and hangs his head.

Without really thinking, I follow my instinct and jump in. "It seems wrong to me to say to the customer that he can't have any more features at this stage. Perhaps he should be prepared to drop something else instead, but surely we should be prepared to respond to the needs of the business? We are still in the pre-study, after all"

The project manager was not impressed. "This pre-study has already been going on for nearly 2 months, we really need to put together a budget and project plan so we can pass the next tollgate and proceed to the implementation phase." He looked around the table sternly, then his frown softened a little. "Well ok, you can have these two new requirements. Let's take a look at them"

A few days later, the project manager called me into his office.
- "You can't go telling the customer he's allowed to change his mind. After that meeting he came to me with more requirements. Your comments confused him as to how our software development process works. Please don't do it again".
- "But I though we were trying to be agile in this project? You know, short release cycles, end of iteration demos, like in Scrum".
- "Yes, we are following a process which is more agile than the standard company mandated process. We have got permission to skip two of the tollgates, and 5% extra in the budget for 'adjustments' so we can respond to the customer feedback we get at each demo. We are not doing Scrum though. Who told you that?"

Sigh. I heard "agile". What I should have heard was "more agile than the standard company process".

Would you buy a hammer from this man?

2008-12-17T19:19:00.003+01:00

The APL community clearly contains some characters. I really enjoyed this heartfelt plea for simplicity.

small children and working hours

2008-11-30T22:14:00.004+01:00

Michelle the manager has two small children. She regularly puts in a 45 hour week. Alan the project manager also has two small children. He officially works 80%. The first architect, Steve, has one small child. He officially works 90%. The second architect, Flo, has two small children. She officially works 100%. Also on the project team are a number of developers, testers and other experts.

The project isn't doing so well, and when there are about 6 weeks left until the delivery deadline, Alan the project manager starts coming in on Fridays - the day he usually spends at home with his children. Luckily his wife's mother lives just round the corner, and since she is retired there is no problem with childcare.

A short time later, he starts to make impassioned speeches to the project team about how important it is to make the deadline, and presents a strong case that overtime is needed. He asks everyone has to email him with their availability over the coming two weekends.

Michelle already works weekends semi-regularly. Her husband is in a business that is suffering from the recession, so he is only working 75% anyway, so there is no problem with childcare. She is available.

Steve is hardworking and ambitious, and his wife is happy to spend more time looking after their child. Steve is available.

One of the developers, Paul, has one small child, but his wife's mother is also keen to help, so childcare is not a problem. He is available.

None of the other developers have children. No problem with their availability then.

The thing is, Flo does have a problem. She has no extended family within reach who could be called in at such short notice. Her husband is already at home on paternity leave 100% and is finding it tough. He doesn't want to take up the slack, and she doesn't want to spend any less time with her children than she does already. After some thought, Flo tells Alan she is not available.

So what happens? Everyone works extra, except Flo. Alan is frustrated because he feels he can't give her any important tasks to work on, because he knows she won't stay late to finish them. Then Flo requests to work 80% in the new year, so she can spend more time with her children. (By Swedish law, all parents with young children who have a full time job have the right to reduce their hours.) Alan is not pleased, and talks to his boss about the situation. The project must go out on time, and he feels Flo's behaviour is endangering this. The upshot is that Flo is told her contract will not be renewed.

The official reason given is that "working 80% is not compatible with the rate of productivity we require of an architect at this workplace". The secondary reason given is the unwillingness to work overtime. As a contractor and not an employee, Flo has no recourse, the law doesn't apply, and she is left searching for a new contract to work on.

It turns out that even in enlightened, feminist Sweden (1), even when the boss in question himself has small children and normally works 80%, even when the other architect in the team officially work less than 100%, it is still the case that a mother working the hours specified in her contract, is not able to keep her position.

If this is what it is like in Sweden, God help working women in the rest of the world.

(1) Just as an example how the feminist culture affects the political agenda: The main opposition party, (who polls indicate will win power at the next election), wants to quota parental leave so that each parent will be forced to take half of time available. This must be the only nation in the world that expects fathers to stay home from work for 8 months with each of their children.

Overtime

2008-11-30T20:51:00.002+01:00

If you were looking to employ someone, what would you say to a candidate like this:

highly intelligent, excellent qualifications for the job, 10 years relevant experience, hardworking, ambitious.

Sounds good, doesn't it? What if she then added:

has 2 children, will not work overtime, (although still hardworking during normal working hours)

Perhaps not quite as interesting?

Then if she went on to ask to work 80%?

So the reality is, how many employers turn to the next CV at this point?

Anyway it looks like I am going to be finding out. My experience as a contractor so far is not encouraging.

agile toolkit podcast

2008-11-23T18:22:00.003+01:00

My weekend jog through the park was particularly interesting this week. Not just because of the light sprinkling of snow, bright sun and freezing temperatures. I had to watch my footing every time I heard myself interrupt Geoff or forget someone's name. Yes, I was on my own. And no, nothing wrong with my head. (nothing serious, anyway). I was listening to the latest agile toolkit podcast where Bob Payne interviews Geoff and me.

In a previous post I was rather critical of Bob's interviewing technique, and perhaps this is justified. He is a really genuinely friendly guy though, who is warm and enthusiastic towards people and that does make up for a lot. In the interview he did make some random joke about Thoughtworks that I still don't get, but on the whole I think we got on ok.

In the first part of the interview we talk alot about how TextTest grew up in an environment of long running batch processes, and a bit about the crew planning system that Geoff wrote it to deal with. I hope listeners don't decide this is boring and switch of at this point, because it does do more than just that. I talk a bit about what we did with TextTest on 'Programming with the stars' and then we discussed what else it is good for (legacy code, and even greenfield TDD development).

I did try to think through beforehand all the things I was going to say, but intevitably I left out a couple of important points. Neither of us mentioned that TextTest is written in python but can test any language (so long as it can produce plain text log output). I didn't make it clear that I don't work for Jeppesen, rather my new employer IBS JavaSolutions kindly paid my conference ticket. I said that 'I' got the highest marks in the stars competition instead of 'we' (forgive me Michael and Geoff! We did it together, I know)

Overall I think the podcast is worth listening to though. I hope it will encourage some people to try out texttest, and write automated tests for some code that they thought was untestable.

Intimidating situations

2008-11-12T20:23:00.004+01:00

This week I was finally invited to the architect forum meeting. Ten more or less geeky men, and me. It's funny, I don't usually think about the gender imbalance in the software industry much. On this occasion though, I felt distinctly uncomfortable. They all seemed to know each other, and mostly ignored me. They had an annoying habit of spattering their conversation with unidentified acronyms. I left feeling somewhat disheartened.

Later that evening I talked to my husband about the experience, as I often do. Seeing as we both work in the same industry, he generally has helpful comments. This was no exception, even though Geoff is currently at home with the children, enjoying his parental leave. "I understand just how you feel. Today I went to the baby rhythm and song group. Ten women with babies, and me, also with baby. They all seemed to know each other, and mostly ignored me. They tended to talk about breastfeeding and shopping."

So it could be worse, I suppose.

booked for SDC2009

2008-10-24T19:58:00.007+02:00

The full programme for SDC2009 in March will be published in about a week's time, but I can already tell it will be a great event. The call for papers is now closed, and the website has been updated with photos of all the booked speakers. With only one day of talks, it looks like there will be a lot to choose from.

I'm really looking forward to hearing international software gurus like Jeff Sutherland and Neal Ford, as well as lots of cool people from Scandinavia. Clicking through the photos on the front page, there are several faces I recognize as leading agile proponents. It's actually a bit of a shock to see my own headshot there in the lineup.

GothPy last night

2008-10-07T21:07:00.002+02:00

The second official meeting of the Gothenburg Python User Group was last night. Eight of us turned up, despite my writing the wrong address on my meeting invite. (It is Norra Ågatan 10A, not 6A - sorry!)

Anyway, in the first part of the meeting Jacob Hallen explained about PyPy, a very interesting project. It seems PyPy aims to replace jython, iron python, stackless and a host of other things, and has nearly as good performance as cpython. Jacob reckoned it would be ready for general use in about a year's time.

After fika, Johan gave a short presentation about how he uses Python at Nordea. Although the company policy is only to use Java and Cobol, he has had some successes with using python too. He's written several small applications that have been quick and cheap to build and have lasted much longer than their initially projected lifetimes. Unfortunately he hasn't persuaded anyone else at Nordea to write any python yet.

The coding challenge for the evening was KataRomanNumerals which went very well. We split into four groups and in less than 45 mins three of the groups had working solutions, all different, all elegant in their own way. My group was the one that didn't come up with a solution and that was because I was more interested in how to define the tests than how to define the solution :-) I wanted to write the tests in a spreadsheet then generate unittest test cases. It kind of worked. I will try again another time with FIT instead.

Most importantly, everyone said they enjoyed the evening and the chance to write some python code, just for fun.

A Quality codebase

2008-10-02T21:03:00.003+02:00

What is the quality of this codebase on a scale of 0 - 100? Zero means "perfectly designed, clean code" and 100 means "total spaghetti, impossble to make changes".

Without hesitation, Andreas answered. "70".

Andreas was standing at the whiteboard, sketching a timeline and drawing boxes labelled with the names of the parts of the system and the people involved. His task was to give a history lesson to the latest batch of newly arrived programmers. How did we get here?

It seems that way back in about 2001 when Andreas and the rest of the team of hotshot young programmers began building this system, it was pretty good. In six weeks ten programmers had achieved more than 100 consultants from had achieved in 3 months. That code was ditched shortly afterwards and Andreas' team code is still at the heart of the system today.

It seems that for several years things went pretty well, Andreas' team grew slowly and the system gradually took on more and more functionality. Their focus was on working closely with the business and delivering value quickly. The team was so successful that it started pulling back work from the firm's outsourcing partners, since they were so demonstrably better at delivering valuable functionality quickly.

Unfortunately the programming team is not so productive now. Over the last few years more and more people have been added, a fourfold increase in fact. Many of the original team have either left or disappeared on protracted parental leave. The quality of the codebase has deteriorated as developers unfamiliar with it have implemented new functionality at cross purposes to the original intent. It's not that they are bad programmers, but rather without guidance from more experienced people it is very hard to introduce new functionality cleanly without breaking anything. The almost total absence of automated tests doesn't help either. Programmer productivity is dropping steadily.

There are various initiatives to improve the situation. For example, Andreas' training courses for new programmers. Also, several experienced programmers are working on refactoring projects. (Without the aid of tests). The question is whether this is too little, too late. Rumour has it that the size of the codebase has increased 25% in the past 6 months. Emergency patch releases are now routinely scheduled after every major release. Obvious bugs have are present in the production system that no-one seems to know how to fix.

So the question I really want Andreas to answer is not the absolute quality of the codebase, but whether the quality is increasing or decreasing. Unfortunately, he couldn't tell. I fear the worst.

Conflict of interests

2008-09-27T19:58:00.001+02:00

My cousin held out the keys to his flashy looking sportscar and said “Do me a favour. If you crash into something with my car and it's nearly written off, but not quite. Please back up then hit it again, harder, until it really is written off”. I laughed nervously. “yeh, sure. Of course”. Needless to say I returned his car in perfect condition a few hours later.

The architect grinned as he reviewed my design proposal. “Don't worry about making the code beautiful, just make your changes work without causing extra test cyles. In fact, ugly changes are better. The sooner this code becomes legacy, the sooner we can rewrite it” I laughed nervously. “Sure, of course” He handed back my uml diagram and I went back to my computer to write some code. Beautiful code. Carefully.

jsolutions.se - Java nyhetskanaler

2008-09-05T11:09:00.002+02:00

For those of you who read Swedish, I have a new post up on jsolutions.se. The gist of it is that I usually read infoq to find out what is going on in the world, and I've just realized how biased it is compared with other Java news sources.

Scandinavian Developer Conference in Göteborg!

2008-08-27T10:07:00.004+02:00

I'm very excited to announce that I'm helping to organize a conference in Göteborg in March! This is going to be so cool. We've booked the biggest venue in town (Svenska Mässan) and are inviting high profile speakers from around the world. There will be a whole track on development processes and methodology, and I expect to see many leading agile proponents presenting there. If you're interested in presenting, there is a call for papers open right now. Otherwise, do sign up for the rss feed to hear all the conference news.

I really enjoy conferences, agile2008 was such fun, so I'm really looking forward to welcoming lots of interesting people to Göteborg in March!

Final meltdown

2008-08-09T21:20:00.006+02:00

The "Programming with the Stars" final was almost the last event of the whole agile2008 conference, and Michael Feathers and I were up against Lasse Koskela pairing with Noah Jacobson. Our brief from Joshua and Jeff was "you have 8 minutes on stage. Impress us". This seemed a little vague to me, but when pressed, all they said was "you have 8 minutes. Impress us with your skills at Pairing, TDD, Refactoring and IDE expertise." So there.

Yesterday (Thursday) was very intense, and I am exhausted. Geoff and I presented a 90 minute slot on TextTest first thing in the morning. We get better every time we do it, and this was definitely the best yet. I ended the session with an extended demonstration of KataBankOCR which I had been practicing loads, and went off without a hitch. Then at lunchtime we did "Programming with the stars" demonstrating JUseCase and TextTest (see my previous post) and directly after lunch Geoff did a 45 minute presentation of xUseCase. The room was packed and lots of people seemed interested. Afterwards Geoff and I spent some time chatting to important people from various agile tools companies.

On top of all that it was the conference banquet yesterday evening. Good company, good food, generally a great evening. Today Michael was running a session first thing, I wanted to go to the keynote, and the upshot was we didn't manage to get together to plan what to do in the "Programming with the Stars" final until an hour before it started. For some inexplicable reason the python installation on my Vista machine stopped working and I couldn't get anything to run, so we decided to use Michael's machine, (a mac)....

ok ok enough with the excuses. It was a disaster. Eight minutes on stage isn't long enough to achieve much, especially when you are dog tired, unprepared, and nervous. They had warned us it would happen, but when after 4 minutes Jeff stopped us and asked the judges to give us some interim advice, I totally lost my train of thought. All I remember of the advice was Bob Martin telling us to act "perky", so the fatigue must have been showing. When we restarted for the remaining four minutes, the audience began calling out more or less helpful directives. By the end we had written about five lines of code and still had no tests running.

The judges were surprisingly understanding and did give us a few points for our pairing skills (they can't have been for our coding, let's face it). Then Lasse and Noah came on stage and did a really slick, thoroughly prepared demonstration including testing with stubs, and a funny video clip. It was well done, and they deserved good marks.

So Michael and I didn't win "Programming with the Stars", but it was good fun, and we got to show off a little along the way. Now I just have to go back to being a normal programmer, pairing with other normal programmers, and Michael, well, I guess he continues to be a star...

We pulled it off!

2008-08-07T19:56:00.005+02:00

Today in "Programming with the Stars" our task was to do "Story Test Driven Development" (aka Acceptance Test Driven Development). With just 6 minutes on stage, this was a pretty tall order.

Jeff and Joshua had suggested that we use tools like FIT or Fitnesse to create the story tests, but I thought it might be an idea to try using TextTest. I have an ancient Java application that I have used before to demonstrate how TextTest works together with JUseCase, and I thought I might be able to do something with that.

Michael was really cool about all this, which was great, because I thought it was quite a risk to move away from the well-known acceptance testing tools.

The most important part about JUseCase is the way it helps you to interact with the customer (domain expert). So we thought it might be cool to bring in someone to act as the customer in the middle of our 6 minute slot. Geoff was the obvious choice since he wrote the tools, and knows how to write tests in them already.

So in the middle of our performance, Geoff came up onto the stage for a couple of minutes. He helped us write a failing story test in JUseCase/TextTest, and then Micheal and I made the use case part of it work by adding a new widget. We didn't get the whole test passing, but it was a start.

The judges apparently loved this, we got the highest marks of the whole competition so far. Wahey! Now for the final tomorrow!

(It has taken me some time to write this post. It feels like every time I sit down in the lobby to write it someone I have never seen before comes up to me and congratulates me or asks me if I've planned what to do in the final... this pleb-to-overnight-celebrity business is weird)

We scraped by with the help of the audience

2008-08-07T13:04:00.004+02:00

We were up last this time, rather than first, and I was so impressed with the three pairs who went before us, they all paired really well and seemed to achieve what they set out to do. Joshua (one of the hosts) also decided to interview each pair just before they started coding ("so do you think you've got what it takes to go all the way?") and I had no idea what to say. On the TV shows I'm sure they coach the contestants on how to respond to that kind of question, but I was too busy worried about how I was going to remember to type enough semi-colons to say anything coherent...

So, Michael produced some horrible looking C++ and led me through setting up a test so we could do "extract method" on a small portion of a hairy looking monster method. He introduced me to a technique called "sensing variable". Basically you write a test that calls the long hairy method, and in the middle of the method just after the part you want to extract, you introduce a "sensing variable" - you assign the result of what will be your extracted method to this global. Then from your test you can check what the global contains, and write an assertion for it. The next step is to do the extract method, and the test then checks that the "sensed" variable is still the same. This should ensure that you didn't make a mistake with the extract method, it is called, and returns the same as before.

It's fairly simple really, but it's the kind of thing you wouldn't think of if it wasn't shown to you. In a language like C++, you need all the help you can get.

Well, the judges had already awarded some very high marks to the other contestants, and our score was joint bottom, I think. Anyway, it went to audience vote between us and J.B. and Todd. They had done a teacher/pupil act similar to ours, on Eclipse wizardry rather than C++, and had raised considerably more laughs than we had. So I was a little surprised when we clearly got a louder cheer from the punters, and Jeff (the other host) announced we were through to the next round tomorrow!

Onwards with the stars

2008-08-05T23:40:00.008+02:00

Michael Feathers and I competed in the "Programming with the Stars" competition today, which was fun, if rather nerve racking. Our category was "TDD from scratch" and we chose to perform the FizzBuzz Kata in python. We chose that because we thought it was simple enough we could do the whole thing in the time limit, just four minutes (!).

It seemed to go smoothly, ping-pong programming, and this is the code we ended up with:


def fizzbuzz(max):
return ["FizzBuzz" if i % 15 == 0
    else "Buzz" if i % 5 == 0
    else "Fizz" if i % 3 == 0
    else i
    for i in range(1, max+1)]

assert fizzbuzz(1) == [1]
assert fizzbuzz(2) == [1,2]
assert fizzbuzz(3) == [1,2,"Fizz"]
assert fizzbuzz(5) == [1,2,"Fizz", 4, "Buzz"]
assert fizzbuzz(15)[-1:] == ["FizzBuzz"]

print "\n".join(map(str, fizzbuzz(15)))

As you can see we didn't bother with a testing framework of any kind, just a few assert statements, and the code that does the work is all one line, (although we put in some line breaks to make it readable). I was pretty pleased we managed to do it without mishap.

The judges turned out to be Bob Martin, Rachel Davies and Mike Hill, and they weren't actually as nasty to us as I feared. We got good marks from Rachel and Mike, (8/10 from both), and since Bob was mean to nearly everyone, his 5/10 was actually ok. Only one other pair scored more than us, which puts us through to the next round tomorrow. Our category is going to be "Refactoring", which is basically Michael's specialist subject, so hopefully we'll be able to come up with something good.

Geek meets Idol

2008-08-02T04:04:00.006+02:00

I've just got to Toronto in advance of the agile2008 conference which starts on Monday, and I'm looking forward to it with great excitement and some trepidation. Until now it was the session that Geoff and I are running on Thursday that was claiming all my attention but now my head is also buzzing with another potential conference highlight.

I've signed up as a contestant for the "Programming with the Stars" competition, and I got a mail today explaining that I will be performing live on stage with Micheal Feathers on Tuesday! We will have exactly four minutes to impress the audience and the panel of judges with our impressive collaboration skills and amazing feats of coding. I've seen "Idol", I know what "panel of judges" means... we're going to be eaten alive! I just hope I can remember how to code after nearly a year at home with baby. Thankfully I am very confident that Michael Feathers not only knows how to code, but if I do manage to produce anything really dodgy, who better to sort me out than the author of "Working effectively with legacy code"?

We are competing with five other pairs, it's a knockout competition, and the winners will be declared on Friday. Wish me luck!

New Job

2008-06-13T13:09:00.004+02:00

What do you have to do to get me to come and work for your company? Well, it seems a couple of free lunches and some good geeky conversation works pretty well. Of course, it helps if you're also offering me an exciting mix of software development work, high calibre colleagues and speaking engagements, all on my doorstep here in Gothenburg. So anyway, yesterday I signed on the dotted line for IBS JavaSolutions AB.

JavaSolutions is responsible for the local branch of Sun's JavaForum, which exists to support Java developers. There are regular meetings with talks and mingle, a bit like GothPy only on Java and without the interactive coding part. Hmm. I might have to do something about that :-) JavaSolutions also has a blog that employees are expected to contribute to. So I will have to devise some strategy for what to blog here and what to blog there.

My first appearance in my new role will be at agile2008 in Toronto, Canada, at the beginning of August. I'll be leading a session about Automated Acceptance Testing with my husband, Geoff. During the rest of the conference I will probably be going to lots of stuff to do with agile development and testing in Java. Having spent the last 6 years working in python, I'll need to brush up my Java a little.

So I'm looking forward to a fun autumn coding, learning stuff, and getting involved with GothPy and JavaForum. For the moment though, I plan to make the most of the Swedish summer together with two small children.

GothPy

2008-05-13T09:50:00.009+02:00

Last night a group of eight python hackers were drawn into a darkened conference room on Odinsgatan "Odin's street" in order to exchange little-known information and to take part in obscure coding rituals. To open proceedings, Andrew Dalke shared deep insights into the enigmatic "stackless" python. Later on, fuelled by strong Swedish coffee and cucumber sandwiches, we together attempted the "BankOCR" Code Kata. Everyone present contributed to further our art, and most took a turn working the somewhat arcane keyboard and IDE. By the end we had created a perfect although incomplete code chimera. Despite our considerable successes, it may need further work before any bank would consider taking on our design for their optical character recognition system.

And now I must confess to the part I have played in this pythonic plot. It is the result of scheming between Andrew Dalke, Johan Lindberg and myself. We joined together a few weeks ago to make arrangements for the creation of this chapter of the python community. By some twist of fate, I was designated "temporär ordförande", or "acting high priest".

Three hours of pythonic union notwithstanding, everyone present last night agreed that the experiment should be repeated. We look forward to the continuation of our assembly at the second Gothenburg Python User Group meeting sometime next month.

New baby

2007-11-21T15:52:00.000+01:00

Miranda was born last Thursday, a healthy little girl 53cm long and weighing 3.77kg. Her big sister Karina, (now three and a half) and Geoff and I are all doing well.

I hope to be at home with Miranda for about 6 months, so I don't expect to write much here for a while.