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: https://testsidestory.com/2016/11/16/the-power-of-doubt-becoming-a-software-skeptic-paper/.

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 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…..it 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:
http://www.zorgboerderijbuitengewoon.nl/index.html
http://www.nldoet.nl/

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,

PNOzorg

Divisiemanager Verzekerden

Dealing with big systems, some considerations

As ambition goes up, organizations try to solve bigger and bigger problems. This often leads to bigger systems. This is fine, but does need some awareness of management. Bigger can be done, but it does have a price.

– As the size of the system increases, programmers (or project members) need to consider more side effects for each found error. Think of side effects like the size of the code, the quality of the code, design integrity, testability of the code, completeness of the documentation, etc. The price –> maintainability costs will suffer if these side effects decrease.

– As the size of the system increases, both the number of faults as and the number of places to look for faults will increase. The price –> both effects have a negative impact on the total time to find the fault(s).

– As the size of the system increases, the complexity of the system increases as well. This causes a problem, because one’s ability to manage complexity remains a constant. You just can’t increase the capacity of your brain (hiring smarter people has limitations), like you can increase a hard disk on your computer. Adding people to manage the complexity is limited due to Brook’s Law (Man Mythical Month).

So how to deal with these challenges?

Make use of good software engineering practices. They are invented for a good reason, use them wisely. Good engineering practices are; technical reviews, a solid definition of done, or something like a requirement management tool. But please consider the context, please don’t just apply a “best practice”.

Reduce the size of the system. Eliminate something. Yes elimination. Eliminate the scope, drop specifications, cut the worst part of the system, remove the least valuable part, eliminate that feature that isn’t finished yet.

Invest in your own people, don’t get addicted to (expensive) hired consultants.

Allow for extra time.

Note: the story still holds if you change system by project.

The map and the territory

When the map and the territory don’t agree, always believe the territory.

— Jerry Weinberg —

What does this have to do with software? Everything!

This dictum is valid in many ways:

• Does your documentation really match your software?
• If the software metrics are good, why is your software maintanence department so busy?
• The software is built conform specifications, why are users complaining?
• Are you confused/upset about a missed deadline, perhaps the plan (the map) doesn’t match reality (ouch).

My advise? Update your map, so it matches the territory. Oh, I understand that’s hard and possibly painful (on limited resources like time, money, manpower), but not updating .. is that really an option?

Technology Transfer (part II)

Monday, the Technology Transfer started. What happened? Well, take an educated guess. We are still trying to find out what when wrong and why…sigh. No news anymore from the migration team. Yeah, let maintenance solve it…..sigh.

The Plan
Yes, the migration team made a plan. Thou salt have a plan to lead thee out of the wilderness.

It was a specific plan, very detailed. The plan contained activities, durations and involved people. Not bad, a plan helps building structure. Unfortunately, something went wrong (OMG). How was that possible? Hmmm the plan lacked an activity called “solving problems”…

Simple math
The assumption of the plan was that all the activities would be successful (100%), none would fail. Let’s think. What is the assumption was different? What if we say that each activity had a low probability of failing, say 5%. That means that the chance that at least one of them will fail is nearly 65%. That is, one minus the 20th power of 0.95. That’s no rocket science, but simple basic Math.

I don’t know yet when we will finish this migration. Luckily, this was the migration of the Acceptance Environment.

No happy ending yet…..

The Ten Commandments of Technology Transfer

Technology Transfers, I just dislike them, especially when they are driven by the IT department. No matter what they tell you, it’s always more complex and end users usually suffer.

A major Technology Transfer is currently taking place in my organisation. The Big Cheese decided all applications will have to move from the current data centre to a brand new one. Sure, if the Big Cheese decides so, it will happen. What could possible go wrong? It’s “only” moving a server to another place…the software doesn’t change. This can be done quickly.

May I suggest a little reading dear Project Team? Try Quality Software Management volume 4 Anticipating Change, chapter 23.5 Jerry Weinberg discusses his Ten Commandments of Technology Transfer;

• Thou shalt have a plan to lead thee out of the wilderness.
• Thou shalt not worship thy plan.
• Thou shalt not ask for no person in vain.
• Thou shalt not work 7 days a week.
• Thou shalt honor thy users and listen to them.
• Thou shalt not kill support for change.
• Thou shalt not adulterate from the work.
• Thou shalt not steal resources from the work.
• Thou shalt not bear false witness against thy plan.
• Thou shalt not covet they neighbor’s optimal technology.

After reading this chapter, please don’t ask me to agree with a testing period of maximum 10 minutes. Don’t be upset anymore if I don’t want to work on my free day, after all it is my day off. I spend my days with my kids, and you didn’t consult them when you made your planning. I wish you all the best with the Technology Transfer, you will need luck.

Much appreciated.