I am sure a lot of you are frustrated at your colleagues, not being here at this conference. Not being passionate about code the way you are. And I am sure you are trying to teach them. You are talking about design patterns, test driven development, refactor your code making it readable.

I am saying that they are not ready for that. They are not aware that there is a need that could be filled by learning these things. And until we make them aware of that need, there is no meaning in trying to teach them.

— From Good to Great Developer - Chris Hedgate

The bouncer pattern

Last week, J.B Rainsberger talked at Agile Philly about integration tests are a scam and explained to the audience the bouncer pattern.

I am going to paraphrase the concept.

Imagine you own a night club. It’s pretty big with 7 bars around a dance floor. Bartenders must ask for your ID before you get a drink. Some bartenders are pretty good at remembering faces, others not that much. It’s Saturday night and the place is packed. As the night goes on you start to get pissed off at the fact that you need to show your ID for almost every drink. Getting a drink gets slow and sloppy. People stop showing up at your night club.

So you push that responsibility out of the bartenders and hire a bouncer that can check for IDs at the entrance of the club. Now, the bartenders understand that if you are the club, you pass the requirement for drinking. Not only this speed things up, it also minimize the possibility of something going wrong (null pointer if I don’t have my ID anyone?).

So that’s the bouncer pattern. Instead of doing defensive programming all over the code base, check for basic correctness at the edge of the class/module/service. The code becomes easier to read and simpler to maintain.

If we use constructor dependency injection to construct objects/module/service, we can help out our bouncer keep the junk out of our code.

Starting a code study group

We are starting a new code study group at work. Here is the email that I sent to the group to kick it off:

Starting a code study group

What is it?
A code study group is a bunch of people that choose an open source project or library and read it like a book.

As they go through it, they take notes; identify patterns, critique techniques and post a report.

They look at code with a critical eye. Various style of code will amaze them, amuse them and challenge them. They learn new paradigms that completely changes the way they approach problems.

They study the work of masters to improve their skills.

They meet twice a month and nominate 2 to 200 lines of code to study.

Why study code?

• To sharpen the saw
• To use existing code to reflect on our own capabilities
• To understand new code quickly
• To identify code patterns quickly

You can even learn from bad code.

This is not something new. Musician, painters, poets get together to study the work of masters. They learn their work and quiz each other.

Since we are heavy on the java side, I created an online survey with 4 open source libraries that could be interesting to study:

• Mockito
• FitNesse
• Spring
• Jakarta Commons

I can’t wait to see what are the results of the survey. I am going to keep it open until Monday.