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?)


Microsoft fixes ’19-year-old’ bug

IBM researchers discovered the flaw, which affects Windows and Office products, in May this year – but worked with Microsoft to fix the problem before going public.

The bug had been present in every version of Windows since 95, IBM said. Attackers could exploit the bug to remotely control a PC, and so users are being urged to download updates.” (BBC, 12 November,

Wow, fixing a critical bug in the software that had existed for 19 years. 19 years!

I can’t even estimate the amount of testing hours Microsoft did over the years, 19 years it took them to find this bug. According to IBM the bug had been “sitting in plain sight”. (how rude to hide in plain sight)

So this happened to Microsoft, could it happen to all of us? Missing a bug, missing a critical bug for 19 years? Even if you test the software, you asked those testers to test “all” didn’t you? Making a decision to release the software with that bug?


Yes it happens all the time, because we seem to forget/ignore the fact that testing is sampling. There is no way you can test 100% of your software product. You don’t have the time and money to do it. Sure you are testing “risk based” perhaps even in an agile environment.  It is no guarantee you find all your critical bugs.

Microsoft just reminded me of the lesson that you never know all the information about the quality of the product at the time you need it. I’ll apply this lesson next time I hear some saying “I’m done with the testing”.

BBQ & Software improvements

Who would refuse an improvement? Don’t we just love magic wands, we wave them, and voila, instant better results. “You, you, you, you are now a team, good luck”. Or how about this one; let’s implement tool X, and make it a mandatory tool for everybody, that will surely improve our production. Yeah, like a tool will solve our problems…sigh. Jerry Weinberg mentioned this about tools; “Don’t kid yourself. Software users will find ways of not using software they don’t want to use”.

So how do we get better results? Forget about agile, scrum, lean, prince2, automation, etc. Try something easier: practice!

Let me use a hobby of mine as an example: BBQ. It takes great skill to master your BBQ. It takes countless hours of practicing. I’m sure you experienced a terrible bad BBQ meal; burned sate, dry chicken, tough steak, and a destroyed brisket. Most people struggle with their BBQ, because they don’t practice. So how do you practice with a BBQ? It’s so simple! Do a dry run. A dry run is a good practice to calibrate your BBQ, so you know what it is doing and how it reacts to changes (coal burn down, vent openings). No food needed, so it’s cheap, but the information value is high. Today I practice the low and slow cooking with the Snake Method, because I want to improve my skills.

Daniel Pink told us a little secret: People want to get better at what they do. It’s called Mastery. So let them practice.

Request for future bugs

Dear Mr and Mrs. Bug

Please follow our corporate standard procedure of finding you. It will nice if you “hide” somewhere close to a written specification. We especially look in those areas which we assume to have a high risk profile.

We would deeply appreciate your corporation to our request.

Software ellende anno 2014

De tranen schoten bijna in mijn ogen toen ik onderstaande email gisteren kreeg. Het lijkt een verhaal van “zo ontwikkelden we software 40 jaar geleden”, maar helaas ook nog in deze tijd….diepe diepe zucht.
Beste ouder/verzorgers,
Bij deze wil ik u meenemen in een kijkje achter de schermen bij de administratie. Zoals vele van u ondervonden hebben verkeren wij in een nare droom waarbij het ontwaken maar niet wil plaatsvinden.De overstap naar een nieuwe versie van ons computersysteem verloopt op zijn zachtst gezegd niet volgens plan. De aanleiding om over te stappen werd vanuit de overheid bewerkstelligd doordat wij over moeten naar IBAN betalingen. Onze oude versie was hier niet opgebouwd.
Ondanks het feit dat het niet zo lijkt heeft ons team de nieuwe versie uitgebreid getest. Toen was het punt daar om over te gaan. Altijd een spannend moment, maar vol vertrouwen gingen wij over. Het begin van heel veel ellende. De bouwer zette in eerste instantie niet alle onderdelen van de testversie over. Er zaten fouten in het programma en bij het overzetten van de data van het ene systeem naar het oude systeem liep het helemaal mis.  Al weken werken we met man en macht om hier weer grip op te grijpen.
Heel moeilijk wanneer je afhankelijk bent van een derde partij. En u als klant die daar heel veel last van heeft. Na honderden mailtjes te hebben verwerkt, zitten we nu nog met 1 groot probleem. Het betreft hier de vakantiekaart. Daar zitten nog grote fouten in. Wij schijnen als enige klant van de bouwer een strippenkaart principe te hebben, dus hadden ze dit niet voorzien. Kortom, de nare droom wil niet stoppen.
Wij hebben besloten om deze maand de vakantiekaart niet te factureren. Voor de maand juni zou alles opgelost moeten zijn en in een correctierun de maanden mei en juni afgerekend worden. Wij hopen met deze oplossing u tegemoet te komen, zodat er in ieder geval niet teveel geïncasseerd wordt.
Wij gebruiken bij de kinderen Zaaigoed. oa Vraag hulp en Werk samen. Ik wil uw hulp vragen in uw geduld en met ons samen te werken om dit op te lossen. Ik garandeer u dat het allemaal recht wordt getrokken en dat wij alle zeilen bijzetten wat in onze macht ligt. En wij tevens de druk bij de bouwer er volledig op leggen. Het is een mooi systeem, maar het moet wel werken!
Mijn welgemeende excuses dat u als klant hier zoveel last van heeft.
Met vriendelijke groet,
Directeur Kinderopvang 

Why I dislike technical debt

Technical debt (Cunningham) is the debt a company “owes” to a software product. Typical components are complexity, duplications, rule violations, test coverage and documentation. This debt is also known as “software rot” (Hunt) or as “design maintenance debt (Weinberg).” Like any other form of debt, it involves paying interest at some moment, which I consider (usually) a waste. I don’t like waste, so therefore I don’t prefer technical debt.

Let me explain why I am not amused finding technical debt in one of my systems.

IF the quality of the code decreases;
THEN the velocity over time decreases;

Meaning…..we are not adding value to the software at the speed I would like to. My pseudo code will also have statements like;

  • It’s harder to analyze the code = TRUE;
  • It’s harder to change the code = TRUE;
  • It’s harder to test the code = TRUE;
  • The cost of adding new features will increase = TRUE;
  • Everything will take longer = TRUE;
  • More bugs found in production = TRUE;
  • More technical debt added to the product backlog = TRUE;

These are all nice ingredients for an increase in REWORK for the programmers. Rework is hard to plan, leads to multitasking, which leads to a lower productivity and that leads to less profit.

So how will this impact the product backlog? The backlog represents value to the client. Value, the client is happily to pay for, but not to any price. The client will not pay €2000 for a feature which is worth €1000. The consequence is….that feature will not be build. The IT supplier could have made €1000, but now makes €0. And isn’t making money the goal of your company? (I do hope so)

I have seen systems come to a hold due to technical debt. It’s not funny. I don’t like it, I will not tolerate it. Neither should you.


Impossible is nothing

Let’s start 2014 with inspiration:

“Impossible is just a big word thrown
around by small men who find it easier
to live in the world they’ve been given
than to explore the power they have
to change it. Impossible is not a fact.
It’s an opinion. Impossible is not a
declaration. It’s a dare. Impossible is
potential. Impossible is temporary.

Impossible is nothing.”

— Muhammad Ali