The Power of Doubt – Becoming A Software Sceptic by Zeger van Hese

I don’t know”. This short sentence can make all the difference. It might not be the answer you want to hear, but be happy when somebody dares to say it to you. It is not a sign of weakness.

Doubt and skepticism can be seen (must be?) as a skill. Skills can be developed. One can start with the following steps;

  1. Observe; look and listen with deliberate effort.
  2. Ask questions; this is crucial. Don’t passively accept what you are told.
  3. Research; do you own fact-checking.
  4. Experiment; can you think of an experiment to test a particular claim before accepting it?
  5. Share your ideas and conclusions with others; this is a great way to get feedback from people who may know more than you about a given claim.

Applying this approach will help to reduce errors. Applying the Specification by Example method (Gojko Advic) can be a powerful aid with step 2 – 5. Specification by example is a collaborative approach to defining requirements and business-oriented functional tests. With specification by example, requirements and tests become one, expressed as concrete, realistic examples. Gojko’s 2 day workshop on this topic is highly recommended.

I don’t want to give away to many spoilers on Zeger’s book, you can download it free:

But. I truly like his Skeptic Manifesto:

A while ago I chose to embrace the skeptic lifestyle. This has taught me to value:

Suspending belief / Rejecting certainty           OVER    Being convinced

Finding things out                                               OVER    Believing what you’re told

Challenging claims                                               OVER    Accepting them

Saying “I don’t know (yet)”                               OVER    Pretending to know

Deciding based on best available evidence      OVER    Sticking with what you “know” is right

Questions that can’t be answered                    OVER    Answers that can’t be questioned


It’s ok to doubt.

Failure is (most of the time) an option

This phrase became well known in the Apollo 13 movie. Gene Kranz (played by Ed Harris) is in charge of bringing back the Apollo 13. He famously said, “We’ve never lost an American in space and we’re sure as hell not gonna lose one on my watch! Failure is not an option!” I can think of other situations where this might be a valuable statement. A mouse, being chased by a hungry cat, would definitely agree. I guess this mantra applies to all life and death situations.

But I don’t think it applies to most real life situations. For instance in the free market, failure is always an option. Startup companies are known for their failure culture. Fail fast, fail cheap, fail towards success by learning the lessons taught by failure. Fail fast is a strategy Agile uses for getting fast feedback. After the feedback the team can adapt and become successful. It’s a smart strategy, as it is fast and relatively cheap.

If failure is not an option, one must believe in the possibility that all risk can be removed. The project will be able to get into a state in which 100% security and 100% of control is possible. This however can’t be done..not by a long shot. Believing you can, is very dangerous for the project. Basically you set up a trap for managers, a trap they easily fall into. Jerry Weinberg reminds us to the Titanic Effect, which says: “The thought that disaster is impossible often leads to an unthinkable disaster“.

So if failure is an option, what do we do now? Let’s start doing some serious risk management. And I don’t mean writing down (and never look or talk about them ever again) only the big risks. Yes a big risk can bring down your project, so can 100 little risks. Start thinking is terms of “what if”. This forces you to have a plan B (or even more, as the alphabet have 26 characters to choose from).

Continuing a project, a project that should be stopped, could get very expensive in the end, and only creates the probability of a spectacular failure. At least build in the option to fail.

The software version of: The Emperor’s New Clothes

People like to hear stories. So do I, stories can give insight to a problem from a different perspective. Recently I saw a parallel between a great story and the world of software. The story is about the Emperor’s New Clothes. Here is the short version of the story.

Many years ago there was an Emperor so exceedingly fond of new clothes that he spent all his money on being well dressed. Two weavers (the swindlers) offer to create a special set of clothes for the emperor. They tell the emperor and his followers that the clothes are invisible to people who are too stupid for their jobs. No one can see the clothing, but no one wants to admit this fact because they do not want to be identified as foolish.

“I’d like to know how those weavers are getting on with the cloth,” the Emperor thought after a while, but he felt slightly uncomfortable when he remembered that those who were unfit for their position would not be able to see the fabric. So he sends in his most trusted men to verify the progress of the weavers. None of them can see the clothes, but none did say so.

Well we all know how the story ends.  The little boy said at last, “but he has nothing on at all”.

So how does this work in our software world? First of all, remember that software (and progress) can be invisible like the clothes of the emperor. The development team can use all kinds of excuses. We can’t (will) show you the software right now because;

  • We haven’t integrated the latest module yet.
  • We haven’t tested the software yet, and don’t want you to run into all kinds of bugs.
  • We have no data in the system. This is planned for next week/month/year.
  • We are currently understaffed due to <some excuse>.
  • The configuration isn’t up to date in the test environment.
  • That’s normal in a <huge amount> dollar project.
  • We never show the software to our clients until the promised release date.

This can happen. Perhaps in the early stage of a software development project. Time flies. Now you have send your most trusted men to verify progress. Are you sure they return with the truth?

When do you need a little boy to reveal the truth about your project? (Will you even recognize the little boy?)

The Uccello clock of software: Agile

Holiday, a great time for reflection. This blog shares some ideas, thoughts about the struggle to adopt agile.
The Trying

I stopped “preaching” about agile some time ago. I thought that if you did something different and important [like running software projects in an agile mindset] – and I did think agile made sense of a lot of phenomena in software development and gave direction that was badly needed – people would hoist me on their shoulders and a carry me in triumph. But that was just incredibly naive.

The Point

Sometimes people even looked at me in bafflement: What’s the point of agile development? And what does any of this agile development stuff have to do with “real” [Waterfall] software development? Questions like this left me at a loss. How could they not see it? The [bloody] point is that you have to look at the world as it is, not as some elegant theory [Mr.. Royce’s article] says it ought to be. But people kept being sceptic.

The “Science”

Nothing wrong with skepticism, it can prevent mistakes, even encourage people to come with additional ideas, but….it Can also stop progress. There is still a lot of skepticism in waterfall minded (traditional very command and control) organizations. Perhaps skepticism is because agile development can’t be called a “science”? Perhaps. But how about geology, or astronomy? Can they predict exactly when the earthquake will come or when the next star will be born? Not at all

The Clock

You might claim that the Waterfall method is still the standard and yes we are locked in to this technique, and that is ok, because… must be superior to its rivals. Clocks are like that, locked in, always running “clockwise”. But the Uccello clock in Florence is running backwards. My point? You don’t have to follow the pre defined Waterfall steps to get results. Pair programming and test driven development (tdd) show it can be done in another way.

The Trap

To answer your unspoken question: Yes it is possible to lock into an inferior technique like the Waterfall method. History shows other examples, like Beta-versus-VHS, the QWERTY keyboard and MICROSOFT software. 

The “Moral”

It doesn’t have to be that way. Within the (perceived) “Chaos” of Agile, you will find a lot of order. this Order will deliver results.

A bug in the bug list

We are currently fixing a lot of bugs in our system. They have been there for a while, but it was time to do some cleaning. During intermediate testing I found a bug, which “should have been solved”. So I asked my colleague Frank to help me out here. It turned out we had a bug in our bug list. It has been there for some while, hiding, staying unnoticed, until now.

From: Frank
To: Ronald
Subject: Re: where did we lose sight of this bug? 

Hi Ronald,

I see. It is neither incident#26 nor one the print bugs (incident#36, incident#201, incident#205). It seems that this incident is described in incident#211 and incorrectly was set to duplicate (to incident#200) by Eric last year and therefore is not in the current scope. I will talk to Jack, to clarify whether he can fix it, yet. We will do so, if the solution does not conflict with others.

Best regards, Frank


From: Ronald
To: Frank
Subject: where did we lose sight of this bug?

So we had a bug in the bug list 🙂

Best regards,  Ronald


From: Frank
To: Ronald (VWM)
Subject: where did we lose sight of this bug?

Hi Ronald, 

It seems that we can fix both (the bug in the bug list and the bug itself), without delay in the planning.

Best regards,  Frank


Well, I have a next action on my (long) to-do list: checking all incidents with status “closed (due to duplicate)”.

NL Doet 2015: zorgboerderij BuitenGewoon 3

Vrijwilligerswerk is belangrijk. NLdoet is een landelijk evenement waarmee lokaal vrijwilligerswerk wordt gepromoot en waarbij gemakkelijk kan worden aangesloten. Dit jaar hebben een aantal collega’s (waaronder ikzelf) van mijn afdeling mee gedaan.

We hebben geholpen op Zorgboerderij Buitengewoon. Om een lang verhaal kort te maken: een geweldige dag, die ik niet had willen missen!

Meer informatie over de zorgboerderij en NL Doet:

NL doet

Software ellende anno 2015: PNOzorg

PNOzorg gaat van een oud naar een nieuw administratiesysteem, en dat gaat niet zonder slag of stoot. Ergens  gaat er iets mis. En vanzelfsprekend zijn de klanten daarvan de dupe. Fijn project is dit geweest PNOzorg. Ik daag jullie uit om het salaris administratiesysteem te gaan vervangen met dezelfde aanpak als het huidige systeem is gedaan. Kijken hoe dat bevalt!

Houten, 27 februari 2015

Onze dienstverlening

Geachte heer Perluka

Aan het einde van 2014 hebben veel mensen gekozen voor de zorgverzekering van PNOzorg. Tegelijk heeft PNOzorg de overgang naar een nieuw administratiesysteem afgerond. Het nieuwe administratiesysteem werkt helaas nog niet zoals we graag hadden gezien.

Door omstandigheden is de kwaliteit van onze dienstverlening niet van het niveau dat u van ons mag verwachten. Zo kan het zijn dat uw declaraties later dan gebruikelijk worden uitbetaald. We worden veel gebeld met vragen hierover, waardoor de wachttijd aan de telefoon langer is dan u van ons gewend bent. Ook kan het zijn dan u langer moet wachten op een reactie op uw e-mail.

We vinden het bijzonder vervelend als u hinder ondervindt. Daarvoor bieden wij onze excuses aan.

Er wordt ok dit moment hard gewerkt om de problemen met het nieuwe systeem op te lossen.

Met vriendelijke groet,


Divisiemanager Verzekerden