Archive

Archive for 2009/05/13

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?

Advertisement
Categories: Business, testing, Usability

Why the scrum team should be the time trial team

Being a Swede is incredible fun this year. Of course watching 25-year-old Thomas Lövkvist at least one day in pink is awesome but one can’t help being amazed by Fredrik Kessiakoff, not a year into the discipline and already among the greatest on a day like today.

OK, I’m bike stricken and that is kind of silly of a person who normally knows nothing about sports. Sweden won a World cup bronze medal in ice hockey, and I didn’t even know that was happening even if ice hockey is one of the biggest sports in Sweden.

But road cycling is something completely different. Why? For not interested it looks so boring. Those guys sitting on their bikes all day long. And they are all on drugs. Well, if just address the last item first: as a pragmatic I understand that athletes like all humans cheat and you’re pretty stupid if you think this is more common in sports where you perform more tests. Being on constant pain killers doesn’t seem to bother soccer here in Sweden. So, let’s move along to why road biking is so interesting and why I find it so inspiring as part of software development.

I find that the needed traits are so similar: you have the hard work, the need for good tools, the long hours, the constant improvement. You have the cheaters and you have the loyal guys. And if you want to see a successful team. follow a team trial (if you missed stage 1 of the Giro you can still catch the Tour of France) and see who wins.

A team time trial is when the whole team get on their bikes on the same time and try to move as fast as they can to the finish. Everyone puts in their best effort to make the whole team win. Yes, there are always the weak links and they don’t perhaps do as much time in the front, but they do what they can. The team effort is measured by the fifth guy crossing the finish line. This mean that you can drop off a number of guys on the way but if you’re less then five it won’t matter. They still measure the fifth guy. Also, one can often see that the teams who push too hard so they lose people don’t win anyway.

Also, the focus on deploy is so interesting. Barloworld this year. The finish line nears. So, some of the guys sprint and others stop bothering. The problem was that only four were sprinting. So, they still had to wait for a couple of seconds for that fifth guy. I don’t think that dinner was a happy session for that team.

In rugby, one guy scores after the scrum and the sprint but in a cycling team trial the whole team is the winner. And that how it’s supposed to feel after a software development iteration.

Categories: Agile Tags: , , , ,