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

Advertisements

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, http://www.bbc.com/news/technology-30019976)

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.

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”.

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.

 

Book review: Commitment, novel about managing project risk by Maassen, Matts & Geary.

Cool, a graphic novel, brilliant idea to share ideas about the subject. The drawings are very nice. Refreshing to see the main character is a woman, who is supported by her younger sister.

The main idea of the book is about Real Options. Three things you need to know about real options;
1. They have value,
2. They expire,
3. Never commit early unless you know why.

In the story, Rose Randall is appointed project manager to a project in trouble. With the help of a kanban visualisation board she gets control of the state of project. Tasks can have only 3 statuses: ..not started….work in progress…and done. Percentages are nonsense (thank you authors).

New for me was the concept of staff liquidity. This is the time it takes for a team to respond, the time to redeploy people. Based on this concept and the real options model you allocate the most experienced people last (!) to tasks. Experienced people have to most options. This point reminds me about the super programmer you don’t want in your project and the lessons from Peter Drucker (The Effective Executive) about key man dependencies in projects. Really cool stuff.

It’s a great book, which makes you think. I enjoyed reading and thinking about it. Truly recommend it to (project) managers.

P.S;
Once a while I hear someone mentioning the phrase “failure is not an option”…hmm…after reading this book I hope is an option…..I sure don’t want people commit to failure. 🙂

My Appreciations

2013. Definitely not a boring year. I want to appreciate the people who taught me so many things I already knew, but never understood.

I appreciate;

  • The AYE Quartet (Jerry , Esther , Johanna and Don) for the insight that people change one at the time.
  • Tom for his persistence, throughout this year, to remind me that a crisis is just the end of an illusion (Rhonda’s First Revelation)
  • Michael for teaching me projects should start on time, which is not equal to: as soon as possible. (AHA!)
  • Gerald for showing that you don’t have time, you make time. Thanks for listening to all my project war stories.
  • Darek, Reshma, Casper and Anouk for teaching me the best ingredient for successful project teams; professionals who love their job.

Looking forward to 2014.

Quality vs. Speed Simulation; a Project Management Retrospective

When asked the pressing question: “How does a project get to be a year late?” Frederick P. Brooks, Jr. (The Mythical Man-Month, 1975) gave the sobering answer, “One day at a time”. More often than not, projects seem to have to deal with small planning setbacks on an everyday basis. A conference hall has been double-booked, your programmer has suffered more than was expected from the after-effects of a visit to the dentist, the server you ordered has accidentally been left behind in the mail room, a seemingly simple hotfix hasn’t worked. The result is that projects often find there are not enough man-days in a month. According to Frederick Brooks, one of the major reasons for this is that schedules are drawn up under the assumption that everything will go according to plan. But isn’t it so that projects by definition do not run as planned? (Frederick Brooks doesn’t put it in these exact words, but he does give a guarantee of sorts that projects will not go as planned.)

Bearing this wisdom in mind, I put to myself the question of what unscheduled incidents we had encountered in our Quality vs. Speed Simulation (originally thought up by Gerald M. Weinberg). I decided to make a list. The list was meant to help me in drawing up schedules in the future.

The simulation was focused on the quality vs. speed (time2market) dilemma. Small teams competed against each other for the highest possible product score. The product score was determined by the number of bugs that remained in the product and by the remaining budget. The teams did not know the quality of the product in advance. The difficult questions the teams faced included: To what extent and how often do we want to assess the quality of the product (testing)? What price do we want to pay to raise the quality of the product (fixing)? With what (estimated) quality should we launch the product on the market?

Several unscheduled incidents

1. The team consisting of myself, Tom Breur and Ronald Damhof knew one another but had never facilitated this simulation together. A try-out was needed. The combination of full diaries, available space and the availability of the participants made this an impossible mission in the short term. Ronald Damhof had to spend several weeks in the US but luckily Tom Breur’s son Tim was able to come to the rescue.

2. The simulation consisted of an element that required two marbles of different colours. We didn’t have those resources. For us, the days of playing marbles in the playground lay in the dim, distant past and, unfortunately, that also applied to the ranges on offer in toy shops. Online shopping seemed to be the solution but sadly the marbles we ordered never arrived in the Netherlands. Buying in a considerable number of bags of M&M’s resolved the problem.

3. Another major element in the simulation was (Monopoly) money. We had invited quite a lot of people and they ALL turned out to be present! That meant we didn’t have enough money. Who could ever have assumed that everyone who had promised to come, would actually turn up? The consequence was that we quite literally had only had two minutes to print off extra money.

4. The idea was for Tom and Tim to direct the simulation, and that I would try and learn as much as possible as an observer. A well-thought-through plan. Reality proved less compliant. Tom and Tim were running their legs off and I wasn’t able to be with all three groups at once, which meant I couldn’t properly observe the dynamic of each group. We’ll do that differently next time.

5. The try-out took place in a time box of two hours. The most common complaint immediately after the end was: “We want to play the game again!” Maybe so, but there was no more time. Gerald Weinberg’s statement “quality is value to some person at some time that matters” (Quality Software Management, 1992) ran through our minds. Fortunately, in the days that followed we received lots of positive feedback from the participants. If you want to obtain different (read: better) results, you definitely shouldn’t keep doing the same thing. The lessons learned from the try-out were written down. We made some adjustments and concluded, with satisfaction, that we had become much wiser.

6. December 2012, it was winter in the Netherlands. The cold and snow had the country in their grip. Indoors, the heating was on high in the simulation room where the (three-hour long) morning session had started. The simulation was going well and we had not yet been confronted by the relationship between a high room temperature and chocolate M&M’s. However, once the afternoon session was underway, we soon became familiar with the natural phenomenon of melting. A considerable number of M&M’s got broken, and soon, alongside our red and yellow M&M’s, we were also using orange ones in the random samples. Fortunately, everyone was able to see the funny side.

7. We added an extra game element to expand the complexity of the simulation. In the middle of the room we set up a table with pens, paper and calculators. These aids were literally there for the taking and, to our thinking, were very useful. No one, and I mean not one single person, used them.

Conclusions

Naturally, this is not a complete list of everything that ‘happened’ to us, but at least it gives you a picture. Time to take stock.

Even a relatively simple project like facilitating a workshop involves a degree of complexity that inevitably leads to surprises. You can design projects to succeed or to fail. Don’t let yourself be surprised by “an accumulation of setbacks”.

Test your plan early and frequently, and modify it if necessary. A pilot (try-out) or a Hudson Bay Start (Rothman, 2007) can provide you with fast and inexpensive insight into whether or not you will be successful. You don’t need to work in an ‘agile’ organisation to implement agile elements. It’s simply good sense to apply the agile principle of Fail Fast, Learn Fast.

Your ‘single point of failure’ (for example, M&M’s, an essential colleague) will fail during the project. Get rid of it.

And now it’s now time to reflect philosophically on the article. The Temple of Apollo at Delphi is said to have borne the inscription “Know Thyself”. Thank you BIPODIUM for giving me the opportunity to remind myself of lessons I have already learned!