"I didn't know it was hard"

Ivan Sutherland invented the graphical user interface and the lightpen, as well as object oriented programming (he talked about “hens and chickens” instead of objects, a bit more poetic ). I found the quote Steve mentioned on Wikipedia:

“How could you possibly have done the first interactive graphics program, the first non-procedural programming language, the first object oriented software system, all in one year?” Ivan replied: “Well, I didn’t know it was hard.”

Ivan Sutherland with Sketchpad

I’m not sure whether Steve and Michael Feathers (his co-host who was stuck in the USA) intended to have ‘creating a programming language is not hard, as long as you don’t think about it’ as a feature of the workshop, but thinking about it afterwards, every single one of us participated in the design of no less than four programming languages in the space of a few hours! Armed with nothing more than pens, papers, peers and a high level description of the language features we managed to create programming languages that were expressive enough to solve the problem at hand. To be fair, we created examples of programming languages and reasoned about how the examples would run in our programming language. But still, the process felt pretty fluid.

Some things, like designing a programming language are hard, if you think about them a lot. I recently wanted to do more with drawing, as developing and communicating ideas visually is often a lot more effective than working with words alone. I started to ask people who were facilitating with visuals (Rachel Davies, Serge Beaumont) or drawing comics (Chris Matts) how they went about it, and I got a few books on drawing. The overall feeling I took away from it, is that it is easy, as long as you don’t believe that it is difficult; drawing doesn’t have to be hard, as long as you don’t believe it has to be art.

What are the things you are doing that other people believe are hard, while you do it easily? What are the things you believe to be hard, that might be easy if you just stopped thinking about it?

References:

Sutherland, Ivan Sketchpad: A man-machine graphical communication systemPDF (3.90 MiB), Ivan Sutherland’s PhD Thesis.

Sketchpad and Ivan Sutherland pages on Wikipedia.

Dan Roam, The back of the napkin, solving problems and selling ideas with pictures.

Betty Edwards, Drawing on the right side of the brain

We brought one exercise, to be carried out by pair programming. A pair can choose what ever programming language they want to use. We try of course to get an interesting variety of languages to learn from. We ran three 40 minute timeboxes. Each timebox consists of 25 minutes for actual work, and 15 minutes reflecting (about three different solutions presented on the projector accompanied by discussion). Some people switch pairs from one timebox to the next, so they can get hands-on experience of trying to solve the same problem in different languages. The goal of the exercise is not to finish first, or have the cleverest solution, but develop a solution that is idiomatic in the language one is solving it in, so that we could compare notes afterwards.

This time we had three pairs working in smalltalk (cincom smalltalk as well as squeak), two pairs in ruby, two java, and further pairs in Scala and Haskell.

A few pairs wrote examples using Rspec or Scalaspec, most pairs wrote ‘classic’ XUnit style tests. Some worked completely outside-in, other bottom up, and quite a few from the middle outward (me and my pair amongst others).

Some things that struck me:

• at least one of the smalltalk solutions I saw did not strike me as very idiomatic smalltalk (admittedly, the presenter said it needed refactoring, so they went for make it work/make it right).
• Nat Pryce noticed that collections were processed easier (and with less code) in the Haskell and Smalltalk solutions than in Java.
• The smalltalk pairs were the first ones to finish setting up their development environment and getting to work (Rob did a timecheck, the smalltalkers were the only ones working on the problem already). Having an environment that contains almost all the tools and libraries that you need gives a big speed boost at the beginning. What was more striking still was that all smalltalkers used environments they just installed and had not used before; I installed squeak last weekend, the others were using a fresh beta version of their environment.
• Many people had not seen (much of) haskell/ruby/smalltalk style of iterating over collections using blocks/closures, luckily these idioms seem to be trickling down to Java and C#.

As with the previous instance of Flying Horses, the Haskell pair was moving towards a complete solution the fastest. This may be because the exercise we use seems to find itself in Haskell’s sweet spot (parsing and manipulating data).

On the whole, the level of engagement was pretty intense (about half the participants continued working through the breaks, even though we emphatically tried to get them to stop ), participants said they got to see some very different ways of solving a problem from what they knew, so they came out of the workshop with puzzles to investigate further.

As one participant mentioned, code presentations work up to a point. They show what a pair has done, but it is hard to see what steps they have taken to get to the solution. Seeing the sequence of steps (and experiencing it) when you are part of a pair (especially with someone you don’t know) is very valuable. I’m interested in suggestions for getting more of the sequence of events (rather than the solution) out into the presentations.

We have tried letting people work with task lists and presenting from there (works somewhat, but may cause pairs to loose to much time on their small design up front).

Let a thousand languages bloom Below are the flipcharts summarizing some of the things people learnt from the workshop.

At the GOOS Gaggle I heard David Harvey praise the upcoming SPA conference because of its’ great keynotes (and yes, they are going to be fantastic). But to me SPA is not a sit-back and relax conference. The main reason why I’m going are the hands-on sessions and simulations. This year we’ve got even more hands-on sessions than last year, so much so that we’ve got more than a complete software craftsmanship track. Whether you are just a programmer and like to program with your peers, or you fancy yourself a software martial artist sweating it out in the coding dojo with fellow code-okas, this should be a lot of fun and very effective learning and experimentation. The language track (to introduce and explore various programming languages) also has lots of hands on sessions. This year for instance on Scala and Clojure, and  if you are lazy Haskell is present like at SPA2009, but now from a more day-to-day development angle.

Of course, if you want to rest (or don’t program at all) there’s good discussions to be had in the design track (and even there several hands-on sessions) and simulation games in the People and Process track.

Take a look at the programme , I hope to meet you there.

I planned to write individual posts about new and upcoming workshops, but the rate at which we get invited and accepted to conferences this fall outstrips my ability to post new entries I have to post now, before the conferences themselves are over… I hope you’ll join us for at least one of these. We’ll be doing some hard-core programming workshops as well as more enterprise and facilitation oriented sessions this fall.

First up is Scan-Agile next Thursday and Friday in Helsinki, Finland. Marc already wrote about our Story Testing workshop.  I’m also very much looking forward to participating in the Scan-Agile Open Space, which now has its’ own day.  The main reason for me to return to Scan-Agile this year, is that last year it had very strong participants (and presenters, but good session organizers are only part of what makes a conference worthwile). Having my own unit tests ripped to shreds by critical participants was interesting and valuable. So I’m glad this year all participants get more space. We had some discussion on Twitter about ‘is kanban a failure mode of lean? (and what that means if it is so)’ that merits more than 140 characters… should make for lively open space as everybody involved in that discussion will be there . If I haven’t motivated you to join us, check out Vasco Duarte’s series of motivational posts about Scan-Agile.

Next up is the Practical Product Lines conference , October 20 and 21 in Amsterdam, Netherlands. There we will be hosting a value stream mapping workshop, as described by Marc. We decided to try out more conferences outside our regular schedule of agile conferences – preaching to the choir is fun, and helps us improve our understanding, but going out into the world and sharing what we’ve learned is at leas as valuable. We thought it would be interesting to bring our understanding of value stream mapping, and take participants’ experiences with product lines, should provide an interesting mix.

Freek Leemhuis of Devnology asked us to send in some proposals for the Devnology community day, saturday November 7 in Baarn, Netherlands.  We did, and they chose three of QWAN’s sessions for the program:

Refactoring to concurrency (with Scala) grew out of a series of commits I did for a product I’m developing with Marc, micro-ISV style. We needed some background processing to make our application more responsive, and I wanted to take small steps, be sure that it worked and have everything covered with tests. So I first refactored, until introducing concurrency was just a one character change. This session shows you how to do the same thing, with scala or another language.

Flying Horses – cleaner code in other languages. This session was inspired by a dojo description from Emily Bache (I don’t have the link handy right now, will insert it later). Rob ran with it and tried it out at Agile Open Holland last month. We’ll bring an application written in one language, everybody gets their laptops, a pair to program with and translates that to their favourite language. At first as literally as possible, and then make it ‘more like their language’. Then we will discuss what makes code, e.g. pythonic, javaic, C-sharpish etc. based on the examples we just created.

Give your code some love is a demonstration (a series of prepared katas) of us doing tiny refactorings on code that looks allright at first glance. Tiny refactorings then show that there are quite a lot of things we can do to make the code express its’ intent better. This session was heavily inspired by Ivan Moor and British Mike Hill ’s Programming In The Small workshop at the software craftsmanship conference in London earlier this year.

Jfall, conference of the Dutch Java Users’ group, November 11 in Bussum, Netherlands, sees Rob and me doing TDD As If You Meant It, inspired by Keith Braithwaite’s session of the same name at, again, the software crafsmanship conference in London. Keith kindly gave us permission to reuse the name. We are happy to see more people applying unit testing. Very few, however, seem to be really doing Test Driven Development. In this demonstration we hope to give the audience a taste of what test-first programming can do for you.

Xp Days Benelux, November 23 and 24, Mechelen, Belgium I already described Retrospective Hero with Nicole Belilos of Task24 and Agile Politics – (re)discover the politician in you at XP Days Benelux with Emmanuel Gaillot of Pyxis

and Finally, XpDay London, December 7 and 8th where I’ll be pair facilitating the Open Space with Rachel Davies.

Wille Faler asked on Twitter earlier this week about how people who go to conferences a lot do work. All of the conferences above are one, maximum two days, that leaves plenty of time in the rest of the week to do ‘actual’ work.  The other thing is, writing is a poor medium (for me at least, even though my blog does seem to travel reasonably well these days) to show our passion for software development, going out to conferences helps us connect with other people who are equally passionate about our profession. And sometimes this then leads to actual work. Which leads me to the following:

Shameless plug:

At the moment I’m looking for a new project to work on, either as a developer, agile coach and/or project leader. contact me if you know of a place where my skills would add value. Also, all of the sessions above and more are available as customized in-house training.

Sandra, one of the product owners, explains her point of view, Serge listens intently as facilitator

Now, lets' hear the second group of product owners, with their position

Nicole and I thought it would be fun do design a simulation game around facilitating retrospectives. At first we came up with a sort of board game, but after some brainstorming we thought a role-play would work better – our board game was turning out to be a bit too simplistic for our taste.

These are the benefits we proposed for our session at XP Days Benelux 2009, November 23/24:

• Learn new techniques by applying them to a simulated real world situation
• Experiment with techniques you already know – do something different with them
• Hold an emergency retrospective to ‘get to the bottom of it’ and come up with sustainable solutions quickly.
• Get some fresh ideas to do group reflection on emergency situations and longer timespans

At XP Days we have an hour and 45 minutes, for the try out at Agile Open we decided to see what we could do in a 60 minute timeslot to get as much feedback as possible on our game ideas. For the XP days version we were thinking about playing two simulation rounds, in which the participants get to deal with a) facilitating during an emergency situation and b) facilitating a retrospective over a longer period (weeks or months).

We were most curious about facilitating in an emergency; what we expect to learn from these simulations as hosts is observing facilitators ‘in the wild’ under controlled conditions and seeing how they behave, and what techniques work in which circumstances (we have our preferences, but they do not necessarily end up in the simulation). For the longer-term retrospective part we still would like to do a trial run. contact me if you’re interested in hosting it.

Therefore we designed a role play that happens in a Bank, something went terribly wrong and after the facilitator comes in on a monday morning he or she is asked to facilitate a ‘hero retrospective’ : find out what went wrong quickly and get the group to agree on some actions.One or two participants play facilitator, while the other participants play roles like product owners, helpdesk boss, development team and systems administrators. We give everybody an overview of the situation, and then each role receives an envelope with a more detailed description of what happened from their point of view. This leads to a group situation where everybody has partial information, so one of the challenges for the facilitator is to surface all the relevant information quickly. (I won’t say much more, because I fear that would spoil the simulation in case you come and play it…)

We creatively brainstormed the situation and roles based on our own experiences. And it worked. One of the players asked me ‘does this happen?’ about something that I experienced during a meeting; some of the assignments and poses of the roles seem far-fetched, but things get political when people have to divide resources, and as a facilitator you’d best be prepared to not be surprised about that

You might say ‘that is not a retrospective’, and you may be right; that is something that we want the participants to figure out and discuss in the debrief. And at Agile Open they did. Participants found that for effective facilitation you need to find a technique and style that fits you, the participants and the context. Some ‘participants’ preferred a ‘businesslike’ style, focused on only content, while others seemed to prefer also getting the mood of the people on the table.

In writing this sounds like knocking down an open door, but the emergency role play was pretty intense, with at least one facilitator behaving differently from his own expectations. We really did manage to create a stress situation .

Now we have to pick up the pieces and figure out what to do next with the simulations and the workshop. The participants gave us a good amount of useful feedback. The roleplay worked well, so we are going to keep that, but how to fit it into an overal workshop seems to, ehh, depend . We introduced two techniques before the simulation, and encouraged the facilitators to use one of those two. Next time we may only chose one, and see how that compares between groups, or alternatively (especially in an in-house course where we have more time), start out without a specific suggestion, roleplay and learn from the debrief, maybe explain a technique and try again, and see what difference that makes.

In reviewing the session for XP Days, Pierluigi Pugliese suggested we add observers to the list of roles, and give them specific instructions. That seemed to work well.

Jorrit shares his observations with the group

Since we are operating a kind of pull system for workshops, we asked ourselves beforhand: what do we want to learn from the try-out (does the simulation work? This is the first roleplay I helped create.), and what is the least amount of work we need to do to get that feedback. Therefore we created all the role descriptions in dutch…

Deborah Preuss wanted to participate, and while she speaks and understands a couple of languages, dutch is not among them. So we improvised and gave her, as an observer, the task to observe and interpret body language. Because of this the players learned about the effect of finger pointing, and that they were doing it without realizing it… The debrief was interesting. Deb noted that at some point several players’ body language indicated they knew enough and were finished with the discussion.

Deborah observes body language of one group

From the players’ perspective that was partially true: some of the players were finished with the discussion, not because they were satisfied, but because they realized they had nothing to gain by the meeting, as their concerns went unheard (and unacted upon).

For those of you who asked me what Retrospective Hero was, and what it was about, I hope this cleared it up a bit. I welcome your questions and suggestions. For those of you who participated or observed, we’d love to know what you feel about the game after a few weeks.

In any case, we hope you join us at XP Days Benelux 2009 to experience the extended version

“You have some experience writing unit tests, but wonder how you could get more out of unit testing. Register for the Mastering Unit Testing training to experience how test driven development can make development faster and more enjoyable. You’ll learn how working test-first lets you create better designed code, and understand why unit testing techniques that are ’simple’ in theory can be difficult to practice. Past participants have experienced less defects in production code, as well as higher velocity, which leads to happier clients and more fun in your job!”

See the Mastering Unit Testing page on the iLean site for registration and details. The first course is scheduled for September 24 and 25. After that we’ve also got our Mastering legacy code, November 16 and 17, also in Antwerp.

Televox by d.billy

photo found through Photo Suggest

The Trousers of Reality Book Cover

Barry Evans works as an independent consultant and writer, and is based in France and the UK. I met Barry a few years ago at Agile Open in Belgium, when he was working as a senior coach in BT’s large-scale Agile introduction. Now we’ve done an interview to find out more about his new book “The Trousers of Reality”.

Willem: So Barry, When did you start thinking about writing a book?
Barry: I have always been a writer. I come from a literary family and it was always something I wanted to do..
Willem: what triggered you to write this one?
Barry: I started writing this book when I realised I had something to say and I had enough life experience behind me.
Willem: what experiences in particular inspired you?

Barry Evans

Willem: In your book, you discuss a number of techniques, besides Agile also NLP, Systems Thinking and the Theory of Constraints. How do they help to improve business and private life?
Barry: I talk about things like NLP because it allows us to communicate better – this is useful everywhere.
NLP in particular concentrates on seeing the other persons point of view – it is not hard to see how this skill is useful talking to both your colleagues and your significant other.
Willem: indeed.
Barry: As you get good at it in one situation you must get better at it in all others – it is a skill that takes constant practice.
Willem: like playing the piano, programming, or writing….
Barry: Funny you should mention that – I use almost the same example in the book.
Willem: I swear I haven’t read it yet:). I’ve just been thinking a lot about deliberate practice recently.

Barry: When I looked at Agile and my experience as an Agile coach I realised that what Agile was doing most was clearing the lines of communication and trying to get rid of presuppositions on every side.
Willem: so that fits nicely with NLP then.
Barry: NLP is concerned with just that and has proven tools, so I said to myself – why reinvent the wheel.

Willem: that makes sense.
Barry: It also fits into systems thinking which shows how things are interrelated. You need to be able to see outside your job, categorisation, sphere of influence, interest, skill-set though.
Willem: yes, and that is a hard soft skill to master.

Barry: When I started looking at these things I noticed that they all had an intersection point and that interested me greatly.
Rather than the ceremony of Agile I started to ask myself why does it work and isn’t it interesting that other things that work all seem to intersect at a subset like a huge Venn diagram. In this intersection I started to find things that worked everywhere – therefore back to the work/life thing.
In fact that started to be my litmus test. The things with real value tend to work across borders of every kind or they are parlour tricks with limited shelf life.
Willem: so how do you distinguish one from the other?
Barry: In my experience with Agile and software development I began to realise that too much was being hung on which tribe you belonged to. Tribalism is the great enemy. My mission with the book is to tell people that whatever tribe you think you belong to that there are things that just work and it is power to understand why they work.
Just clinging to a tribe will leave you out in the cold sooner or later – it blinds you to what is really happening.
Ritual and ceremony were the target of Agile and they seem to have crept in under the door again – I want to call it before it is too late. Indeed NLP has the same problems and the same solutions. Understand the principles and why you are doing what you are doing…. If you really understand it you can turn it into a process for convenience; but you must know when and how to change that process.

Willem: how do you distinguish people who follow “the rules” by rote from those who genuinely want continuous improvement?
Barry: Well the quick answer is experience. It is also trust. If you are a business you hire people who genuinely know what they are doing and who are not afraid to tell you home truths. There is no lazy way out.
There are thought leaders and professionals who are clearly interested in making things work. Identify them. It is also important to develop your own ability to distinguish – based on experience and knowledge. I say in the book to beware the “One Truthers”. Look for flexibility and things that work in variety of environments. Be suspicious of spin and hyperbolic claims. In the end it comes down to Einstein’s advice – Everything should be made as simple as possible, but not simpler. Whereas Occam’s tool was a razor – Einstein uses a vice to similar effect.

Willem: The one topic you cover in the book that we haven’t discussed so far is the Theory of Constraints. How does that fit into all this?.
Barry: There is a chapter in the book called “The Key”. It explains what these things are and ties them together. Essentially TOC allows you to examine cause and effect and is a tool to work your way out of assumptions and constraints.It is great for helping you to understand your current reality so you can start to step up into systems thinking.

Willem: what have you learned from writing the book?
Barry: That writing books is great fun and marketing is hard work. Of course I did a lot of research and as I said in the book the real secret to life is to keep learning. It opens possibilities and opportunities. This is the great thing about what we do if we are involved in IT – we keep pushing our own boundaries of knowledge and what we think is possible.
Willem: yes, that is what got me into IT in the first place. Marketing folks would say that marketing is fun and writing a book is hard work, though .
Barry: Part of the secret of managing people is realising that what you like to do, or do not like to do, does not necessarily map onto other people. You must have empathy but at the same time realise the others feel differently to you. It makes it fun to work with people you do not understand, when you see that lack of understanding as a new model of the world to learn about. And you can be delighted that there is always someone out there you can work with who will like to do the things you do not – great teams are made of this sort of interaction.

You can find out more about Barry Evans and this book at The Trousers of Reality’s website.

It has behooved the XP Days Benelux conference to allow playing of devious political games in its program. Join Emmanuel Gaillot and me on November 23 or 24 so that you can (re)find the (dirty?) politician in you.

“Cheney Satan ‘08″ by futureatlas.com

Photo found through Photo Suggest

(Well, you don’t have to get as dirty as the photo suggests, but you will have to put up a fight for your cause )

We will play politics – in a game you will represent a political faction that tries to get an alliance of agilists to spend money the way you prefer.  Convince others to vote for you so you can carry out your program, or choose another party to do what you want for you… Will you be trying to convince the voters to spend money on conference organization, advanced agile research, business 2 business schmoozing, or something else entirely?

After playing the game we will debrief our experiences and draw parallels with everyday work. It may be that you are already aware of the politics around you.  In that case the game can help you understand more about your behaviour.  It may be that you believe your work has nothing to do with politics.  Think again… it may be that you are a “spoiltician” – someone who has “delegated” that dirty politics to others (e.g. your boss . This game will show you how political many common project decisions are. Whether you care about corporate politics or not, they have an impact on your worklife. Regardless your status, be it an opinion leader, a reckless reformer or “just a programmer” in the silent crowd, this workshop is for you!

Benefits:

• Learn when politics happen
• Get a better grasp at why politics happen the way they happen
• Experience your own behaviour and that of others – it is the situation that is politically charged more than you
• Try out various political strategies and safely observe their possible outcomes
• Have fun!

In case we haven’t convinced you to join, maybe we can offer you a bribe or a kickback? (In case you are american, we may also have some pork available for projects in your home state, to be executed by the companies you love )

Agile Politics Workshop, November 23 or 24, XP Days Benelux, Mechelen

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.