Asylum

Is your boss insane?

Does he take bad decision all day long, telling you to work on useless things while you know what needs to be done?

Are you colleagues insane?

Do you think their design could be better? Their code more robust? That their architecture could be more testable? That they should use this and that framework? That they don't know how to code but you do?

Are you insane?

Do you do whatever is in your power to help your boss and colleagues to understand what you think is important? Do you know the reason behind your boss' decisions? Do you understand the business, the competitors, how your product compares to others? Do you suggest improvements and changes of priority when you see fit or do you stay silent? Do you coach your colleagues when you know something they don't? Do you learn every thing you can from your colleagues, either personally or professionally?

If you start to think others are crazy, think again. Bring yourself to the center and check what you can do to understand them. Sometimes it does not take much except a small thing called 'communication'. Talk to people, understand them, know why the act the way they do. Then maybe what you saw as 'insanity' will go away... most of the time.

What is rubberducking anyway?

Some people have asked me where the title of my blog (rubberducking) comes from.

Well it's quite simple - rubber-ducking is the art of talking to a rubber duck to find solutions to your problems.

Sounds crazy? Well probably a little bit...

But you probably had this kind of conversation a few times:
You: Hey Joe, I've got this problem with my code... I'm wondering how to... Oh yeah just saw the problem, thanks!
Joe: ...

Now I'm sure Joe is a nice person, but what if he's not available? A rubber duck can sometimes work nicely:
You: Hey ducky, I'm having trouble with this algorithm... Everything is by the book, even this tricky part here... Oh wait, got it! Thanks!
Ducky: <quack>

Anyway I wanted a medium to explore ideas and get feedback... Rubber ducks are nice, but sometimes I need the duck to talk back, hence the blog

If talking to a single duck is not enough, you can try to talk to many pixies... You never know, it might help.

Java Brainteasers

I had lunch with a few colleagues yesterday and we started talking about obscure stuff. Among other things we talked about:

• the initial default size of a hashmap, which is a power of 2 (16) in HashMap but a prime number (11) in Hashtable in java 1.6 (possible explanation, see the 'Tip' section)
  
• the strictfp keyword, which can be used to ensure that floating point numbers behave the same on all hardware.
• the volatile keyword, which seems to have a slightly different behavior since 1.5. I did not find anything from Sun about this, but I found some references indicating that something might actually have changed... Basically it seems that writing to a volatile variable synchronizes all cached copies of variables with the main memory, not just the volatile variable itself. I must admit this one was totally new to me.
  

Anyway that reminded me about Java Puzzlers, a book about obscure features of Java in the form of puzzles. I decided to go through the book again to see if I would gain anything. Although many puzzles show how things can go hairy while using really bad code, a few bits of knowledge can always be useful. Here is a few of the things I learned (or re-learned) while skimming through the book:

Weird behavior of Math.abs
The absolute value is not always positive!
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE

Unicode considered evil (at least problematic in comments)
Unicode characters in comments can cause problems. Consider the following comment:
/*
Test files are located in \utest\samples
*/
The file will not compile because the java compiler tries to convert \utest to a Unicode character (I saw this in a real project once)

Escape regex
I learned that Pattern.quote() can be used to automatically escape a literal string as a regular expression.
System.out.println(Pattern.quote(".")) will print \Q.\E

This method was added in Java 5.

Recursive array printing
I also learned about the Array.deepToString() method, which can output the content of multi-dimensional arrays. This method was also added in 1.5.
int[][] array = new int[][] {{1, 2, 3}, {4, 5}};

System.out.println(array); => [[I@1ad086a
System.out.println(Arrays.deepToString(array)); => [[1, 2, 3], [4, 5]]

Ternary operator madness
And finally the behavior of the ternary operator (? :) was changed in 1.5. Consider the following statement:
boolean b = true; // or false, doesn't matter
List list = b ? new ArrayList() : new Vector();

In 1.5, the code compiles fine.
In 1.4, I get an error 'Incompatible conditional operand types ArrayList and Vector'.
Before 1.5, both values returned by the ternary operator must have a shared ancestor other than Object. In 1.5 the requirement was relaxed - any common ancestor is fine, and since all classes inherit from Object you can return two completely unrelated classes.

Now why would you want to do something like this?
Object o = b ? new ArrayList() : new JButton();

Don't ask me, I'm just the messenger...

Addiction

Hi, my name is Mathieu and I am a test addict

I wasn't always like this. It all started a few years ago. I was working on a graphic application and there was a fluke. I only saw it once. The colors kept flickering: red-green-red-green-red-green. I was mesmerized, I could not look away.

I was staring at the screen, trying to figure out what went wrong when I felt something... snap... inside my head. I didn't know what it was and went home, but it kept haunting me. I could not sleep that night, so I went to see the Guru, a little guy standing high on his ebony chair, on the last floor of the highest building in town. I talked about the colors, and like I felt something was missing from my life.

"Unit test you shall" was his answer.

I did some research and found what he was talking about. Testing frameworks, stubs, mocks. A new world opened to me. I read about all this weird stuff all night.

The morning after I started to test, I was wondering what it would feel like.

Red - hm mm, OK
Green - nice, something works!
Refactor - change this, and this... and the code still works!

I felt peace inside, a feeling that nothing could go wrong with my life, ever again...
Red-Green-Refactor
I was hooked.
Red-Green-Refactor, Red-Green-Refactor

Over and over, faster and faster

The light kept flickering. I couldn't get enough.
I felt... strange. I felt... alive.
Corporate drones kept coming close, attracted to the light like little bugs, but they had to shield their eyes - the light was too strong. A few people went blind and were set to maintain the mainframe, deep under the Earth's crust.

But one particular mindless Cobol Zombies was attracted by the light . I handed him the keyboard and as he started to code, I could see flesh forming all over his rotten body. He was alive!

The addiction could spread. I was amazed. I had just saved a life!

But I cannot do all the work alone. I need your help. Help spread the word, help save the world!

Disclaimer: This is a mostly true story. Some events and places have been slightly modified for my own enjoyment.
No Cobol Zombies were injured during the writing of this story.

How to be Agile in a Day

I read a few articles lately that claim Agile is basically a magic bullet that will allow you to have greater productivity in a few weeks. Well a few weeks is too long... Here is my magic recipe to be Agile in a day. It just requires a little preparation:

Preparation:

• Hire a good mix of junior and senior programmers.
• Hire passionate, pragmatic programmers that care about their craft.
• Make sure your team is co-located.
• Have a definition for a work item that is 'done'. Were coding standards followed? Is the feature tested? Is it documented? Is it installed in a demo machine?
  
• Plan the release of the product with the main features and an approximation of how big the whole thing is going to be.
• Plan the work for two or three weeks at a time.
• Make the team take responsibility for the work to be done in the next iteration.
• Test everything you do thoroughly (unit tests, end to end tests, and anything you feel is required in between).
• Know the difference between a stub, a mock and a fake for tests. Know when to use each one.
• Have a continuous integration build.
• Name your classes with words the customer will understand as much as possible. Programmers and customers understand each other better if they speak the same language (DDD).
• Have a good knowledge of object oriented design.
  
• Fix your bugs as soon as you find them.
  
• Refactor early, refactor often.
• Pair program when you can.
• Organize code reviews.
  
• Have a customer on site (or at least readily available) so you can question him about the requested features.
• Demo your product at the end of each iteration to get customer feedback.
  
• Ship! Release your software to some users early and often to get even more feedback.
• Integrate the feedback into your next development cycle. If the customer changes his mind because what he saw is not what he expected, do not be afraid to recode entire features (but make sure the customer knows he will not get new features in the meantime).
• Hold a retrospective at the end of each iteration. Identify the biggest problem you currently have and take steps to solve it.
  
• Follow up the retrospective with concrete actions to obliterate your problems. Retrospective are useless if you talk about the problems but do not solve anything.
• Always strive for higher productivity. "We always did it like that" is seldom a good reason not to improve.
• Allow failures. Expect the team to fail from time to time. Never failing might mean the team is aiming too low.
  
• Do all of the above for a few sprints. The longer the better. If you can do all of the above for a year and still continue to ship valuable software for a customer while maintaining clean code, there is a good chance you can continue to do it for a long time.

That's it for the preparation. Now, here's how to be Agile in a day:

• Read a book about Agile methodologies. Realize you're already pretty good but you still have a lot of room to improve. Claim that you are now Agile.

There's no shortcuts, no magic bullet. Software development is hard. Agile software development even more so. Do not expect every programmer you meet to thrive in a dynamic environment where everyone must take responsibility for their work. Agility is not for everyone. I believe it is the most enjoyable way to build software, but I'm aware that a lot of work lies ahead.

So can you be Agile in a few weeks or less? Well if you are already doing almost everything in the list you probably can. If you do not understand why the list is important, you're far away... Claiming you can be Agile in a few weeks might be a nice commercial gimmick but that's about it...

Book Review: Six Thinking Hats

Thinking is a skill. Like any other skill it can be improved.

Six Thinking Hats aims at making your thinking process more effective by removing something that I rather enjoy but which makes any decision longer to come: arguments.

People do not use arguments because it is the preferred way. They simply do not know any other way.
- Edward de Bono, Six Thinking Hats

I admit, I'm guilty... I've been in a few useless debates before. I'll try to change now that I know another way...

Instead of arguing back and forth over an idea, it might be worth it for everyone in the meeting to gather information over a single axis at a time.

So when you explore an idea, you might want to wear a different hat to be sure to explore all sides. This can be done in group meetings or if you are alone thinking about a problem. Colors are used because they offer a neutral language which is easy to remember:

• Blue: overall view, control of the thinking process
• White: cold facts and information
• Yellow: hopes, positive outcomes, advantages
• Black: caution, warning, disadvantages
• Red: emotions, feelings, hunches
• Green: creativity, new ideas

The premise is that it is difficult to view all sides at once. In a meetings it gets worse because someone might be focused on finding what is good about an idea while someone else is focused on the drawbacks. Disagreement follows and it becomes a willpower contest.

A brief example

You do not have to use every hat for each decision. You might for example start with a blue hat to define the problem and the desired outcome. The you might gather as much information as you can about the problem (white hat). Then talk about the advantages of a particular solution (yellow hat). If the advantages are not what you expect, then just drop the idea and explore something else. No need to argue over a bad idea...

On the other hand if the idea looks good, then request everyone to put on their black hat and explore the hurdles that might encountered during the implementation.

Power of the team

So I invite you to think about the principles behind the book and try to find alternatives to arguments to solve problems. I know it can be fun, but arguments just are not that effective...

By focusing on each side separately, everyone is sure to have a global view and the decision is probably going to be easier to reach. Everyone is focused in a single direction at a time. Everyone is working together instead of against each others. If you're a software development team, it might be time to act like one...

Clearer Intents using Selenium

If you've ever had to write Selenium tests, you know it's a pain. Tests are very verbose, so you probably create your own methods as a library on top of Selenium. And when the next project comes, you start again from scratch...

Two colleagues started a project called Fluent Selenium to ease the pain. They wrote their own DSL (Domain Specific Language) over Selenium to make the tests more readable. The DSL is in C# and uses Selenium RC to control the web site. The project is still in its infancy - only basic features are implemented. However I think it looks promising.

Here is an excerpt from one of their sample code. The API is changing fast so it might not be accurate, but it should be enough to give you an idea:

shopper.Goto("Shopping/ShopOnline.aspx");
shopper.WaitFor(ShoppingOnlinePageLoadWait);
shopper.For(UnitPriceField).ShouldSee("5,00$");
shopper.For(NumberOfItemsField).Enters("2");
shopper.For(ProceedToCheckoutButton).Clicks();


shopper is an instance of the User class, which is the actor that drives the web site. You probably guessed that the test drives an online shopping and checkouts two items.

What I really like about Fluent Selenium is that it makes it clear what is the intent of the test. The framework suggests to put xpaths out of the way (using Locators like UnitPriceField above) and to really concentrate on what you want to test from a user's perspective. Reading the test reads almost like you would read a sentence!

So next time you need to write Selenium tests, remember to make it Fluent!