me.andering – Willem van den Ende

The causal loop diagrams in this post have been heavily inspired by GeePawHill (also known as American Mike Hill) ‘s  How TDD and Pairing increase production. These diagrams were meant to follow mikes’ story. After they were done, another order presented itself. I recommend you read Mike’s post for some background and an interesting comment thread after you’ve seen the diagrams. I’ll use Mike’s definition of internal quality for this post, and refer to it mostly as ‘quality’.

Zed and Carry are programming an online catalogue for Amazing Widgets.  If they deliver new features for the catalogue faster, their company will make more money, because they can outsmart the competition and draw more paying users to their site. Sure, they have a customer, but he’s on holiday at the moment; he might return for another post . Right now Zed and Carry are chugging through a long list of feature requests the customer left them, so they would not be bored while he was away…

So far they have not made much progress. Carry and Zed are wondering why they are going so slow. Carry read this post by GeePawHill saying “the biggest single determinant in today’s production is the quality of yesterday’s production.”

yesterdays quality is the single biggest determinant of todays' quality

That sounds mysterious. Carry wonders how to write good code today, if everything has already been determined yesterday… It seems kind of hopeless! She was taught in school that the number of lines of code a programmer wrote in a day was a measure of productivity. Now she was wading through file after file, looking for the one line she needed to change. If only the code were smaller, the variable names were not all spelled like I, J and cmd and that whenever she was debugging she would not need to remember over 15 classes at once… All of the decisions they took in a hurry to get the new features in production before the customer went on holiday were now haunting them like the ghost of christmas past…

What determines yesterdays' quality: bad variable names, many dependencies, flawed design decisions and the number of lines of code

They stare at each other for a moment. Zed says “what if today’s internal quality was better?”. What would our code like, and what would it mean for us? Carry dreams away. ” If today’s code were better,  we would have less dependencies and much less code, and everything was so clearly named that I knew where to start working immediately. But I don’t know where to start refactoring! It’s all tangled together, I don’t understand what half the code is doing, it just sounds like a dream. And I don’t have time to work on that dream, because we have to hurry! The customer will return from holiday soon, we need to show some progress. Hmm, Zed goes. I think if we stared naming the variables better in the bit we’re working on now, we could see some improvements soon, it would make our work for this afternoon and tomorrow already a bit easier. With the refactoring tools we have it’s not dangerous at all, and we can always get the previous revision from version control if necessary. We could spend part of our increased speed tomorrow on some other improvement.

If internal quality goes up, speed will increase. This can free up time to improve (but you have to make a conscious choice, hence the decision square). With time available for improvement, internal quality can improve, given you choose relevant improvements and have agreed what improved internal quality means. The 'condensator' symbol indicates there may be a delay. Try to choose improvements that improve internal quality quickly - that helps motivate further improvements. If this works you will get a snowball effect: you will go faster and faster, while delivering ever better quality software.

“That would be great”, says Carry “I’d really like that. But I’m scared to break features that are already working. With all these dependencies I don’t know what might fall over when I refactor. Remember the trouble we had with the helpdesk after our last release? Hmmm… Would you be willing to help me clean up the design in the part I’m working on?”

“Sure”, says Zed, “Why not, I can’t go any slower than I am now, and maybe together we can come up with a way to add some tests as well. I’ve been aching to write some of these microtests, I’ve done some exercises but I just can’t figure out where to start. I’ve heard that it can help you focus on the design as well, and the refactorings would be a lot safer – Come to think of it, I still don’t fully trust our refactoring tool, it seems a bit wonky at times; some refactoring up front would make it easier to add tests, so having your help to refactor would be great, it would be a lot safer that way”.

Test Driven Development, Pair Programminging and Refactoring improve today's quality, so that we can go faster later today or tomorrow. Pairing supports refactoring, Refactoring supports Test Driven Development and vice versa. This leads, amongst other things, to Better Variable Names, Less Dependencies and code that expresses its intent more clearly. Pairing and TDD also help prevent and eliminate defects, but that is a subject for another story.

Carry and Zed sat together, changed some names, did a few commits and eventually found a place where they could start writing a test. To their surprise, adding a few more tests was easy, and they were surprised at how little time it took to actually do these things. Carry had some time left at the end of the afternoon to continue reading GeePawHill’s post:

“If you want to increase the productivity of your team, then do these three things:

write a microtest that fails before you change any code;

adopt a “no-pair no-keep” agreement;

establish a shared understanding of internal quality.”

Zed was happy they did this as well. Tomorrow, they could go even faster! He was almost thinking of working alone again tomorrow and skipping the tests, but thought again. He wanted to go at least as fast the day after tomorrow…

Tomorrow, today will be yesterday. Any improvement we can make today, however small, will help us go faster tomorrow.

After thought

For a long time I’ve been planning to illustrate the value of test driven development through diagrams of effect here.  We’ve been using this to ‘sell’ the benefits of TDD to course participants and folks we mentor for a few years now, and it’s been remarkably effective. The essence is simple, as Marc Evers put it:

“If we work on the same code as you today, and we write tests and pair when you don’t, We’ll be drinking beer in the bar, while you’re still inside fixing bugs”

Well, that’s the benefit for programmers. I haven’t met product managers or customers who dislike getting better quality software sooner either

Undoubtedly, the speed with which this post was written (as well as the lack of pairing and TDD that goes with writing prose in the flow) merit improvements. Your suggestions and comments are most welcome.

I was getting really frustrated about some online discussion today. It seemed other people were getting even more upset than I was (and even that is just one of many possible interpretations. I know from experience that the more frustrated I am, the less reliable my interpretations are). Instead of blowing off steam by firing of a blog post in frustration… which would let steam off on my end but could potentially multiply frustration elsewhere, I stumbled across Habits & strategy for effective listening by David Parnell. and decided to write publish on that instead. Tips for listening in a discussion can be just as useful when reading a discussion. Read the rest of this entry »

I hope I got your attention with this title It’s taken from this video : the Great American Bank Robbery: , taken at the Hammer Museum at the university of California in Los Angeles (hence the many references to california in the presentation and Q&A. it’s message applies to the rest of the USA and other parts of the world just as well):

William K. Black, the former litigation director of the Federal Home Loan Bank Board who investigated the Savings and Loan disaster of the 1980s, discusses the latest scandal in which a single bank, IndyMac, lost more money than was lost during the entire Savings and Loan crisis. He will examine the political failure behind this economic disaster, in which not only massive fraud has taken place, but a vast transfer of wealth from the poor and middle class continues as the federal government bails out the seemingly reckless, if not the criminal. Black teaches economics and law at the University of Missouri, Kansas City and is the author of The Best Way to Rob a Bank Is to Own One. (Run Time: 1 hour, 38 min.)

Read the rest of this entry »

While I was on holiday, Marc started creating a new product from scratch. He’d been walking around with a problem he wanted to solve and couldn’t find anything that he liked. Marc also wanted to try out the Scala programming language, to see if it would be worth using, and thought nothing helps you focus more than building an actual product.

I didn’t get it. But I gave Marc a hand anyway, because we had previously decided that QWAN values:

supporting someone who has a passion over discussing the business case at length

Variazione in scala di grigi by Eric Perrone

Why didn’t I get it?

Read the rest of this entry »

It’s cool to see more spaces opening, the spanish agile user group is hosting Agile Open Spain, 23 & 24 October 2009 .

Xavier Quesada Allue tells me this will be mostly in Spanish. My Spanish stops around ‘donda esta el bano’ and ‘hola’, unfortunately. If yours goes further, this might be for you. Madrid as a location is attractive, and should be easy to reach. No doubt the organisation will be very good as well, and the event is for free!

electronic waterfall by curly_exp( l)osure

In the meantime, if you speak english, why not attend Agile Open Holland – my named cloud is bigger than yours, or is it?, September 10 & 11? Registrations are going fast. At last count we had over 50 participants, with space for about 80. As in previous years it’s looking to attract a good mix of old & new faces, all equally fanatical about uncovering better ways to develop software. It’s not free, but we kept registrations low enough – we hope the value for money makes it a no-brainer; the fee covers part of the costs, but its’ main purpose is to prevent no-shows, so that everybody who wants to attend, can attend. I hope to see you there!

Madrid scenes de rue by George Eastman House

London’s eXtreme Tuesday Club celebrated it’s ten year anniversary last tuesday. Unfortunately I could not be there, so I’m celebrating here, beer in hand, as one should – I find the weekly meetings in a pub with eXtremely interesting folks and the conferences (XP Days) that are organized around it refreshing.

Refreshing by Louise Docker

Read the rest of this entry »

I’m back from holiday and looking to get my swing back with writing.

perfect stranger by daniel sandoval

Before the holiday I wanted to write a post on agile software development and risk management, but it seems the dog ate my fieldstones for that, so I’ll write about the risk of not writing instead.

I liked Johanna Rothman’s advice in The Gift of Time

The best way to prevent writers block is to write

For me it seems writing alone is not enough, it is publishing that gives me focus to go for it. A large collection of notes seems to hinder publishing, because it means I have to chose which of the notes to work into a post, which might mean procrastination. Call it publishers’ block instead of writers’ block if you want, but the end result is the same – less interesting things published than possible. I get around to posting event announcements and reports of those events, because there is some time pressure: announcements after the fact don’t make sense, and reports are more interesting for readers during or right after the event.

Even the draft for this post has been laying around since before my holiday and it contained this advice by Mike Cottmeyer :

It took weeks to write a post because I wanted everything to be perfect… I couldn’t let anything go. The guy I was working for at the time gave me the best advice ever… he told me to get over it. That’s easier said that done… but you know what… that is just what I did. I got over it and started writing.

So I’m taking that piece of advice right now, and may take the next one:

Try to limit your writing to two hours. [...]The idea is that you want to set limits and create a little pressure to perform.

I know from my coaching practice that setting defined timeboxes helps, doing it regularly: even better. How that works and to what I’m applying it right now, I’ll write now publish about it later

Marc already has the scoop, details and a pretty word cloud to explain the theme, so I’ll keep it short and simple. The next Agile Open conference in the Netherlands will be September 10 & 11, in Baarn.

We chose the theme ‘my method is bigger than yours… or is it?’ because it seems that as this agile software development thing goes mainstream more and more people lose sight of what we perceived was one of the underlying goals of the Agile Manifesto: get continuous experimentation and learning going by developing software and helping others do it across communities – hence the signing by people involved in all ‘lightweight’ methodologies at the time. We like the Named clouds meme and hope it spurs some discussions.

Even if this theme does not speak to you, come to Agile Open Holland anyway – anything goes, and new cloud formations are likely to form during the conference. Named ones in the sessions and the hallways, unnamed ones in the sky (we do hope the sun shines most of the time though..).

We proudly announce Photo Suggest, a web application that helps you find photos with liberal licenses to go with your blog entry or slide Check it out.

Dancing Peacock by Hamed Saber

Here’s why:

Read the rest of this entry »

A newsletter is much like software – if you create a larger batch of items, the work grows more than linearly (editing, translating, scrolling, selecting). It’s still worth it though – creating the newsletter on a regular basis helps to reflect on what we’ve done, but also creates focus: what are we going to do or research to make the next one interesting…. The positive response we’ve gotten so far also helps. Marc was kind enough to create a wordle to reveal more of the content:

QWAN newsletter topics, according to wordle

Maybe because of the delay (we skipped May eventually) we not only have more items, they are also longer. We try to keep the newsletter short, but the things we discussed at conferences and while making the product development training gave us some inspiration to explain some topics in more detail. If the topics pique your interest, you can read it online or subscribe.