Continuous Integration is a common practice in Agile development circles, but I think people (especially those new to agile thinking) sometimes miss the point.

Problem is, the term has become synonymous with build-servers such as CruiseControl (etc, etc), which frequently grab the latest code, build it, and execute automated tests. These are often referred to as "continuous-integration servers", which IMHO is a really bad name, 'cos if there's one thing these servers typically don't do, it's integrate.

And the point of continuous-integration is just that: Integrating. Continuously! Which means:

• developers frequently updating their working-areas (or personal branches) with the latest code on the mainline branch (typically many times a day), and
• frequently merging their own changes back into the mainline (typically several times a day).

Unless you're doing this, you ain't "doing continuous integration", however frequently you're running automated builds!

Integrating continuously can be difficult. In particular, it forces you to chunk larger changes and features into small, bite-sized pieces that can be drip-fed into the codebase. And, you have to deal with other developers changing stuff all the time. Build-servers and automated tests are essential tools here, because they help keep the team honest, ensuring that everyone has a stable (if evolving) base to work on.

There are are plenty of upsides to frequent integration:

• each individual integration is smaller, and therefore easier
• design issues (including differences of opinion) are identified earlier
• developers can leverage each other's work earlier
• changes can be tested (and bugs detected) earlier
• software can be deployed more frequently

In summary: check it in already!

In developing software, consistency often helps:

• Refactoring your code to reduce duplication makes your system easier to extend, and provides bugs fewer places to hide.
• Solving similar problems in similar ways (e.g. using design patterns) promotes conceptual consistency, allowing teams to communicate and collaborate more easily.
• Adhering to user-interface guidelines can make your application more predictable, and therefore, more comfortable to use.

That's great. But don't lose sight of the real goals, like: usability and maintainability. Consistency is just a strategy; if it's allowed to become a goal in it's own right, things can start to go awry:

• Comments are sometimes helpful, but making them mandatory for every method/procedure often reduces maintainability, by making the code "noisy".
• Parts of your system may benefit from declarative security and transaction management, clustering, and all those other tempting features provided by EJBs, but that's no reason to use them everywhere.
• An ORM tool like Hibernate is great for building object-oriented, domain-driven, RDBMS-backed enterprise applications, but if all you're doing is dumping data as CSV files, perhaps it's overkill.
• Your defect-tracking system might be good for tracking, er, defects ... but that doesn't mean you should use it to manage all your work.
• Re-use is nice, where appropriate, but some things that look conceptually similar from the ivory penthouse can turn out to be quite different once you get into the details. If it requires more code to use an existing library, than to implement your feature directly, then the library isn't adding value.

In summary: keep your eye on the ball. (Whoops, there it goes ...)

When developing using XP, the development team estimates the work using some arbitrary unit of time, which is then mapped to real time using a measured velocity factor.

Often, the unit of estimation is something like an "ideal day" or perhaps an "ideal hour", or an "ideal week", depending on your level of extremity). An "ideal day" is about the amount of work a developer feels s/he could get through in a day if fully fed and watered, well-rested, un-interrupted, and so on. Estimating this way makes sense from a developer's point of view, as we typically know what a day's worth of work "feels" like.

But, in addition to the fact that interruptions etc are inevitable, we're usually somewhat optimistic (read: utterly delusional) in imagining how much work we can get done. Often, by the time I've clarified requirements, written tests, etc, it takes me two to three real, elapsed working days to complete a task that my gut told me would take one "ideal day". (That's me; I'm a consistent under-estimator ... though I think a factor of 2-3 is fairly typical.)

If everyone involved understands this, and can interpret estimates through the lens of an appropriate (preferrably measured) velocity factor, you might get away with it.

But when you include a word like "day" in the name of your unit-of-estimation, people (non-agilists) can be forgiven for making the assumption that they map roughly to real, elapsed days. They'll probably give a little, but when you try to explain that it might take several days to complete an "ideal day" of work, it's often a hard sell. If the people who don't "get it" include your customer, or project manager, then you have a problem!

In future, I'm going to estimate in something like StoryPoints, in an attempt to avoid the mis-interpretation. To further discourage bad assumptions, I'll probably take my internal "ideal day" estimate and slap a zero on the end. I figure that:

This week, I completed 20 story-points.

will be less likely to invite argument, panic and retribution than:

This week, I did 2 (ideal) days worth of work.

Wish me luck.

I'm nearing the end of my first week at ThoughtWorks.

I have to say, I'm impressed by TW's onboarding process ... when I arrived on Tuesday, they had waiting for me:

• a brand spanking new laptop;
• network/mail accounts already set up (I even had several weeks worth of mail backlog);
• an orientation folder (containing info that is actually useful);
• a corporate Amex card;
• a stack of TW branded goodies (shirts, fleece, mug, etc.);

Some of this may seem a bit naff, but it really makes new hires (like me) feel welcome, and valued.

It's a nice contrast what I'm used to, e.g.

• "Sorry, we haven't got a PC/desk/key ready for you yet."
• "Sorry, everyone's really busy right now ..."

Like I mentioned, I finished up on a job last week.

When I've left previous jobs, the final few weeks have typically been full of the stress of last-minute documentation and handover. This time, happily, there was none of that.

The difference, I think, was pairing: over the last couple of years I've made a point of trying to involve other people in whatever I was doing. As a result, even though I was a key contributer to the team (he said with a straight face), my leaving wasn't a great drama.