October 20, 2011

That’s just perfect!

Filed under: Learning,Process,Programming — Freek Leemhuis @ 7:22 pm

I’ve been thinking about the concept of ‘Perfect’ recently.

In our business there’s a lot of talk about self-improvement, excellence and similar concepts.
Often the discussion is lead by ‘agile coach’ types who can not program their way out of a paper bag, but that is another story for another day.
The ‘Perfect’ meme is used to promote Deliberate Practice, as perfection is elusive by design and so by aspiring to perfection we can continue to learn.
Personally I find it a lot clearer to strive for improvement rather then perfection. Improvements are easier to define and measure than an abstract concept like perfection.
Suppose that you would strive to reach old age, would you focus on immortality? You’d probably be off looking for that magic potion. If instead you aim to get older you would maybe decide to obtain a healthier lifestyle, thereby actually increasing the chance to get older.

There’s this quote from George F. Will:

“The pursuit of perfection often impedes improvement”.

By looking for that perfect solution one often finds a gaping void between it and the current situation, making it hard to figure out where to start. If instead you try to think of one thing that would improve the situation, and do this as often as possible, then you are well on your way towards excellence.

The other problem with aiming for perfection is the potential for poor return on investment that more practical minds would point to. We as programmers care a lot about the form and shape of our code, where our customers usually really only care about it’s function. Too much focus on the internal quality can thus be perceived as being wastefull. Nobody will deny you the right to improve yourself and to spend time and energy for that purpose, so overall it would make more sense to use terms like Continuous Improvement (or ‘Kaizen’ if you want to be pretentious about it) then to strive for perfection.

I try to create code that is less sucky everyday, so as to stay in what I call the Zone of Usefulness.

Let me know if you find this a usefull concept 🙂


December 14, 2010

The scientific method

Filed under: Community,Process,Reading — Freek Leemhuis @ 11:42 pm

The ‘scientific method’ – or is it?

I like the work of David Anderson on Kanban, which I think is deserving of the attention it is now getting in the software development industry. His latest post describes the basic principles well. I noticed he and others in the field describe the use of the ‘scientific model’ as approach to improve one’s process. In this post I would like to examine the use of this term, because I think there’s a lot of misunderstanding about scientific methods and how they can be applied to software projects.
In David’s post it is described as follows:

The use of models allows a team to make a prediction about the affect of a change (or intervention). After the change is implemented the outcome can be observed by measuring the flow and examining the data. The outcome can be compared to the prediction expected from the model and the change can be assessed as an improvement, or not. This process of evaluating an empirical observation with a model, suggesting an intervention and predicting the outcome based on the model, then observing what really happens and comparing with the prediction, is use of the scientific method in its fundamental sense. This scientific approach, is I believe, more likely to lead to learning at both the individual and organizational level. Hence the use of the scientific approach in Kanban will lead directly to the emergence of learning organizations.

It makes a lot of sense, change a variable and then measure the difference it makes. I do believe however that some scientific methods are overlooked in this type of description. I’ll try to explain.

Suppose you’ve run a project and you have gathered all kinds of metrics regarding performance of your team. The data shows that since this one bald developer was introduced in an otherwise hairy developer team the velocity increased. This leads you to the hypothesis that having at least one bald developer on the team leads to better team performance. In order to test this hypothesis, you will introduce a bald programmer to another team, and again you collect empirical evidence to see if your hypothesis is confirmed. Again, the numbers show an increase of productivity. You’ve followed ‘the scientific method’, so you can now state firmly that

bald programmers lead to better team productivity.

And you have numbers to back it up.

The example is deliberately silly, you will immediately think of alternative explanations. Quite often, bald developers are of advanced age and therefore on average more senior and experienced developers. There’s all sorts of alternative explanations that would, when true, show the correlation between performance and amount of hair to be spurious. That is one problem that is not easily solved, there can always be an underlying correlation that is the true predictor for the result.
However, the outcome can also be influenced by other factors, and these can be controlled by using methods that are ‘more scientific’.

Let’s talk about two types of controls that are common in social scientific research: the use of control groups and sample distribution.

control groups

In the social sciences, experiments to gather data to test a hypothesis are executed in controlled experiments. Usually, to test a hypothesis a researcher use two different (sets of) subjects simultaneous: a treatment group, for which the effect of an manipulation is observed, and a control group, which uses all of the same conditions as the first with the exception of the actual manipulation. The effect of the manipulation can then be measured by comparing the results of both groups. If you do not use a control group, the data that you so carefully collect might be influenced by factors outside of your manipulation. Increasing performance might for example be in fact due to the fact that the team was working on easier parts of the system for that time, or the bout of flue that was going around and kept important team members from contributing was over by that time. Using a control group will eliminate all factors related to the time of your experiment from influencing the outcome of your manipulation. Well established misinterpretations such as the Hawthorne effect can thus be avoided.

Sample characteristics

Secondly, you’re looking for findings that are applicable not just for the team in question but somewhat broader. But can you say that findings for the one team are expected to apply to all teams in your organization? To do so you need a sample (the team) that is representative for the population (all teams) that you want to target.
In science the sample size and distribution of these characteristics are used to measure the probability that the effect of manipulation is in fact valid for the population. If you want to measure the popularity of Ajax football club in the whole of Holland for example, you would be wise to include people from different age, sex, from different parts of the country, with different incomes and so on. Obviously, the closer the sample size is to the population, the higher the probability that the findings will apply to the population as a whole. We know teams can vary greatly. If you add the bald developer to a team of java developers, the effect might be totally different then adding him to a team of php developers. Adding a baldy to a new team might increase productivity, adding him to a well-established team however could be counter-productive.
There’s all sorts of team attributes that might be important to the effect of manipulation. One should look carefully at the attributes of a team in order to decide if the sample is representative.


I don’t think there is such a thing as one ‘scientific method’. There’s different methods, one more scientific than the other, that can lead to a measurement of probability that a hypothesis is true or false. And sure, in practice it will not always be feasible to improve our process in a rigorous scientific manner. I do think for best results we should at least understand and communicate these factors and account for them where possible.

May 5, 2010

Programming for kids

Filed under: Devnology,Learning,Programming — Freek Leemhuis @ 4:44 pm

Some time ago I was running out of time for the Devnology codefest assignment to create my own Tetris clone. At the same time I was trying to spend some more time with my daughter, who is 8 years old now. She is sometimes very bored from school, which I sympathise with – I was the same at that age I guess. So I thought this would be a good time to try and see if she would be interested in programming. After some research on visual programming languages for kids I to give Scratch a go to see if we could build something together.
It took us very little time to get going, and in no time we had some of the build-in characters moving across the screen. Visual programming makes it relatively easy to grock some of the core concepts of programming. Loops, conditions, variables – you just drag them on a pane and they snap together.

We started out by discovering animation, and this is when something amazing happened. We added some animation logic while the app was running, and it changed its behavior while it was running.
I had a flashback to Alan Kay’s demo on TED – a powerful idea about ideas. If you’ve not seen it, go ahead and watch – it will be 20 minutes well spent.

Reading up on Scratch I found it is actually build on Squeak, an implementation of the Smalltalk language and environment.
After some goofing around we set off to create a simple tetris clone. Except tetris isn’t that simple, and with no means of testing or debugging, one quickly realises this is really an educational tool but not so good in producing something more complicated.
We did get sort of half-way, but it’s fair to say that by then neither of us was enjoying the experience very much.
I’m very impressed with Scratch as a tool for education young children, and it’s a real joy to see the thoughts and discoveries of your child click into place going through some of the basics. Some advice for other fathers: take it slow, one step at a time. After an hour or so trying to explain everyting, it turned out to be a lot to ask for from Hannah. ‘Can I play with my playmobile now daddy?’ Ofcourse you can, just wait while your daddy finishes this real simple tetris game…

March 17, 2010

Adrenaline Junkies and Template Zombies

Filed under: Learning,Reading — Freek Leemhuis @ 8:34 pm

I’ve followed Tom DeMarco and Tim Lister ever since I read Peopleware, a great book about building great software teams. When a new book by these authors (and a few others) came out last year, I ordered it straight away. It’s called Adrenaline Junkies and Template Zombies, and it’s a great list of patterns of project behaviour.
It’s a fun read, although I’m sure for some of my colleagues and former colleagues some of the stories are too close for comfort.
I’ll describe why a few of the patterns really resonated with me:

At one of my previous assignment there were a lot of procedures to follow. Using project management procedures like Prince2 really revolved around having the specified documents in place at certain to pass certain milestones. Usually, the templates for these documents have little descriptions here and there where information is required.At the start of a project, one had to fill in an document listing predefined architectural concerns and design decisions for the system to be delivered. In itself not a bad practice, but ofcourse only valuable if you put the right amount of detail and consideration into it. As a test, I filled in the template with completely inane comments to see who would pick up on it. Where it asked: what are the logging and tracing requirements for this application I wrote This application has no specific needs for logging and tracing other than standard.
Under the heading: what security concerns need to be adressed for the information contained in the database I wrote : the information needs to be authorized by the guidelines specified in the technical design (note: there was at that time no technical design document – this was to be delivered only in the next project phase). You get the picture. I filed the document and it passed with flying colours: all boxes where checked. In reality, it amounted to nothing.
This kind of behaviour is what DeMarco et al refer to as Template Zombies. If procedures are more about form than content, be very careful. The Template Zombies are out to get you.
The other pattern that lends it’s name to the book is one I deal with quite a bit: Adrenaline Junkies. You will find these people in organizations where priorities are constantly shifting to the project that is particular urgent at that time. A new project was about to start, and after calculating the manpower required to finish on time we concluded that a 4man team should start right away to have any chance of actually meeting the deadline. However, after confronting the project manager with this information, he looked at us stunned, and responded: `are you kidding me? There are 10 more projects that we need to work on before we start that one!’
And so we did not start until it was too late, and ofcourse the project was late like any other project they were doing.
This is the thing when you are dealing with Adraneline Junkies: they react rather than consider, and there is no long-time planning, and generally they confuse being very busy with being very productive. There is generally a lot of burnout and turnover at companies that follow this pattern. Junkie behaviour does not scale, and companies that fail to recognize it will struggle to make a long term impact.
Mind you, the book does not really go into detail on how to handle the situations it describes. It merely gives a name to patterns that are, unfortunately, rife in our industrie. When dealing with Adraneline Junkies I have made my mind up to avoid in particular one other pattern mentioned by DeMarco: I will not be a Film Critic. Go ahead and look that one up, and many other similarly apt named patterns.

October 16, 2009

Transfer news

Filed under: Personal — Freek Leemhuis @ 12:42 pm


Working for Logica as a consultant for the last three years has been quite a journey. For a number of reasons, (I won’t bore you with them here) I felt the need for a new challenge, and when the opportunity arose I decided to join IHomer. As of the 1st of November I will become the tenth participant of this group. Delighted as I am with this prospect, I am also sad to leave Logica. There’s some tremendously talented people there, and I have enjoyed my travels with you all.
I would like to express my gratitude to Logica, working with them has brought me many things and it´s been a great place to work.


One of the perks of working for IHomer is, obvious, working from home on a regular basis. I´m really looking forward to this, I´ve created a nice little home office and I´m sure I´ll see a lot more of my girls.

I have commited myself to deliver workshops for Logica later this year, so for my colleguaes: there´ll be opportunities to catch up.

October 15, 2009

On the nature of community driven events

Filed under: Community,Devnology,Events,Learning,Speaking — Freek Leemhuis @ 5:45 pm


lowscore Last week I was involved in organizing a Scala workshop, and from the feedback we received it was notable that some of the issues that were mentioned were more to do with the expectation of participants than with the actual content.The average rating from the evaluation for this event was 7.3 (on a scale from 1 to 10), and while that might seem decent it is dramatically lower then scores for our previous events.Some of the feedback that was provided was very fair. For example, it was mentioned that the tempo could have been higher, and it could have. The typical participants of Devnology meetings have way more smarts and passion about them than any other group I have participated in, so we need to become better at tailoring our meetings accordingly.

Another point of criticism we received was that the facilitators did not seem to know all the ins and outs of the subject matter. This in my opinion is a result of the position we take in organizing these types of events: there should not be one expert explaining to the rest everything there is to know, but rather a situation where there’s enough preparation done to go through the material, and in the process learn from each other.

Under these conditions, chances are a lot bigger that it will be an interactive event, with active participation.

This way, you get to know the attendees, learn what knowledge and experience they can contribute, possibly even beyond the event itself. The meetings will become more lively and interesting, and more in line with the ideas behind the Unconference.

Having an expert capable of explaining everything on a particular subject may not improve the experience, expecially if you lose a level of interaction. We will therefore continue to encourage members of the community to take on a subject and create a learning events that is geared toward learning together.

Obviously, this will only be a success if the more knowledgeable participants are aware of this and willing to share their skills and ideas. If you are aware of points being missed or if you have information or skills that can contribute, one way to react it to sit back and be bored. It might however be better to ask yourself this question: what have I done to improve the experience of this event for some (or all) of the other participants?

Let me paraphrase what this guy said:

Ask not what your community can do for you, ask what you can do for your community!

I don’t mean to sound obnoxious here and I certainly don’t want to put people off from attending. What I hope to achieve with this post is to make our viewpoints regarding these issues clear and hopefully prevent misunderstanding in the future.



Please feel free to respond!

July 17, 2009

DDD Course… coming to a theatre near you very soon!

Filed under: Community,Domain Driven Design,Events — Freek Leemhuis @ 7:23 am

There’s a great opportunity to immerse yourself for 2 days in Domain Driven Design. On the 14th and 15th of September Gregory Young will speak about the essentials of applying DDD concepts in the design and implementation of your application. This is a very practical, hands-on event. Places are limited, so sign up now at

You can see Greg in action in this recent presentation at QCon

May 26, 2009

Speak up!

Filed under: Learning,Personal — Freek Leemhuis @ 1:46 pm

Lately I’ve been involved in a lot of workshops and meetings and one thing I noticed is that when a question is asked in a group of developers, it’s very often the younger attendants that reply first. Sometimes there’s a crop of bright young developers who really know their stuff, but other participants with years of experience just seem to be less vocal. In discussing this observation with a colleague last week it started to dawn on me: it’s not that the younger guys are brighter, they are less inhibited because they can still get away with an answering incorrectly.

If you have been a developer for 8 years or more, and someone asks an innocuous question (what is a function?), you probably know the answer. However, suppose you give the wrong answer, in front of a crowd of fellow programmers. Your reputation is on the line. Better keep quiet, and let the young guys go at it, right?

The best way to learn is to be wrong occasionally, even if it means being painfully wrong sometimes. As a programmer, there’s so many things that you ‘should know’ that it’s near impossible to have all this knowledge readily available. There’s never a better learning moment then these. Being painfully wrong means being wrong once. Being silent can mean being wrong many times. So, mainly as a reminder to myself: it’s ok to be wrong. It’s not okay to stop learning. As the lady says, sometimes you just have to feel the fear and do it anyway.

April 10, 2009

More DDD

Filed under: Community,Domain Driven Design,Learning,Speaking — Freek Leemhuis @ 4:12 pm

The second part of the DDD workshop contained a modelling session (modelling out loud!), which I think helped a lot explaining some of the concepts.


I’ve attached the slides for the second day below.

ddd-day2 slide deck

April 8, 2009

Spreading the word

Filed under: Community,Domain Driven Design,Speaking — Freek Leemhuis @ 7:33 am

Eindhoven, 7th of april 2009, Workshop Domain Driven Design.



Smiles all around yesterday as each participant received a copy of the DDD bible. I think a few heads were spinning toward the end of the evening trying to take it all in. It is hard to cram a lot of the ideas in just a few hours, especially if there’s good discussion.

The slide deck can be found here, and the assignment here.

Second part on thursday, see you all there!

Next Page »

Create a free website or blog at