I still read too many switches

Yes, I still read too much code with switches inside. I hate it. There’s still also a “nice” page on the official website of Sun on how to write really nasty code, it’s here. I don’t wanna infect this blog, so I’m not pasting that example of code here. I paste only a quote, it says:

Deciding whether to use if-then-else statements or a switch statement is sometimes a judgment call.

Yes, indeed. And the judgment call is: “should I write a long list of if then else or maybe think on some kind of polymorphism?” The switch is not an option. Switch smells of poor design, smells of “you dude, writing that code, you don’t know what object oriented is!”. It’s not well testable, it’s ugly.

The web is plenty of examples on how to refactor from a switch to a decent design, just searching right now, I’ve found a good one here.

There’s another one here, with strategies for getting rid of it.

So why are you writing still switches? Let me know, we can talk about this and maybe I can help you to quit.

Switch off the switches. That’s the tip.

Hey, this does not allow you to write a long chain of if then else blocks! Think on polymorphism every time you write an if, ask to your pair what he thinks, maybe you can move that responsibility somewhere else, one if is still fine but when you start to have an else… Mhmmm….

I really hope that someone is reading and I’ll read less switch stuff…

Some stuff you might try in your retrospectives

The title of the previous post “Some stuff you might try in your team” perhaps was catchy or maybe finally I wrote something interesting since I’ve got a big jump of visits, so I go on with a similar title, talking about retrospectives and let’s see how it goes

There are two things that I’m doing right now when I run a retrospective:

The short version of the prime directive, aka the Toni Directive and a bit of time boxing.

The original version of the prime directive says:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

It’s too long! It takes ages to read it and in my opinion is less effective than a simple, concise, direct:

1. No blame thanks
2. We are all sure that every one did his best

That’s it, I was bored when listening to the orginal, long version, I didn’t see any blame running retros with this version neither people judging. You can try and let me know.

What about time boxing?

Well it cames after a (too) long retrospective run by me, The Kua came and told me, why not time boxing the next one?

So right now we are trying to fit our weekly/2 weeks retrospectives in half an hour, of course for an end of project retro this might be not enough.

But as a general recommendation, keep an eye on the clock, try to stop people when the conversation goes too long without adding any value, try to find an action quickly and effectively.

Some stuff you might try in your team

In the team we are used to be Agile, and especially what I call being Agile doing Agile stuff. Which means being not dogmatic: stop doing a practice when it does not give us enough value and starting it again when we feel that we are missing it. Not only: we also try always to introduce something new.

Since the beginning of the project we had 2 swim lanes on the wall, one for actions  to do and one for actions done, we just added a third column, the keep doing actions, it’s like having a star fish always there.

The waste bin. Yeah, we are interested in what’s going on with lean, so now there’s a box on the wall, if someone in the team feels that is wasting (s)he can put a card there, we’ll discuss it during the retrospective.

As a reminder, the seven lean waste types:

1. Overproduction = Extra Features
2. Inventory = Requirements
3. Extra Processing Steps = Extra Steps
4. Motion = Finding Information
5. Defects = Defects Not Caught by Tests
6. Waiting = Waiting, Including Customers
7. Transportation = Handoffs

A lovely software for GTD

I always used a text file for my todo list, I never found something better than moving lines coping and pasting, nothing so easy and immediate.

I’ve tried for a while tadalist  which is cool since it goes on the web, you can share it, it has an RSS interface, but the usability wasn’t so great.

Yesterday searching for a software that I’ve seen on the Gaz Mac I’ve found another one,  iGTD

The guy says:

You are a busy person, aren’t you? And there’s an easy way to track all things that have to be done… and to get those things done! iGTD takes some concepts from Getting Things Done methodology and makes them easy to understand and use in your every day life. But it’s definitely not limited to the GTD concept – you can really use it the way you want.

It’s simply one of the best Mac Os apps I’ve ever seen, I try to list here what I love of it so far:

• Export to iCal: awesome
• Easy to use, simple, logical, keyboard shortcuts for everything
• Integration with Quick Silver: cool
• Widget, integration with almost all the apps
• It’s free

Are you still reading this? Let’s try it out!