Mistaeks I Hav Made
Good judgement is the result of experience ... Experience is the result of bad judgement.
—
Good judgement is the result of experience ... Experience is the result of bad judgement.
—
For the last eight years or so, London's famous Extreme Tuesday Club (XTC) has been meeting every Tueday to share ideas about XP, "agile" software development, test-driven development and otherwise waffle philosophise about software development over fine ale and microwaved, puff-pastry pies (being in the UK, the beer is much better than the food).
The last few years, we have met in the Old Bank of England pub on the Strand. From now on we'll be in the Counting House pub on Cornhill, near Bank tube station.
Lots of great ideas and collaborations have spun out of the XTC, among them the XP Day family of grass-roots conferences, the mock objects technique and the jMock library for test-driven development of object-oriented code, the First International Conference on Postmodern Programming, the Jester mutation testing tool, the Extreme Lego workshop and other training games, and lots more.
An interesting aspect of XTC is that it is completely anarchic. There is no central organising committee. There is no formal membership. What happens is entirely up to whoever turns up and gets involved. This year we will be spending some of the income from XP Day on regularly hosting more formal presentations and rerunning the most popular sessions from XP Day to make them available to a wider audience. But for the rest of the time, the informal get-together style will prevail.
So, if you're interested in the future direction of software development techniques and practices, do please come along the Counting House and join in. The beer is the same but the pies are better, I've been told.
For the last few years XP Day has had an open review process. Anyone who submits a session also becomes a reviewer. Reviews are written on the website, are attributed and can be read by any other submitter/reviewer.
This year, this process had an interesting effect: people started reviewing sessions as soon as they appeared on the site, before the review phase started of the submission process started. This meant that the earlier a presenter submitted a proposal, the more time they had to improve it in response to the reviewers' feedback. Some really interesting sessions were invented on the website as reviewers and presenters bounced ideas back and forth.
Our review process accidentally stumbled onto an essential aspect of Agile software development: the earler you get feedback the more time you have to fix problems.
Maybe next year we shouldn't have a review phase at all. The submission deadline could be just before the meeting when the programme is put together. Presenters could submit as early (or as late) as they wished. The earlier they submitted the more feedback they would get, the more they could improve their submission, and the more they could be involved in the review process. The later they submitted the less feedback they would get but also the less reviews they would be able to write, which would count against their submission.
I've recently started a new project on which we use the Team City continuous integration server from Jetbrains. It's an excellent tool: easy to install and configure and with many advanced features.
There's just one thing it lacks: a honking great build monitor to make the state of the build publicly visible.
At my previous project we used Build-o-matic, which generates a very obvious, public display of the current build state and who is responsible. As Ivan has written, we found that this feature really helped everyone become personally involved in the build and integration of the system.
So, with no further ado I'm happy to introduce... Team Piazza, a Team City plug-in that provides Build-o-matic like build monitors. A Piazza build monitor displays:
Here are more screenshots.
Like many that use pair programming, the teams I work on often use pair stairs to track who pairs with whom and to ensure that each member has paired with all others. We draw the stairs on the whiteboard at the start of the iteration and tick off the boxes at the end of each day to record who has paired with whom.
As a consultant helping to introduce agile practices into a company it's often my task to introduce pair stairs to a team and draw them on the board for the first time. Unfortunately, I can never remember how to draw the axes. "Alice, Bob, Chris, Dan down the y axis and then Bob, Alice... no not Alice... Dan? ... or is it Eric?... err...". Somewhat embarassing when standing in front of the team, to say nothing of the project manager, customer, customer's boss, program manager, etc. Therefore, being a computer programmer, I decided to solve the problem with automation.
So, with no further ado, I present "Stair Master", a pair-stairs drawing program.
Type the names or initials of your team members into the input box, separated by commas. The app will build the pair-stairs in the rest of the page. When the page is printed, the input box will not be shown, so you can print from the browser and stick the resulting document on your team's whiteboard.
Stair Master updates the browser's URL field to link to the pair stairs. You can copy this link into your project's wiki for future convenience.
Warning: Stair Master only works properly in Firefox and other standards-compliant browsers. I can't be bothered to spend time trying to work around all the bugs in Internet Explorer.
Update: Thanks to a tip from Michael Mahemoff Stair Master now displays the link to the pair stairs in the browser's URL field, not as part of the HTML. However, this does mean that previous links you might have saved are now invalid. Sorry.
Update: The Pair Stairs are now easier to understand and the names are sorted alphabetically.
I've used, or been forced to use, many different commenting conventions over the years. The most awkward was a coding standard that required big banners at the top of each source file and a header comment for each function that repeated the information that was in the function's signature and followed it with a description of the function's behaviour that usually ended up pointlessly rephrasing the function's name. Another awkward commenting convention I've had to use is Javadoc : source code can become quite unreadable when it contains long comments that contain HTML markup.
A common misconception of agile software methods is that they eschew comments completely. On the contrary, like everything, it's a matter of context and sometimes comments are necessary. Agile methods try to use meaningful identifiers as much as possible to reduce comment noise and to ensure that human readable text is always kept up to date. In my projects, I have come to use a commenting practice that can be summed up by a pithy one-liner that Joe suggested I post here:
Identifiers say what. Comments say why.
Code is usually straightforward enough to require no more commentary than the identifiers provide. However, when I have to make an unusual design decision, I add a comment explaining why I have done what I have done.
On a recent project we kicked off with a few meetings to extract requirements in the shape of user stories. We followed the widely used format of "As a... I want... So that...". During the meetings I found this format quite unsatisfactory — I couldn't get a feel for how the users worked, how the system that met these requirements would fit into their routine and how they would use the system to generate value. I think that by following this rigid format we lost a lot of communicative power that stories, in a more traditional sense, would give us.
Furthermore, the "As a... I want... So that..." format makes it easy for users to slip technical details into the requirements. The telling of a real story about their work and the problems that they must surmount will hopefully help the storyteller concentrate on the end result they want us to provide and the business value that it will generate.
In the book Story, Robert Mckee describes how story tellers follow certain conventions to make a story more compelling to the audience. Stories that follow these conventions instil stronger reactions within the audience, and transfer a deeper understanding between teller and audience, than those that do not. I wonder if we can use some of these conventions in describing software requirements to aid the communication between users and developers. (Ironically, Story, a book that tells people how to write, is itself written so badly as to be almost unreadable).
Dave Snowden has done a lot of research into narrative and how it can be used for knowledge management. Dave gave a keynote speech and tutorial at XP Day 4, both of which generated a lot of interest among Agile developers. Several, including Rachel Davies, Willem van den Ende , Joseph Pelrine & Tim Bacon, have written about his talk so I won't summarise everything here.
One of the many interesting topics that Dave touched on was how people naturally turn to raw, personal stories rather than collated research when they want to learn how to solve a problem. Furthermore, people prefer negative stories that show what to avoid, rather than positive stories that describe best or good practices. This certainly struck a chord with me, as you probably could guess considering the theme of this blog.
Dave has built a "narrative database" that people can fill with stories and then search for insight into a situation or problem. The search criteria were particularly interesting: a user can specify the emotional intensity of the story, as well as on content. Perhaps a narrative database would be a useful tool for collecting user stories at the start of an agile project before pulling out or synthesising "archetypal" stories to act as system requirements. The emotional intensity of a story could be used to focus usability effort on particularly stressful tasks, for example.
The stationary cupboards in our office contain a few biros and lots of packs of Niceday highlighters. By chance I discovered that the plastic highlighter pack is the perfect size to contain a good sized wodge of 3-by-5" index cards, the essential tool for agile software development. Our team now carries its story cards in neat wipe-clean packs... and our office has more highlighters than we know what to do with.
I recently screwed up when applying an automatic refactoring. I would have thought that my unit tests would have detected the error but the refactoring also changed my test suite to accept the erroneous behaviour.
Automatic refactoring tools are great, but they're not perfect, and if you rely on tests to catch bad refactorings, refactoring your tests at the same time can easily mask errors.
What's the solution?
Firstly, I've got to stop mindlessly hitting the Ok button when refactoring! A skim through the list of refactorings to be applied would have shown me the error before it happened. Some refactorings are safer than others, but any refactoring that affects string constants needs careful review because it cannot use the type system to ensure safety. Perhaps I can configure my IDE to be more "in your face" when a refactoring affects string constants.
Secondly, I'm going to try refactoring my code separately from my tests. If the tests fail as I expect, I will then apply the refactoring to my tests as well. It might slow me down a bit, but the extra step will force me to check the effect of refactoring.
Refactoring is a case of more haste, less speed.
Recently, while travelling back from a client site on the train, I wrote a small web application to guide the very early planning stage of agile projects.
Launch the Agile Project Preplanner...
Note: The tool requires Javascript to be enabled in your browser.
I've been pair programming on laptops recently. Not the ideal situation by any means; the screens are too small and you can't pass the keyboard to your pair without turning the screen so far away from you that it becomes hard to read.
On the other hand, my pairing partner and I both have laptops, the codebase is huge, and neither of us is familiar with it. "Perhaps we could work faster by using both machines at the same time," we thought: one of us could use one to search for information in the codebase while the other coded or we could both search for information at the same time.
It turned out to be a bad idea. We found that we often each drifted away from our common task as we followed separate trains of thought. We also learned different things and couldn't easily share what we had learned with one another, the very opposite of pair programming's intended effect.
The value of pairing comes not from "parallel processing" but from two people thinking about different aspects of the same problem and constantly communicating with one another to keep their understanding of the problem in sync. The constraint of using one computer forces the pair to work in a way that produces the benefits of pair programming.