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.

Are you consistently bad?

We need to be consistent! We need to be reliable!

Aren’t that nice?

But then consider Sanjiv Augustine’s wonderful statement from APLN:

(Source Jesse Fewell)

A team can be consistent and reliable and still deliver garbage. If you always deliver garbage, you’re pretty predictable, aren’t you? You can truly rely on them delivering garbage. Business as usual.

I have a childhood friend who works with a supplier who he really can count on. He can count on the system failing after each upgrade. He can rely on the support functionality not being able to fix his problems after the delivery and he can be sure to have a lot of angry users on his back. After each upgrade.

What bugs my friend the most is not the individual problems. It’s that no one seems to care that his company loses money every time they upgrade the system. He’s annoyed by that nothing gets better. He feels like the supplier sees the problems as normal. Well, they are since they are consistent, he laughs with panic in his voice when we talk after an upgrade.

I’ve told my friend that he should abandon the supplier, for his company’s sake but mostly for his own health’s sake. And this my recommendation: if you work with a supplier who sees garbage deliveries as the normal state, get out. And if the supplier thinks there are different problems each time and blames this and that, well that is no excuse. If the process consistently produces garbage, it does not matter if the garbage is of type A one day and B the other. It is obvious that the process allows the garbage.

If you instead work at that supplier, you should do something about it. The competition is hard out there and blaming this and that does not help. Look back at your latest deliveries and figure out how many critical errors your company has introduced to your users lately. And no, don’t blame the integrators or the installation guys or even the users. Look at the end product.

Are you proud or are you lining up arguments why you were not to blamed for these incidents?

Jesse Fewell have on his blog presented how Sanjiv Augustine has described his idea of an Agile PMO and how such a solution can fuel continuous improvement.

This is just one take on the problem and it’s handling. Because this is not a problem what can be solved, it’s something you need to work on all the time and on all levels. So what if you have 90% code coverage, work test driven, use scrum and have continuous integration? These are great tools among other tools but if you still work in the garbage spreading business what’s the use of you mixing the garbage with some fine wines?

The non responsive UI – a nightmare for users and testers

If there is something I cannot tolerate as a computer, it’s a non responsive UI.

I’m currently updating my IPod music list and I’m so disappointed with Apple that they still haven’t fixed the responsiveness of the UI. If I click a song in the list, it takes seconds before ITunes starts playing the new song.

My least favorite program is in a class of itself, as always. When I select an e-mail in the Inbox it can take many long seconds before the right message is displayed in the preview. This has sometimes resulted in missed information and always a lot of frustration.

As a tester, the non responsive UI is also a big problem. I click something. Nothing happens. So, I click again. Something happens. Is that because I clicked once or twice?

When you’re buying new software for your staff, don’t be satisfied with a PowerPoint presentation, test the UI yourself. And that does not mean the salesperson showing what he wants to show with the data he wants to display. If you have a product list with 100.000 products, make sure you test the search functionality with that data. And make sure that you are handling the computer. Salespeople know their software, know where the loopholes are. But he won’t be there when the guys can’t complete their tasks because the software is malfunctioning.

We can all blame the software industry for sloppy work in this area but as long as the people buying the stuff does not demand this as much as they demand functions which they rarely use, why should things improve?

Business value of the boring stuff

This weekend, our vacuum cleaner broke down. We both looked devastated on the thing. Not so much for the money (which of course is boring to spend) but for the knowledge that we now would have to spend a lot of time buying a new one.

First, I tried to make an educated, good decision and scanned different communities and sites for the most recommended and best value. But I soon lost interest and found myself surfing on more interesting stuff. That is most things in the universe. I tried looking at one of those cleaning robots but realized that with two floors, one dog and a boy into Lego, this would probably cause more time spent than our gain.

So, I just gave up and went to the store. I went to one of those malls where are multiple stores to choose from, but realized when I got there that it wasn’t worth my time shopping around. So, I picked a store and went inside.

There are an silly amount of options out there, folks. One brand can have five or six different models in your average store. People went around there, testing the things. I just stared. How could I possibly choose?

And then I nearly fell into the trap that most product owners do when they prioritize. They think that something is boring so they go for the cheapest option out there. I almost picked the cheapest one when I realized, Hey, I hate cleaning. Why should I have the worst possible tool when I do the stuff I hate the most? Won’t that make me hate it even more?

The same goes for product owners. They probably don’t think upgrades, logging, error handling and installation features are the stuff of their dreams, so they try to get this as cheap as possible. And then they complain when bugs go unnoticed for months. When regression testing is a hassle, when upgrades takes forever and roll back is not possible.

I didn’t pick the most expensive vacuum cleaners. I took one in the upper level without a bag. I don’t like shopping those bags either. Since I don’t even know the model I’m using, I’m stuck trying to find that just to know that the specific bags are not available then. And they cost a lot of money. With a Golden Retriever you tend to spend a lot of bags.

Well at home, I found that the new thingy made it easier to clean at home. And having a remote in the handle is really a good thing. The dog hair is handled much better and one of the rugs are clean for the first time in five years. Well, I thought it was kind of clean before but now I know.

And one thing more, skipping the bag means that I can see all the stuff I vacuum. No more hiding of dirt. And that is also important in software development. Never hide your garbage for your in house staff. Better that they know about it and help with the cleaning.

Testing on other projects

One of my requirements for starting to work for TUI Nordic was that I was to be able to participate as a tester. For me as a project manager, testing enables me to get to learn the system and the users in a very easy and for filling way, but it also makes it possible to become a real team member. In TUI Nordic, the project manager fills the product owner role in scrum projects and since I’m a firm believer in product owners being a part of the scrum team, this is a easy way to do that. Stating that one is a team member is one thing, but if you don’t do any actual work and function as a chicken, you’re not a real team member, indifferent of how much coffee you bring the guys.

The passed week, I’ve tested a new experience with testing. We’re completing to projects at the same time and since we work with shared code, our projects are really integrated. So, I asked if I couldn’t participate as a tester of the other project. Really interesting. I can get a little bit of insight in the project manager skills of another project manager from an inside perspective, but I also learn more about being a tester. In all other projects I’ve been a tester in; I’ve known all the objectives and known the project in all details. Known what has been decided and which decisions are lacking.

The difference is huge. I’ve really learnt how important for testers to learn about all those decisions. But how? An extensive list? I don’t know. Do you?

Measuring productivity

You get what you measure

So true, so true. These famous words from Mary Poppendieck point at an important objective of anyone interested in their work.

But there is a risk to these words. Because you can be lead to believe that you can measure everything you want.

I want my son to love me. So, following Mary’s words I should probably measure his love. This should ensure me success in getting his love.

Sounds goofy? Well, to most sane people this sounds crazy. I cannot take out a chart and plot my son’s love for me.

But how about productivity? In the agile community I’ve read a couple of discussions about if you can use velocity to measure productivity. I don’t like this idea much. I use velocity for predictions and my priority. Story point estimates are in my world a relative value of size, and if I start measuring how many dots they complete every month, they are not sure to start making their estimates bigger. I still don’t measure productivity but I’ve also lost my chance of predicting my upcoming deliveries.

So, how do I measure productivity of the developers on my team? Well, I measure it by how happy my users and stakeholders Do they feel that the investment was worth it. But, but, you might say: that is too vague! And I say that just this is what matters. If the customer is happy about the investment. Can they make the money they hade anticipated or save the cost they were counting on.

And frankly, I have a hard time finding a good measurement of productivity. I can just look back at my role; project manager. What is a productive project manager? Is it the one who makes the most Gantt chart bars? Or holds the longest steering groups? How does a project manager know if he’s been productive a day? For me it’s a feeling. Some days I can have had this ten minutes meeting which clarified a lot of stuff which will save us a lot of coding time or make us reach our goals. But a numeric calculation, I don’t know.

It was perhaps easier when I was a test leader. And yet not. A productive tester does not find a lot of bugs, he prevents them from occurring in the first place. And how do you measure that? Yes, you can measure the decline in bugs, but how do you know if a specific tester was the reason.

So, to summarize; I wouldn’t feel productive as a project manager if I was asked to measure the productivity of team members.

Do you use the Spoilt Brat Pattern?

One of the reason for why I started working for TUI Nordic was the view of the customer. Not that the customer’s always right but the customer must feel like he’s right.

All too often do people think that their customer is wrong or should blame himself for not being satisfied. He made the wrong choice, picked the budget alternative and still he has the nerve to complain about it. And when he do complain how many strive at making the customer go away/stop complaining instead of making him content. Sometimes it does not cost you anything. More often than not simple words and explanations can make the customer feel that his issues has been noticed and validated. Yes, you feel that your hotel is too far from the beach and that is why you paid less than the others. Do you want me to check if we can upgrade your reservation? That’s an example of what I mean, instead of making the customer feel stupid you can recognize his problem and find solutions.

And the same goes for development teams. You have a feature developed and when you deliver you find that the customer is not satisfied. In some cases they tell you that you got it all wrong, load and clear. In other cases they don’t use the functions. In both cases there can be frustration that you didn’t understand them but I guess there is also a sense of guilt. Perhaps they helped during specification and testing but it wasn’t until production they realized the problem. So what do you do?

Many turn to the Spoilt Brat Pattern.

Before I got Peter, I used to hate spoilt children. I still hate it, but now I have a better understanding. So, what is a spoilt brat? That’s the kid who gets what he screams about and he’s still not happy. He complains, screams that you got him the wrong one or that he just want something new now.

If you as an adult apply the Spoilt Brat Pattern you turn to the child and say “Hey, you asked for that one. You got it now, so don’t be so spoiled and be happy about what you have. Think about the poor kids in X, they would be thrilled about that one. It’s no fun giving you stuff, because you’re never pleased.”

Spot on, isn’t it. Hm. In software development this would sound like “Hey, we built it like the specification and you did approve to this during testing. Now you have what you wanted. Think about the guys in finance, they have been waiting for their features for a month now. Why should we develop things for you, you’re never pleased with anything.”

Well, yesterday an incident got me thinking. My son Peter really wanted a scooter after testing one at his cousin and a month ago, we went out and got one. I went to a toy store and there it was, blue and Peter approved of it. It wasn’t quite like the one his cousin had but there were no others like that one in the store, so we got this blue one. It looked something like this:

At home, Peter started using the scooter but soon, I realized he wasn’t pleased with it. And he stopped using it. I couldn’t understand why. So, yesterday we started talking about in a store. He saw another scooter and he gloated. So, I asked why he didn’t use his own scooter. This one was just the same, or?

                

But, he finally confessed, you cannot slide with his. Stupid mom as I am I stated that they were the same. No, said Peter. Mine has three wheels, so I can’t slide it when I brake. If I were a better mom I would probably hinder my son from sliding at age four, but instead I realized our mistake. Peter hadn’t understood that the third wheel would hinder him from making that daring stuff he wanted to do and I hadn’t even bothered to learn the difference between the two types of scooters.

If I had played the Spoilt Brat Pattern on Peter, I would have just said that he should be happy about his scooter. But instead I got him the right one instead and gave the other one to another child, whose parents wouldn’t afford one and who won’t do any sliding. Both Peter and I made a mistake by picking out the three-wheeled scooter in the first place and forcing him to use it would be of no good to anyone of us. But, and this is a big but; hadn’t he acknowledged that he himself made the original choice, this story would have had another ending.

So, next time your users are not happy about the features you’ve built, think if you’ve built them the three-wheeled scooter they didn’t really have any use for and try to fix the problem.

When a single feature results in an exponential increase of scenarios

Have you ever met a person involved in software development who thinks that the correlation between number of features and complexity looks something like this`

I mean, who does not understand that adding new features does add to complexity.

Then there are the slightly more informed ones who thinks that when you add 1 new feature, you add 1 complexity unit of one. You can see this as test cases. So, these guys thinks that one new feature is about one more test which you have to run.

But have you ever been in this situation (X axis is number of features and Y axis is number of test cases or what ever complexity unit you prefer).

You have a new system to wish you slowly add new features, things aren’t that complicated and then someone comes up with a brilliant idea. It shouldn’t be that hard to implement. But the new feature starts an exponential increase of complexity and now you’ve created a monster. The initial development cost was perhaps small but that little thing made all the upcoming features so much harder to implement.

We also have this scenario. Everything runs smoothly and suddenly you start an exponential growth of complexity. But someone stops the line, recognize what is going on. And does something of the architecture.

If you’re really lucky, you can perhaps even stop and decrease the complexity. Refactoring should lead to something like this:

But you also have another solution and that is removing features. Features which are heavy in complexity and which business value does not match the increased complexity it creates. I’ve done this a couple of times and all of those occasions there has been a tremendous debate over the issue. But when the feature was actually removed, no one noticed it.

So, what do I say. Two things:

1. Evaluate the complexity effects of a new feature before implementing
2. If you have a run away train of complexity, do something about it right away. And that can be refactoring or removing the feature(s) which causes the complexity.

What meets the eye and the patience

I’m currently digging into a a safety management system for my company and one of the first things that struck me was that the system didn’t look that fun. It looked kind of old and my first reflex was that I didn’t like it. When I came into the project, all the sales presentations were already in the past but I was amazed that they’d actually considered this system.

How do I evaluate a system?

But one click later, I understood what it was all about. Pleasing to the eye is not always pleasing to the patience and the suppliers of this software know that this isn’t a software which someone just happen to want, sees in an add and book a sales session. Safety management systems for airlines isn’t a huge market. So, they let the customers be the sales people.

Performance and quality

Customers hate to wait and software is no different than anything else. They want a clear path just for themselves and if a system is slow, the annoyance is building up. The suppliers realized this and understood that for a system like this when you want to register stuff in a minute and be done, performance is key. A system which is slow will never be recommended to that pilot who works for another company. And since pilots by nature works anywhere, their computer can be anyone, so it have to work on old computers with slow network connections. What is good news is that making stuff fast works very well with making it easy to use: if you cut out all the unwanted features the product becomes much easier to use. And the bugs become fewer too. I’m not the easiest of testers and I’ve only found one or perhaps two bugs going through the systems. And non of the bugs were in the critical parts of the system. I actually think that this is the first system that I’ve tested and haven’t crashed in a day.

The features you don’t need

So, all features and goodies are weighted against loss of performance and ease of use. And performance and ease of use comes out on top. And you can feel it. And the users can feel it and this is why the system is sold by recommendation.

Don’t take quality for granted

It is very interesting how we people buy our software solutions. We kind of take performance, quality and usability for granted. When the sales person shows that nice drag and drop functionality we just assume that just because they’ve spent time on making that probably in the daily work useless functionality, they must have fixed the basics first. But we who work the business know that this is not always true.

For which systems are a pleasing user interface important?

I think a nice user interface which is pleasing to the eye is great, I’m something of a pixel maniac myself, but I realize that this is much more important for the systems which I use rarely. Which is strange: if I spend more time with a system one would guess that the looks means more. But for me at least, it’s quite the opposite. I simply get used to it. But I only get more and more annoyed by low performance, bugs and poor usability. (When it comes to Lotus Notes it’s BOTH ugly and poor in performance/usability so that’s kind of a special case).

Tips when you’re buying software systems

Meet a real user

So, what is the trick here? Well first is to ask for a customer list and then pick a customer who you want to contact. Many sales people have one or two safe customers but you want to pick the one they don’t want you to pick. And you don’t want to talk to the manager who was responsible for buying the crap; you want to talk to a real daily user.

Ask to test the system yourself – and bring your best weapon

The sales person knows his demo. Where to click and where not to click. If you instead ask to try yourself he cannot hide behind his script. Instead, use your own script for a real scenario. And here you should bring the angriest person on your crew. The one who complains about all systems. It’s better if she complains now than after you’ve bought yourself into a long contract.

Question buzz words

A previous boss I had always used the latest buzz words from Microsoft. All the time and to all customers. It was always so embarrassing when he mentioned SOA, SaaS and such for the painter around the corner. And when I asked him what he meant by these words and how they mattered to the poor painter, he had no clue of what he was talking about. And he’s not alone. If that sales person starts babbling about the cloud or what ever that doesn’t mean anything to you, ask him:

– And how does this help me earn or save more money?

Don’t let him get away by showing you one of those Microsoft images, go back to the question and ask him again how that will help you get more profitable. If he doesn’t care about that now, why would he care later?

Partly done – root of evil

Now, I’m not religious, but if I thought there would be a devil in software development his name would be Partley Don Woork. Do you know him? Shining on the surface? Nice smile? Cute outfit? But completely worthless when it comes to some serious work. And when there’s a problem, he just starts babbling and you have no idea of what he’s talking about. Don’t invite that S.O.B in your house!

A bad manager does not recognize Partley, or he think’s he’s a rather nice guy. Good to bring with him to customers for demonstrations and sales discussions. But all who have to work with the client after the sale is completed knows that the customers soon recognize Partley too. And they don’t like him either.

A good manager knows that Partley is not worth the applauds on a sales demonstration. He knows that even if he can get two Partley’s for the same price as one Completely Don Work, he knows there is a reason for Completely being so expensive in the beginning. He saves the cost by just cutting away all those expensive meetings where the behavior of all those Partley’s are being discussed.

The management for our software development department is now successfully working against all those Partley’s, and it shows. Not only does it show in the quality of the software, it shows in the actual value being produced. And perhaps most importantly; it shows in the pride of the people at the department. Having to work with Partley’s is bad for workman’s pride. And manager’s helping teams fight Partley boosts the productivity! Try it: there is a world with less Partley’s if we all work against him.