Archive
The consequences of a bug fix
Take a good look at this guy. What, you didn’t know who he is? Of course: he’s pope Gregory XIII, who created the Gregorian calendar.
Here is some Wikipedia quotes about the calendar:
The Gregorian calendar is the internationally accepted civil calendar.[1][2][3] It was introduced by Pope Gregory XIII, after whom the calendar was named, by a decree signed on 24 February 1582, a papal bull known by its opening words Inter gravissimas.[4] The reformed calendar was adopted later that year by a handful of countries, with other countries adopting it over the following centuries. The need for the Gregorian reform stemmed from the fact that the Julian calendar system assumes a length for the mean tropical year of 365 days and 6 hours, when the correct value is 365 days 5 hours 48 minutes and 45 seconds. At the time of its introduction the actual date of the vernal equinox was imperfectly known. At the time of the reform the length of the mean tropical year was also imperfectly known. A 400 – year intercalary cycle was introduced which gives an average length for the calendar year which is 27 seconds too long. In the twentieth century Eastern European governments, on the advice of astronomers, introduced a version with a 900 – year intercalary cycle which gives an average length for the calendar year which is only two seconds too long.[5]
When implementing the calendar, 11 days were removed to get in line with the new calendar.
During Agila Sverige, Albin Rännar from Nordic Investor Services, besides from giving a very interesting speech on the death of the budget, explained some of the problems which evolved from the good pope’s new calendar.
If you just look at the description, it looks like a really good idea to reform the calendar. In other words, fix those bugs in the calendar.
But as Rännar pointed at: what about the short term effects? Let’s say that you had a contract with a contractor and according to this contract, you would deliver on July 14th. And then suddenly, there was no July 14th. What then? And even if the actual date was not removed, you might loose 11 days during which you could complete the delivery.
Another person (sorry, but I don’t remember exactly who it was who told the story) then told us about another problem they had when they fixed bugs. Sometimes there was a bug which users used in their business and by fixing that bug, a business opportunity disappeared with the release and without any warning.
And this brings us back to the definition of a bug. For the poor contractor, the missing 11 days was a bug and for the customer losing his business opportunity removing that loop hole probably feels like a bug.
Sometimes fixing a bug feels like creating one, even if there are no regressions.
Presentations from Agila Sverige
can be found here. Most of it is in Swedish, but some is actually readable to a non Swede too. For example
If you understand Swedish, I must recommend this presentation on T-competence.
We are the knights who say [process artifact]
The other day on Agila Sverige, we discussed agile in an environment where Operations have implemented ITIL. The discussion moved to why ITIL is implemented. Operations want a stable production environment and all changes are a risk to that environment. By keeping that gate and requiring all these artifacts, chances are greater that no one just install something which doesn’t work.
Since it was also Monty Python Day, I couldn’t help thinking about this wonderful sketch and I cannot help but recognizing myself when I’ve tried to get something done. I ask for something and someone shoves a process artifact down my throat. You said what? What did I need to do?
But the next thought was inevitable. How many times have I’ve been that knight who said Nii! in the eyes of a user, wanting some new functionality.
What I said: “No, you will have to wait because there is no product backlog item and the sprint has already started. Get it registered before the next release planning meeting and we can estimate how many story points it will require”
Interpreted as: “No, I won’t let that pass because I want you to bring me a shrubbery before I’ll get it fixed.”
We have all gates and artifacts for a reason but in too many cases we don’t explain this enough or perhaps really know ourselves so instead we just babble out one (or many) of those process artifact names in the face of the one making that requirement.
And the second part of sketch is also so telling. When the stakeholder finally got all that documentation ready in the specified form or formed the requirements as a user story, the process has changed and now they have adapt to that. Imagine all users getting used to scrum vocabulary now having to grasp kanban…
We might all this for a good reason but it is important that it doesn’t feel like everyone need to cut down a tree with a herring too.
Usability testing must cover situation and system
A lesson learned from Predictably Irrational is to test usability in the situation the customer will be in when he will be making that decision/using that system. If you ask a sober young student during a day time study if he would drive under the influence, you might get another answer if you ask that question to the same man, drunk as a skunk, leaving a party.
It is so easy to bring in users in a testing environment, turning off their phones, and making them test the system. They will not behave the same way when they are trying to get all the figures ready for the important meeting, already late to pick up the kids from daycare and with the phone ringing and the high pitched voiced colleague babbling at the next table.
You can just imagine what the product developer for these sandals thought about the ease with which you can put on those shoes. Dead simple.
Safesideoholism
Most of us don’t want anything bad to happen to our kids. In order to keep them safe, we make choices which secure their safety and we set up rules and regulations to prevent those unsecure situations. If it can save the life of a child, we should of course do it. To be on the safe side. Or should we?
David Eberhard, a Swedish psychiatrist, describes in his book “I trygghetsnarkomanernas land” (In the safesideoholics land) he describes a time when everything should be on the safe side but also a time when teens get a psychosis when they are dumped for the first time, where the psychological health is on an all time low and when more and more people get burned out.
Eberhard does not buy the official reasons for this: that the pressure is so high today. He believes that the cocoon like state we put our kids in are ruining their chances to learn how to cope with risks, failures, pressure and sorrow. So, when they are finally in a risky situation they don’t recognize it (since they are used to everything being safe) and when they are faced with a sad situation, they panic. Our “On the safe side” mentally are killing their possibility to live life to its fullest.
The social pressure is also a factor: we talk negatively about the parent who lets her kids cross the street on themselves and these stories are great headline news. It’s better to follow the crowd. To be on the safe side.
I recognize the situation all too well. I have friends who’ve brought their kids to the E.R. for symptoms I would say points to a common cold. Not just once, but many times, and still they continue this habit even if they keep coming back with the same conclusions from the doctors. To us other parents they say: well, it was perhaps not anything dangerous this time but you want to be sure when it’s your kids, don’t you? I don’t know how many times I have had to bite my tongue: No, I don’t think it’s OK to waste precious E.R medics time. And no, I don’t think it’s OK to spoil the weekend for that kid, having to spend yet another day in the waiting room. And I don’t think it’s OK that really sick people get to wait even longer because of this.
What is really sad about Eberhard’s conclusions are though that he thinks that the main concern of these parents are not the kid, but themselves. No parents can forgive themselves if they did something (or didn’t do something) which caused harm to their kids. In other words: we are afraid of the feeling which we would cause ourselves if something happens.
Sometimes while reading this book, I started to think about all these projects out there. All these efforts to introduce agile values in software development. Yes, it’s probably sick to think about that all the time, but I couldn’t help but see the consequences in my work situation.
What happens when the failure afraid, security manic safesideoholic parent come to work and get to plan that project? What does he feel about an agile approach, when he don’t get an estimate in hours but in story points? When he cannot see which date which functionality is delivered a year in advance?
No wonder that many thinks that the traditional waterfall approach is nice and comfortable. It feels great to wait with starting the development to after we have that thick pre study. We have really done everything to get to the bottom with this problem. If they project goes south, no one can say that we didn’t analyze the problem before we got started.
And what are the consequences for the project and the project group? Well, if you’re into agile values, you probably have an idea about this not giving ground for the most innovative development.
Absolut Agile 
Recent Comments