chris clarke

Continuous Deployment As A Practice

A lot of people do Continuous Integration these days (even if that just means source control and CruiseControl). But very few teams seem to do any form of Continuous Deployment. The point of Continuous Integration is to detect integration problems as quickly as possible and to reduce the risks involved in a deferred integration. A deferred integration is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems. As Martin Fowler says in his article:

“you are putting yourself into a complete blind spot right at one of tensest parts of a project”

So why is deployment any different? If your deployment process involves things that have not been done continuously every day, such as packaging files, copying them to servers, installing, configuring & starting processes, then you are doing deferred deployment. A deferred deployment is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems.

It may not be as easy to do Continuous Deployment - so keep it simple at first - grab your build artifacts from your Continuous Integration server, deploy them, automate the rest of your deployment process - then run some simple Deployment Tests:

• Is it up?
• Does it work?

Worry about adding more complicated things such as testing failover, load balancing etc. later. Just get some simple, automated deployment test coverage. I’ve seen & heard a lot of painful release processes, ones that take to 5 in the morning, ones that take 8 hours on the weekend, ones that involve a degree of ‘trial and error’ - don’t ignore your deployment problems - make them visible and try to fix them, just like you would with a slow build or a failing CruiseControl build.

Feature Crawl

Have you ever experienced feature crawl? That time on a project when features seem to take longer and longer to develop and less seems to get done than it used to. There are several reasons why this can happen, but I want to talk about problems relating to the growth of the codebase over time.

As the codebase grows over time it seems to take longer to add a feature. Adding a new feature often involves working out what the existing code does, seeing what functionality already exists that you need to use and finding the places where this functionality is available. The bottom-line is, the more existing code you need to understand and navigate through - the more time it takes.

So what can you do to help? Write Screamingly Obvious Code - code that your grandma could understand, code that’s so easy to understand what and why it’s doing something that a monkey with learning difficulties could understand it.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

Pair Programming Patterns

I’m trying to introduce more Pair Programming at the moment - so I’ve been trying to make it a fun thing to do. One of the ways I’ve been doing this is making use of the Ping Pong Pattern which has been working quite well. However, there are situations when this pattern doesn’t fit such as when debugging, refactoring, looking for something in the code or when their are big tasks which are hard to divide up. When not using the Ping Pong Pattern, I find its easy for one pair to dominate, get bored, silently think ‘OMG WTF is he doing?!!!’, or fall asleep.

So I’m going to just make some patterns up and list some ones I found which might be fun for those new to Pair Programming and stop me falling asleep:

One Line Each - Each programmer takes it in turns to write one line of code. This can be done in silence as a kind of game, or normally to continuously discuss each programmers intentions.

Two Keyboards and Two Mice - Both programmers can interact at any time - the idea is to stop one programmer dominating / hogging (via Steve Freeman).

Chess Clocks - Sam Newman describes it much better than I could.

Pair Poker - Each programmer gets a limited number of cards at the start of the day, they can choose to play a card at anytime and gain immediate control of the keyboard.

Different Roles - Each programmer takes on a different role, possible combinations:

• Refactorer / Programmer : One programmer cannot do anything but refactor, the other can do anything.
• Tester / Implementer : One programmer cannot do anything but write tests, the other cannot do anything but make tests change from red to green.
• Navigator / Programmer : One programmer can only move between classes, the other can do anything but move between classes.
• Adder / Remover : One programmer can only add code, the other can only remove code.

Roles can be switched every hour or just when one get’s bored.

Thinking of a fun thing to do whilst debugging, looking through logs, or looking through code was a lot harder.

Backseat Driver - To keep both programmers attention, one drives and cannot do anything without being directed by the other.

Driver Buckaroo - The driving programmer has to give up the keyboard every time some event happens (e.g. build breaks, someone swears, you get an email, the project manager cracks the whip, someone checks in, someone stands up).

Promiscuous Pairing - Basically pairs rotate more often. (I’ve tried this with a rotation every 90 minutes — it was fun but tiring.)

Driving in to Trouble

Testing edge cases.

Every time I run in to something that gets in my way, slows me down or just annoys me I write it down on a card. If I run in to the same problem again - I add another notch to the card (like a tally). A colleague has a principle of Three Strikes and You’re Out - that is, if you come across the same problem three times you have to fix it. I also find it useful to take these cards along to retrospectives or stand-up meetings. Fixing these things that get in the way has really had a positive effect on productivity and made the team more interested in fixing bad things rather than taking the extra time and effort to work around them.

Red, Green, Cup of Tea

I like the Red Green Refactor pattern - write a failing test, make the test go green and then refactor the code. However, I’ve found recently that refactor doesn’t necessarily mean make the code tidier or improve the design to some people. To some people it just means change some existing code.

So I invented (by accident) the Red Green Cup of Tea pattern - write a failing test, make the test go green, and go and make a cup of tea whilst the build runs. I’ve found that whilst making a cup of tea, my pair and I can reflect on what we’ve just done and often find we weren’t 100% happy with what we just did. We then set our cups of tea back down on the desk and Refactor the code.

Annoying Patterns: Setter Injection

What do I have to do to get this object to work in the way I want?

Does setting some things rely on having set something else?

With all these public setter methods the objects state can change throughout it’s life. If I have to pass references to this object around maybe I don’t want people changing it’s state.