Make Amends with Git

I've always been a fan of small, concise commits. I strive to make my commits as small and concise as possible.

However I often fail... Very often I commit and... discover that I yet again forgot to fix a typo. Or remove a blank line. Nothing major. But it's pretty annoying to have every other commit log reading 'fixed typo' or 'formatted code'.

With Git, I don't have this problem anymore.

If I want to add some changes to the last commit, I simply type:

git add somefile

git commit --amend

Tada! I just modified my last commit to include new changes.

The other option I like to use from time to time is the rebase interactive mode. I use it to merge various commits into one. It has more powerful uses (like removing commits entirely) but I never used these (yet).

git rebase -i origin

Of course  you have to use these commits before pushing anything to a remote repository. 

With these these two commands, I can keep my commit log a little bit cleaner.

Why Katas Work

Musicians, singers and athletes have something in common - they do a lot of practice to become the best. They may have a show or a competition from time to time, but they practice every day.

Martial arts practitioners do katas over and over. At some point it becomes a form of art.

Can the same be done with code? Can you practice to code a certain piece of software over and over until it becomes art? Uncle Bob certainly thinks so. I started doing some katas a few months ago but a question was still nagging me : do they really help me become a better programmer? Does practice matter?

According to The Talent Code, the answer is probably yes.

The book explains how to harness your talent, how to become an expert in your field. And it seems that all world experts, no matter their field of expertise, have spent a lot of time (10 000 hours) practicing. Not just any kind of practice - you can't just play around and hope you'll learn something. There is a concept of 'deep practice'.

There are three parts to deep practicing:

• Chunk things up - slow things down, do a simple part of the whole
  
• Repeat - a lot
  
• Learn to feel what you are doing
  

I think that's what I've been unconsciously doing with katas. I wrote the same application every time. But every time I was improving, basing the next iteration on past experience. I was using more keyboard shortcuts, less code, better idioms to express myself. I was learning from my mistakes and becoming more efficient.

I believe that katas help me to  'deep practice'. It forces me to reflect on what I've done and learn from my mistakes. In the end I believe it helps me to improve.

That's good enough for me to keep doing it.

Switching to the Penguin

Finally it's done.

After months of talking about it, I finally dropped Windows and installed Ubuntu.

I decided to switch because I was tired of reinstalling Windows every year or so otherwise my machine was slowing to a crawl. Plus I mostly use open source software anyway. And I kept installing utilities to help me have a real prompt (I can't live without grep anymore...).

My first impression is that apt-get makes it a breeze to install a new machine from scratch. No need to download all the apps separately like I did on Windows, pretty much everything is one apt-get away.

A very positive experience so far!

Git Part 2 - Share Code with (a few) friends

In my current project we shared code among a few team members without impacting the others using Git. Since it happened twice and I already forgot it once, I put it here as a personal reminder. Hopefully it will help you too.

Imagine you're working on a feature and a teammate wants to use your code. But you're not finished, your code might break the build or some other functionality is broken. You have a few choices. You can send a patch. You can accept that the build is going to be broken. Or you can use Git and create a temporary branch for the sub-team to work on.

Setting up

Let's say you need to work on a new feature. First you create your branch:
git checkout -b myfeautre

The feature takes longer than expected. And you need help. But your changes will break the application and you don't want to impact every one. So you push your branch back to origin:
git push origin myfeature

Get work done (with some help)

Those who want to help you can create their own local branch.
git fetch
git branch myfeature origin/myfeature

I suggest you delete your own local branch and create another one as above. Your new branch will be linked to origin/myfeature so push/pull will work as usual. If you know another way to do this without deleting your branch, please tell me.
To sent your changes back to origin/myfeature, simply do
git push origin myfeature


Now everyone involved in the feature can commit as they wish.

Cleaning up

When you're ready to merge back to master:
git checkout master
git merge myfeature

Then delete your old branches once everything is working:
git branch -d myfeature # deletes your local branch
git push origin :myfeature # deletes the remote branch

Gotcha:
If you push using git push, it will push every thing from every branches, including master. Make sure all your branches are in a stable state when pushing. Otherwise you can push a single branch:
git push origin myfeature

I you feel I missed anything, don't hesitate to tell me.

Discovering git - How to have fun with a SCM (again)

I started using git about three months ago. I just love it. I had lost touch with the joy of using a VCS from the prompt. I was getting pretty used to CVS at the time. Then I entered the dark era of Clearcase. Most features were available from Windows Explorer so I got used to that. And I continued after for about a year using SVN with Tortoise. I could have gone back to my beloved prompt but I had lost my way.

Then came Git. And a host of neat little features that made me want to switch right away.

The first thing I loved about Git : you don't have any .svn folders in your project tree. Only a single .git folder at the root. Which means that you can use any tool you want to move and rename your classes and git will figure it out somehow. With SVN you had to be more careful - it happened in two of my project when someone (once it was me) thought it was a good idea to move a folder without a tool blessed by the SVN Gods. Bad idea - since the .svn folder is also moved, SVN still believes that it is committing files to the old directory.

With Git that's a thing of the past. It's a small thing but only this made me want to switch.

Then on my first Git project we merged two completely different repositories preserving the history of all the files. Nice.

And it's very easy to get started. No need to setup a remote repository. You can have most of the power of git with a local repo. 'git init' and you're ready to start. I now use it with all my projects, not matter how small.

And from then on, Git became favorite source control.

What are you waiting for? Try it! You won't regret it!

Inspiration

If you read yesterday's post and wonder where you can find motivation to start to practice, look at this. It's a screencast of Uncle Bob doing a Code Kata. A simple exercise, but if you look at the screencast you can guess he practices more than a few times.

I was tired tonight, but that's going to keep me going :)

10000 hours

There is no secret to developing a new skill.

Practice. Again. And again.

Looks like you need to practice a skill for 10000 hours before you can master it. That's around 10 years of deliberate practice. This applies to Olympic athletes, musicians, and... programmers.

That's one of the idea behind Malcolm Gladwell's Outliers.
The idea was also explored in Pragmatic Thinking and Learning.
Also see Peter Norvig's 'Teach Yourself Programming in 10 Years'

So what have you practiced lately?

Struggling with the Definition of Done with GWT

I've been pretty busy these past weeks starting a new project.

Since we've all followed Agile methodologies for a while, we wanted to have a definition of what 'done' means for the team.

A definition of done is useful when you want the whole team to agree when a feature is finished. It can include a mandatory code review, documentation, minimum code coverage, executable specifications, end-to-end tests... It should contain everything you need to do to get some high-quality code.

Although every one on the team is experienced, we've been struggling.

We all agreed that we needed to define what 'done' means. The content of some parts is still under discussion.

It wasn't hard to agree on a few things:

• We use Domain Driven Design for our domain as much as possible
• The domain and non-gui modules need to be unit-tested as much as possible
• We have a test map saying which kind of tests should be done for each modules (unit, integration, end-to-end)
• We need to document our module and architecture so others can join the project with too much ramp-up.
  

However on the GUI side we are still debating:

• We have a GWT application and we had no experience with the framework.
  
• GWT tests are slow by nature so we try to write relatively few of them. However for the tests we do need to write, we do not know our test coverage yet as cobertura does not seem to support GWT out of the box. It looks possible to use Emma instead of cobertura to get the coverage reports we want. However as far as I could see this would require us to patch GWT. We haven't tried it yet. It would help if we could find a simple tutorial instead of patches that need to be applied to specific revisions of the framework.
  
• End-to-end tests is an issue. Some people think it's too early to use tools like Selenium, others think it's past time.
  

Do you have experience with a project using GWT? What did you test? How? I'd appreciate if anyone could share their experience.

No Code

Less code is good. Actually the best code is code that is never written.

Code is going to be read by someone else. Less code makes everything easier to understand.

And the what a feeling you get from cleaning code!

Every line of code that can be removed brings a grin
Every method that can be deleted makes me smile.
Every object that can be eradicated makes me laugh.

Act like there is no tomorrow.

Obliterate code.

Mindset

I once worked on a project that had some tests but the architecture was... let's say it could be better. There were many files with over a thousand lines of code many classes had too many responsibilities I did not have enough fingers to count them all.

I think I failed to be as effective as I could in this environment for one reason. A very simple reason.

"Coding in the right mindset you did not" said my master. And the master gave me a bunch of dead trees which people commonly refer to as 'a book'.

Reading Working Effectively with Legacy Code by Micheal Feathers triggered a few thoughts. The book just led me to think differently about legacy code.

And what I found out the hard way is that I should have realized that I was working with legacy code.

Simple isn't it?

Then I would not have minded putting methods public to be able to test them. At least it allows me to test my code without too many changes.
Then I would not cared if the class I was working on had thousands of lines of code - I would just make sure the bit of code I was modifying was tested.
Then I would not have tried to refactor too much code. Small steps are the key.

I plead guilty. I was trying to hard to remove the design flaws. This slowed me down when I had to add features.

Learn from my mistakes. When working on legacy code, change your mindset. Forget about great and extensible design - or at least don't make it your priority. You have a job to do. Do it effectively. It might not be glamorous but in the end, you'll get the features out a bit faster while still improving the test coverage.

Book Review : Peopleware

Project failure is caused by human errors. Very few projects (if any) failed because they used PHP instead of Ruby. Projects fail because people fail.

Peopleware is about these teams. Your team. Why it might be failing it's current project. And mostly what it can do to succeed.

This time I decided to resume the book using a mindmap. I really liked the experience and will definitely give it another go. It allowed me to write down ideas and reorganize them in a coherent picture of what I learned from the book. I believe it will help me remember the main ideas as well.

(Click to view larger image)

"Quality is free, but only to those who are willing to pay heavily for it."

You can find the points I found most important in the mindmap. Still, I can't keep silent on one point : quality matters. A lot. Even more than you think. A team that aims to be the best tends to be happy. The turnover rate is lower. On the other hand, asking the team to lower the quality leads to disaster - demoralization, lack of purpose...

Build a cult of quality in your team. Pay attention to details. About everything. Strive to make everything must be perfect. Doing so will push the entire team to aim higher and higher.

Personnal Goals

People usually do it for the New Year, but for me the beginning of September was time to think about what I want to accomplish for the next year.

What better way to keep the determination to accomplish my goals than to publish them online and be publicly humiliated if I don't succeed?

So here is what I want to achieve until September 1st, 2010 :

• Write 40 blog posts. I aim for one a week but there are always vacations and weeks where I'm too busy on something else. Forty sounds like a good start for me.
• Read a book a month
  
• Code four small projects, one every three months.
  

After talking to my wife, she kind of forced me to get a fourth goal.

• Lose 10 pounds.

I'm not going to elaborate on this one. Talk to my wife :)

Why did I want to set goals?

I read quite a few books and articles saying that setting goals gives you a way to focus your energy. And a colleague of mine is impressing me by his ability to focus on short term achievements to attain his long term goals. Now is the time to see if these goal-oriented fanatics are right.

Why did I chose these goals?

Blogging - I'm committed to continuing on blogging for the next year. It allows me to try some creative thinking techniques when I'm out of subjects. It also forces me to organize my ideas and learn some subjects in more depth before I blog about them.

Books - I already read about 9-10 a year but I wanted to stretch a bit and go for one per month. That should be pretty doable. Books allow me to find new interesting subjects to talk about and I was always an avid reader. The book I'm currently reading is Peopleware. As I'm reading it I'm experimenting with mindmaps. I'll publish my insights in another post.

Personal projects - pretty much every years I code bits and pieces of small applications. I lay down architectures for more ambitious projects. But (shame on me) I seldom finish a personal project. Time is lacking or more interesting things come around. Whatever the reason, the result is that nothing gets done. Well this time I want to turn things around and focus on closure - I want each project to be finished, in a repo (trying git right now... loving it so far) and tested to my satisfaction. I'm not sure if all the projects will be publicly available, but at least one is going to be.

Final Thoughts

I selected short-term goals to get in the habit meeting my commitments. Setting weekly, monthly and quarterly goals seemed like a good start. Eventually I would like to have a Big, Hairy Audacious Goal, something that will drive me for years to come.

This is only the beginning...

Essential Bookshelf : Pragmatic Thinking and Learning

Last time I explained how the Pragmatic Programmer book changed the way I thought about software. This time I'll explain how another book challenged me to look at how I learn and process information. What I learned in this book can be applied to pretty much any facet of life.

The second book I advocate a lot these days is Pragmatic Thinking and Learning - Refactor Your Wetware by Andy Hunt. Yes, the same Andy Hunt who co-wrote Pragmatic Programmer.

Here are a few subjects that were covered :

• The Dreyfus Model - the journey from novice to expert, how people gain skill in a particular
• How to develop your intuition and why it is important for programmers
• Cognitive Biases and how they might affect your judgment and thoughts
• Generational differences - how different generations view the workplace and what are their values
  
• The Meyers-Briggs Type Indicator - a personality test, but what mostly interested me is interactions between different personality types
• Mind maps
  
• Tips and tricks to improve your creativity
  

There is a lot more to the book - many of the subjects are only briefly covered but they allowed me to get acquainted with a wide range of models and techniques. It is up to you as the reader to learn a specific area of knowledge in more depth.

What did I get from the book? So far I got interested in the Meyers-Briggs personality test and in creative thinking techniques. I also added quite a few books in my TODO list from the bibliography. These days I always have a new book waiting to be read...

Pragmatic Thinking and Learning is aimed primarily to programmers and has a few analogies such as "debug your mind" and "refactor your wetware". However the principles in the book can be applied to any skills you want to learn, from blogging to cooking. I strongly recommend it to anyone who likes to use their brain from time to time. Hopefully you'll be interested.

Empower Textmate for Ruby

I've been programming a bit in in ruby from Textmate and although the editor is pretty sharp, I thought there were two missing features.

• Start rspec tests
• Start the debugger from Textmate (not often useful but I still do it from time to time... maybe it's my old Java mindset...)

Behold! I found two plugins filling the description! (and do more on the sides)

• Rubyamp allows me to start the debbuger from Textmate and does a lot more.
  
• The rspec bundle allows you to start rspec tests from Textmate

As a bonus I also found TmCodeBrowser which allows you to see all your classes/methods and jump to them.

Power up Textmate with plugins!

I'll try to update this page if I find other useful plugins.

Essential Bookshelf - Pragmatic Programmers

I read lots of books. Lately I've been evangelizing the virtues of two of the books that had a deeply impacted me lately. This is the review for one of them.

The first book I want to talk about is Pragmatic Programmer, from Journeyman to Master by Andy Hunt and Dave Thomas. I read this book in 2001, after I worked for a year or so, and it totally changed the way I think about software.

There were lots of great advice under the form of catch phrase (DRY - Don't Repeat Yourself, No Broken Window, the Law of Demeter...). The authors even wrote about usage of metaprogramming and compilers in (almost) everyday software. But that's not what influenced me to become a better programmer.

What inspired me was that the authors have a deep passion for programming and it shows. They talked about investing in yourself as you would in an investment portfolio. "Learn a programming language every year". "Learn your tools". "Care about your craft".

I first heard the expression "rubberducking" in this book as well - if you can't find a human to talk to, talk to the duck.

However programming goes beyond coding. The code is important, but so is knowing your tools, the command shell, deploying an application in a real environment, build files and build automation. Programming is a social activity, you need to show your code to peers to get feedback and improve, you need to talk to your customer to know his requirements. You need to care, improve, learn!

That made me realize that the knowledge I have today is already obsolete - I needed to be aware of where the future might be heading, which technologies might come out on top in a few years. I started to read more books and blogs. I went to local user group meetings. I started a few pet projects in a few languages. And I realized that I would probably be programming even if it wasn't my day job - I was just lucky to get paid for it.

If you haven't read this book yet, it's a must for every programmer who is passionate about his craft.

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!

Clarify Your Intent

A maintainable unit test suite is essential in making software that will stand the test of time.
However after a while, some tests might get hard to read.
I was working on a flex application lately and was using fluint as my unit test framework. When we could we used the framework to test GUI components.
At some point we had a component that was composed of a text input and a button. For the sake of simplification, let's say that when clicking on the button, a label gets updated.
At first, the test looked like this:

component.input.text = "hello, world!"
component.button.dispatchEvent(new MouseEvent(MouseEvent.CLICK))
assertEquals("hello, world!", component.label.text)

When I read the test this is what went in my mind:

Set the text of the 'input' of the component to 'hello, world!'
Dispatch a mouse event of type click to the component's button
Make sure 'hello, world!' appears in the component's label text

That gave me an headache...
Next I changed the code to:

enterText("hello, world!')
clickOn(button)
assertLabelEquals("hello, world!")


Let's read it outloud again:

Enter text "hello, world!"
Click on the button
Make sure the label equals "hello, world!"

Now whenever someone looks at the test, the intent is a lot clearer. Whenever possible, try to make the test readable for a human being. Tests are part of your code. Written clearly, they document the intent and are a pretty good reference on how to use a class. However it's pretty important to make the test read like a possible user of the class would use it.
The API of the class being tested might be clear enough that you don't have to do anything. If it is not, don't be afraid to create another API in your test to make the intent clearer.

Iterate your Way to Success (and have fun doing it)

I've been interested about Agile methodologies for a while but until recently I've never been on a project that really embraced iterations and change. e did try a few techniques (daily meeting, poker planning, task board for the iteration) but it did not really work at the time, possibly due to a lack of successful evangelism on my part.

I just finished working on a third sprint in a Scrum project. And this time, it just worked.

The team was interested in the new process, the client was often coming to see what was going on, the ScrumMaster was great at explaining the process, the artifacts (product and sprint backlogs, burn down chart), the meetings and why we were doing each of them (daily, demo, retro). Some people were not familiar with the process but a quick and clear explanation of the next step kept everyone interested and in focus.
Here is what went right in this project:

• Preparation - the client and a few team members prepared a product backlog, rough drafts for the look of the user interface and a little bit of useful documentation.
• Collocation - everyone was sitting a few feet away from each other
  
• Quick wins - first sprint of one week delivered a bit of functionality while developing the build tools and test structure. This allowed the team to get a feel of what an iteration feels like (we did the planning, demo and retro as usual) while getting our build, continuous integration and test framework underway.
  
• Client involvement - on site two days a week, not changing his mind in the middle of the sprint. Would it have been better if the client had been there five days a week? Maybe, but two days is a lot better than nothing!
  
• We shipped! We did have a few hiccups, but overall we did ship working software and the client was happy with it.

And how did people feel about our ways of working? I can't talk for everyone, but here are a few things that I liked:

• Commitment- I believe everyone wanted the project to succeed and did their best.
• Openness - pretty much everything was open to discussion, including the architecture and the features the client wanted.
  
• Pride - for me this was a big one. I was proud of what we achieved and proud of the team.
• Fun - need I say more?
  

A few things could have been better:

• Lack of focus - we had a tendency to work on tasks on many stories and closed most of them at the very end of the sprint.
• Adaptation - our retrospectives allowed us to highlight a few points that we wanted to improve but we did not really address those in the following sprint.

Although not a silver bullet, iterative development sure give you all the tools to run a successful project. A motivated team will perform better and what better way to motivate people than to give them the power to improve and select their own tools and processes?

I'm eager to start on my next Agile project...

Working Agreements

You are in the middle of a great brainstorming session with your new team. Ideas are flying, everyone participates when you hear a ring. You hear in a hushed voice: "Sorry honey, I'm in a meeting, I'll call you back." Everyone stops talking to look at the culprit. The flow is broken. It takes a few minutes for the team to pick up where they were before.

Having a set of working agreements with your team can help to prevent this (and other) situations. Working agreements are behaviors that regulate all interaction between team members as decided by the team itself. This is very important: teams that decide their own rules are more likely to follow and enforce them. The act of deciding gives the team a sense of ownership. Working agreements can be discussed during a retrospective or if you don't do retrospectives (which you should), I guess you can do another meeting for them.

Once a team decided their own working agreements, it becomes easier for everyone on the team to enforce them, not just the project manager, team leader or other authority figure. “I did not appreciate when you were late to our pair programming session earlier today” is not understood as complaint about one’s behavior but as a gentle reminder of the rules the team agreed with.

Here are some examples of working agreements:

• The time everyone is expected to be at the office (9am-4pm or whatever fits your team). Outside these hours people have to be aware that some might not be available for meetings
• Usual lunch time (same principle as above)
• Time of daily meeting
• Meetings should begin on time
• Cell phones should be turned down during meetings
• Only one person at a time can be mad (I really heard about this one, it's supposed to allow people to vent while preventing others from shouting back...)

Working agreements can also be more fun:

• The person who makes the nightly build fail has to bring breakfast (pastries, donuts, fruits) for the team
• The person who makes a build fail is awarded the 'Cow of Shame' (or any ugly figurine) until someone else breaks the build

If the 'Cow of Shame' is ugly enough, your teammates will run the tests twice on their machine to make sure everything is green before committing their code... and so will you.