Your need for speed, sponsored by TDD and pairing

Tuesday, September 1st, 2009

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

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

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.

internal_quality_speed

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, Pairing 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

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:

  1. write a microtest that fails before you change any code;
  2. adopt a “no-pair no-keep” agreement;
  3. 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.

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.

Refactoring in Paris

Tuesday, December 23rd, 2008

In other news today:

Emmanuel Gaillot just blogged about our upcoming French Refactoring Training.

January 28 and 29 at the office of Octo Technology in Paris. This training will be in French. We ran it together in-house (also in Paris) and it worked quite well :) . The training was good fun, we did even more things dojo-style (including demos) than I normally would, and we made time for hands-on systems thinking. I think with the experiments we’ve done this year, that we’ve finally found a good way to do systems thinking with programmers. It seems to be a bit more intuitive for managers and coaches,  but presented in the right way, it turns out developers find it eXtremely valuable. Surprisingly (not ;) ) the topic the developers chose for their diagram was not entirely technical: how too much labour turnover was hindering their productivity and maintenance.

In other other news: the QWAN newsletter is out. It has some instruction on how to do your own temperature reading, conference reports and the public courses agenda. Enjoy!

Now it is time to relax after a  busy and period. Maybe I’ll finally get around to posting photos from all the conferences we’ve been to since october…

Step away from the keyboard, and put your hands where I can see them

Friday, July 4th, 2008

When we let participants pair program in courses, it is always difficult to make them stop… Over time we have experimented with various techniques. Marc and I are at the ESSAP summer school this week, and we needed to pull out all the stops – they were that focused :)

Techniques we used to get people to stop

  • Pomodori (kitchen timer set to 25 minutes, with 5 minutes in between), it makes noise, so some people stop.
  • Marc’s Horn – this gets some more peoples attention
  • and finally this:

I shout “Step away from the keyboard, and put your hands where I can see them!”.

That gets everybody’s attention (and laughs). We are having good fun, and seem to have found a good way to explain refactoring when you are almost having some tests :) (more about that later, hopefully).

More pictures from this session (including the retrospective stickers)

The joy of Refactoring – Reveal intentions

Wednesday, November 7th, 2007

three programmes staring at code, going - ohhh. Text on photo says: Reveal intentions - write code for who comes after you, not the computer.

 

 

This is a slide I made for a workshop on Refactoring Legacy Systems I ran yesterday. I love the puzzled look on their faces.

The photo was made in the open space at agile2007, featuring JB Rainsberger and two others (sorry, remembering names at large events like agile200* is difficult for me – the guy in the middle was a volunteer in a session I co-hosted at agile2006).

The agile2008 call for participation is out, to give you an idea what is going to happen. Major change for next year is the idea of stages, each stage with a specific theme.

 

Close to my heart is of course:

 

Agile and Organizational Culture
Producer: Marc Evers; Assistant Producer: Linda Rising
Agile is not only about changing the way you work and changing the way you think – doing agile in a sustainable way requires changing principles and values. An agile initiative doesn’t take place in a vacuum, it has to interface with the existing organizational culture. It will influence the organizational context and the other way around. This stage provides a space for discussions, teaching, learning, and sharing experiences about agile and organizational culture.

Space for new session organisers and pushing the envelope:

Breaking Acts
Producer: Laurent Bossavit
Agile as it stands today is still a work in progress. For Agile software development to remain relevant, it must incorporate new ideas continuously. This stage is for speakers who bring a fresh and surprising look to aspects of Agile we thought familiar, and speakers interested in ideas that are relevant to Agile but not accepted yet as “mainstream”. First-time speakers are particularly welcome.

And of course, another Open Space :)

Open Jam
Producer: Esther Derby
The regular program presents a wide range of presentations and experiential sessions. The Open Jam stage is a place to share questions and quandaries, talk to the experts, demonstrate software and techniques, and experiment with emerging Agile practices and ideas.

There’s also a francophone stage, hosted by Emmanuel Gaillot, since Agile2008 will be in Toronto, Canada. I will be visiting Toronto December 6 through 9 for an agile alliance board meeting – that way, board members involved in the conference organisation can combine two things in a trip. Let me know if you’re in the area and would like to go for a beer :)