Saturday, January 21, 2012

The rules of the blame game

There should be no (bad) rivalry between different teams of the same company, just that healthy sense of competition that always pushes you to do better. Yet, sometimes you can witness disfunctional behaviours that flow into a blame game.

Just to be clear: blame games are useless, they waste people's time and eat your liver. If you still want to play, you should at least know the rules.

One of these rules is very simple: CYA. When you're talking nonsense you're not covering it very well. Example: check this excerpt from a conversation between a system engineer and a developer:

Sys: The server is not working. The problem is the application.
Dev: The servlet container can only use less than 1GB of RAM, the logs show an occupation of more than 1.5GB. Could it be the antivirus?
Sys: Out of question.
Dev: How can you be so sure?
Sys: If it was the antivirus then the server would never work.
Dev: Right... then it must not be the application, otherwise it would never work, even without an antivirus :-p

Sounds insane? Yeah, the same that I thought. In another domain it would sound something like this:

Doctor1: The patient has a bad cough.
Doctor2: It must be the lungs.
Doctor1: Out of question.
Doctor2: How can you be so sure?
Doctor1: If it was the lungs then the patient would always have a bad cough

WTF??? have you ever heard something like this? do you realize there's something weird? do one of the doctors sound like an idiot? would one of the doctors lose your trust?

Remember: you cannot blame anyone when you're not covering your you-know-what, otherwise you could be, well, you know.

And, if you'll accept a hint, don't blame anyone, even if you're in a full cast iron armor. We got there because we got there, now it's time to go on, so let's go on.

You'll have more time and less enemies, and you will always get a better result.

When you see a disfunctional conversation on the horizon, keep in mind that the best thing you can do is sail away and avoid it. If you're stuck in it, escape.

Automated vs manual testing

Yesterday I had an interesting tweetversation (it actually looks like this word exists) with @lunivore which started with this sentence:
My #1 suggestion for legacy code: If it works, and you change it, check that it still works. If there aren't any tests, run the app already.

I replied something about writing tests, and the discussion went on with several interesting remarks that made me think. As on many others, here's one thing on which I agree with Liz: automated tests do not imply that your app is working as it should. I have seen it too many times to be so naive. It could be (almost) true if our code coverage was perfect, but let's face it, it is not. Please note that I'm not talking about having tests on getters. We should have unit tests, integration tests, end-to-end tests, there-is-no-try-yoda-tests and everything you can think of as long as it ends with "tests" for almost everything. And more often than not we don't.

And even if we did, tests are not users. Well they are, but they are not the users we're most interested in: those who receive value from our app.

Automated tests are very important, but in the end they only are our safety net (even if they also guarantee our customers), but in the end it all comes up to real users.

Automated tests never sign checks, users do. Or at least the bosses of users do. Then, if we belong to that overrated category of people that still insist on eating every day (possibly more than once), we shoud strive to have happy users more than happy tests.

Automated tests are one of our means, not our ends. Let's not forget it.

PS don't forget to follow Liz on Twitter and on her blog.