Git is not (just) Source Control

June 20th, 2010

After many discussions with a colleague about Git, I came to realize that Git is not merely a source control. With time it became a tool in my developer’s sandbox. To develop software effectively, I need (among other) an IDE or text editor, a prompt and countless libraries. I came to rely and trust these tools.

I used many other tools for version control but I saw them as infrastructure – mandatory in the grand scheme of things but not used to improve my productivity.

Git changed everything by allowing me to rethink the way commits and branches work.

  • By promoting small commits that do one thing but do it well, git forces me to split my task in even smaller chunks that can then be commited. This sometimes leads to architectural changes.
  • By making it possible to  reorder the commit history (git rebase -i origin), it pushes me to make each commit clean and atomic.
  • Git makes branching cheap and easy. Like you, I try to code each features in a separate branch. But unlike you, I am undisciplined and often forget. However if I start on a feature and realize it takes slightly longer than expected (and I’m talking about an hour max, not 3 days), I create a branch for that feature. It’s easy and it allows me to work in small, independent chunks. It also allows me to always be able to come back to a stable branch if I need to do a few quick fixes on another part of the project.

Git is not a mere tool – it changed the way I design and code.

Shrinking your Team for Improved Productivity?

June 7th, 2010

Unless things go sour in a project, a team rarely gets downsized. On the contrary, new team members are often added in the hope that more will get done.

What if sometimes, the best action to increase productivity would be shrink a team? I can think of two situations where reduced staffing is a good option:

  • The team realized that it grew too fast. Core team members do not have enough time to effectively coach the rookies.
  • A new features requires an overral architecture change. You can already predict that merging will be hell if new features are added while others are implementing the new architecture.

It’s not always feasible to remove team members – and it’s always a though decision. If the team grew too fast, you might not have any other choice. If you want to do it because you need a big architecture change, it might be possible to shift some members to another module or to start something new that will have no impact on a problematic area. You might also try to make the change coincide with half the team going in vacation (I’m sure many of you felt more productive when most of your team was away).

Next time you’re stuck and have a hard time finding effective ways to make the whole team work together, consider a reduced staff for a few weeks. It might be just what you need.

Quote – Organization culture

May 25th, 2010

While going through Crucial Confrontation to finish up my mindmap, I came across an interesting definition of the word ‘nice’. It seems that many people describe their organization’s culture as ‘Nice’. So the authors came up with a new definition of the word:

Nice
adj. A pleasant, nonconfrontational attitude that eventually kills you.

Does that sound like your organization? If so it might be time to change your corporate culture.

Interesting Quote About Failure

May 21st, 2010

I saw this quote on 37signals’ blog and I thought it fit well with my latest post on failures.

“It’s important that nobody gets mad at you for screwing up. We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible.”

- Lee Unkrich, director of Toy Story 3, Wired magazine

If the goal is to screw up as fast as possible, you need an environment that allows you to do it safely.

Failure is an Option

May 18th, 2010

Failure is often a dreaded word. It need not be. Programming is an art where it’s very easy to fail and you can usually fail fast. Use it to your advantage. Learn to fail with style.

Give yourself the option to fail deliberately and safely. Many tools can help you:

  • Branches – Since I started using git, I often create a branch to play around with the code… then delete it and start again from scratch once I know where I need to go. This gives me the freedom to change configurations, disable features and modify code without tests. I even go as far as breaking existing features (sometimes they don’t even compile) if it makes me learn faster.
  • Prototypes – create a simple throw-away project to test your code.
  • Tracer bullets – whenever I need to connect a few modules together, I like to have a tracer bullet that will handle the normal path without any error handling. It gives me confidence that all the pieces fit together. It proves the chosen architecture works and yields the expected results.
  • Tests – if I want to know how a particular method/class reacts in a specific context, I will sometimes create a test to test my behavior. I might keep the test as-is or sometimes I throw it away and it becomes part of a larger test.
  • Scripting languages – ruby, python, groovy or whatever you fancy, these languages can often help you test an algorithm faster than in Java or C#.
  • Pen & Paper – low tech, but sometimes writing down your thoughts is the best way to go. If it doesn’t work on paper, chances it works on a computer is pretty slim.
  • Rubber duck – having an inanimate yellow friend near your computer that you can always talk to can never hurt :) .

A rubber duck

Code is cheap and fast to write… once you know the way. A few failures early on will help you get a success when it counts.

Technology Radar: What’s Hot, What’s Not

May 5th, 2010

Thoughtworks published another version of their technology radar. I think it gives good insight on the state of the computer industry. I recommend reading it but to tease you, I’ll give you a few highlights:

  • Ruby (and JRuby) are ready for adoption.
  • You might consider to start fading out Java (as a language) to use some of the alternatives on the JVM.
  • Languages on the JVM (Scala, Clojure, Groovy and of course JRuby) are growing and well-positioned to be more widely used in the future
  • Although they love Distributed Version Control tools (Git, Mercurial), they require more knowledge to get the most out of them so using good-old Subversion might be better for your team. Although I would never want to go back to Subversion now that I switched to Git, I have to agree: before adopting Git, make sure you have someone who can handle it in your team.
  • Think twice about using GWT. Although it promises writing Java-like code that will then generate unit-testable Javascript widgets, in practice it doesn’t work very well. I’ve practiced a lot lately and I tend to approve their point.
  • Amazon’s EC2 is the most mature solution if you want to deploy on the Cloud.

Read their analysis to know more. It talks about NoSql, Restfulie, C#, Internet Explorer, HTML5… There’s something for everyone and you might learn about a few technologies that will be big in the near future.

One tomato, two tomatoes

April 28th, 2010

The Story

My teammates are not afraid to ask help whenever they are stuck. We trust each others. We believe in each other. Disagreements are common but it makes us stronger. We work in an open space so it’s easy to get information to everyone.

That sucks. We talk too much. We get distracted from our own problem to help someone else. We ask questions aloud because we know someone will answer, then an argument follows and every one pitches in. Being passionate has drawbacks.

And then we discovered the Pomodoro Technique.

Tomato

The Pomodoro Technique aims to provide increased productivity by splitting time into small increments of work without interruptions. To explain it in one sentence : work for 25 minutes, take a 5 minutes break. If you want to know more about the Pomodoro Technique, check their web site. I’m far from being an expert on the subject. My goal is to share my experience and what we gained by using this technique.

The Beginning

A few teammates talked about the Pomodoro Technique during an Open Space a month ago. As with many good ideas in open spaces, this one went dormant for a while. An afternoon two weeks ago though, something changed. The sprint was in peril. We all felt the urgency to change though we weren’t sure what. After a brief explanation of the technique, we decided to try one big team Pomodoro.

Results

There was something magical about our first Pomodoro. Silence. Concentration. No interruptions. After 25 minutes we took a break and regrouped. We needed to synchronize. I remember discussing the API between two parts of the application. A quick review – were we willing to try another Pomodoro? Unanimous answer: YES!

We did four Pomodoros for our first day then held a quick retro. We didn’t have concrete numbers but we all felt increased concentration and productivity. We decided to continue for one more day and see how it goes.

Ongoing effort

We’ve been using the Pomodoro Technique for two weeks now. Not all our work is done during a Pomodoro. We do about four Pomodoros in the morning and another four in the afternoon. I’m pretty sure it improved our productivity though I have no hard numbers to prove it. We have a rhythm of very intense work followed by an explosion of discussions to synchronize everyone. Every Pomodoro, we commit to work on one thing. During the 5 minute break, questions are asked, new pairs are formed, help is offered and given, tasks are switched. The work done in a Pomodoro is diverse. It could be pairing, writing documentation, sending an important email, a design session… The important thing is to work on whatever you commited to.

Perception

We do look like weirdos. There is a whiteboard with a big tomato (Pomodoro means tomato in Italian) indicating to everyone else in the company that we are currently in a Pomodoro – do not bother us. We’ve been told that the pace a Pomodoro dictates is very hard to follow. The team doesn’t feel that way at all though. Colleagues outside the team need to get used to us sending them back to their desk if we’re in the middle of a Pomodoro, but a few started to come in and watch our clock before interrupting. One thing is sure : lots of people started to talk about us.

Final Thoughts

The Pomodoro Techniques works. Even when we are not officially in a Pomodoro I find interruptions to be less frequent. We salvaged a sprint and the current one is one the way to success in part due this technique. The fact that the entire team decided to try it at the same time helped a lot to see the effectiveness right away. I tried a few other productivity techniques and so far this one had the most impact. You have to try to see for yourself.

Photo by Darren Hester

http://www.flickr.com/photos/darrenhester/

Demo Driven Development

April 25th, 2010

We’ve had enough. We want demos that are fluid. We want demos that are fun. We want demos that work.

So my team tried something which we called ‘Demo Driven Development’ during our last sprint.

In every one of our stories, we included a task called ‘prepare the demo’. This task was only scheduled to take an hour. We just wanted to make sure the story could be demonstrated. The team also named a demo champion (me) for the iteration with some reserved time to prepare the demo. All these tasks were included in our sprint backlog.

The results were pretty good. The demo went smoothly for the most part. I did a small blunder that broke the flow a bit (sorry team) but feedback was positive during the retrospective. The team decided to keep doing the same thing for another sprint, just to see where we’d go.

To me though, the biggest change was not the demo itself but the awareness demo driven development brought. Every time I worked on a user story, I was thinking about how I could show it. The end result was that the feature was just a tad more configurable. One particular story didn’t have a UI so I made logging more readable and complete because I needed people to be able to understand what was happening.

The code was more or less the same. But the feature was better.

Some of you probably think that every story should be coded to be demo’ed anyway. You’re right, it should. But we wanted to improve in this area and it worked for us. Maybe Demo Driven Development is for you as well.

Shipping *is* a Feature

April 11th, 2010

I once received a wall clock with these words : “Shipping is a feature”

I don’t remember what happened to the clock. Maybe I should have kept it around.

Sometimes remembering that you need to ship your code is enough to give you a well-needed push. Good UI, architecture, testability are all necessary… but it’s easy to push too far. Sometimes you have to go with ‘good enough’ and ship.

git bisect saved the day

April 4th, 2010

I had a weird bug UI bug. I couldn’t fix it, I couldn’t get around it… everything I did seemed to make the bug worse.

So I spend some time looking at funny pictures of cats, and that’s when I remembered that I had all the power of git to help me… and I heard the cat whispering: “Git bisect to save the day!”

A Funny Cat

Funny cat? You can't be serious...

Yeah, looking at cat pictures makes me go crazy. Go figure…

Coming back to git, I read the doc and bit and away I went:

git bisect start
git bisect good last_good_release
git bisect bad master

git now sent me to a revision between those two… last_good_release can pretty much any commit identifier (a tag, the sha1 identifier…)

I compiled, ran my test… all good. The bug wasn’t in this version.

git bisect good

Git selected another commit. Compile, test… hmmm… the bug appears it this version

git bisect bad

Git bisect helps you do a binary search over your commits. It checks out something in the middle between ‘good’ and ‘bad’. You check to see if the bug is there. If it is, ‘git bisect bad’, if not ‘git bisect good’. And you continue until you find the guilty commit.

Eventually I found the culprit… It was nowhere near where I thought the problem appeared to be. I had lost a lot of time… but I found it, thanks to git!

Git bisect saved my day.