smart lazyness

I am lazy. I admit it. I wouldn’t know how to cope with the information overload otherwise. You know what: Actually being lazy keeps me quite busy. You need to be lazy and apply it in a smart way.

Being lazy is not about doing nothing. It is about not remembering, because things are obvious. It tries to work on the “don’t make me think” paradigm. Whenever you have a choice, you stop and have to make a decision. This takes time and effort. We need to remove the little, interfering choices.

Have you ever looked at a website or web tool and think it was slick, obvious or easy to understand? This was most likely because someone worked very hard in making the functionality obvious. Making it easier to understand took some effort, but it helped you to use it without thinking about it!

While I was working on a project where a bunch of servers had to be delivered, each with it’s own function, it became apparent that being lazy saved the day. We delivered a test- and a production environment and when we got all servers their names and IP-numbers were close. We had servers like srv21555, srv21556 and srv21557 etc. Each machine was used for different purposes; some for WebSphere, some for TAM, some as a web server. It became harder and harder to distinguish because al we had was ‘a number’. And I am lousy in remembering numbers. Especially if they look alike.

So when we had to integrate the infrastructure, we decide to do it as much as possible with logical names. This meant also that we had and We had and It was obvious that when the name had test in it, it was the test-environment. If it had nothing, it was production (you want clients to connect to and not If it had intra in it, it was only accessible from the intranet.

This might seem obvious now, but almost nobody follow these simple standards consitently.

Getting a new person in, gave them a very small learning curve. Because it was obvious. Even Project Managers understood it :-). And the client did too.

We did not just do this for URLs, but throughout the infrastructure. This means we could forget most details, unless we were worried about the details. The rest of the time we spent on functionality, because the information was self-explanatory.

I heard a story about a trading application. They were testing some new functionality where people could transfer large sums of money. Like typing ‘$1b’ meant one billiard dollars. That kind of numbers. At some point, someone had to attach the front-end to the banks test-backend. They typed in the IP-number and made a small mistake. So when the test was performed someone typed in $1b and did a transfer. Being the tester, he also played the role of bank employee and approved the transfer, so it was ready for processing. However, by making a small mistake in the IP-address, the order went into the production backend of the bank. Of course all kinds of bells and whistles went off and the order got cancelled, but merely the interest-loss, let alone the investigation, cost a lot of money. Of course a firewall should have prevented this. Of course the IP should have been checked more than once. But mistakes happen. If the backend had been entered as the mistake would probably have not been made. While a mistake between and is more likely to happen, because you have to THINK about this. Perhaps you can learn that 78 the TEST-LAN, but why should you?

Preventing people and yourself from thinking and remembering is the key to being lazy. It makes life easier because you don’t have to think about the simple things. So you can focus on the problem at hand without being distracted all the time.

So the trick is to make things obvious whenever you can. In naming conventions, by adding version numbers to document names and by keeping to standards. Good candidates for laziness are those items you keep looking up or making lists of.

This takes a little training and actually quite some effort sometimes. But the effort is small compared to the gains you get.

Being lazy surely keeps me busy!

Leave a Reply