Enough with this seat-of-your pants "eXtreme Programming", this twisty-turny "Agile" bollocks, and this anorexic "Lean"! You're all a bunch of cowboys!

The time has come for a return to a more sensible, conservative approach. Just be a little more careful, okay?

Careful, don't waste your money (and time)

It's sensible to ensure that what you're building has real business value. Ideally, you should be building the highest-value stuff first. Anything less, and you're being careless with your (or someone else's) money.

Careful, make sure it's useful

It's worth saying again ...

If you build stuff that users don't want, nobody's going to end up happy. I suggest you keep in close contact with them. Show them what you're building for them as soon as possible (yes, even before it's "finished"), so they can help keep you pointed in the right direction.

It's important to listen to your users, but don't forget that they (like you) only have part of the picture. You need to work with them to find the best way to solve their problems, rather than just implementing their proposed solutions without question.

Even when you eventually understand what the requirements are, the rest of the team might not. So you'd best write the requirements down somewhere. Somewhere safe. Code (in the form of automated tests) is an excellent way to express requirements, because (unlike other options) it's hard to misinterpret.

Careful, don't miss the turn-off

Plans are great; make sure you have one. But don't follow it blindly. Once you get going, you'll probably discover lots of things you didn't know when you made the plan. You may even stumble upon some useful short-cuts: ways to deliver more value, for less cost! Don't let the plan prevent you from taking those opportunities.

After all, even if you have a map, it's still useful to look at the road ahead. Where'd you get that map, anyway? Oh, you drew it yourself?! Well, why not slip that back into it's protective plastic cover, so it doesn't get grubby. There ya go. And keep an eye out for road signs, okay? Excellent.

Careful, free stuff isn't always cheap

You may find something that looks like it might solve all (or some) of your problems. Perhaps some free software, or a product you already have licenses for. That would be nice.

But beware! Adapting your problem to someone else's solution is hard, and if you fail, leaves you in a delicate situation. In some situations, rolling your own solution works out cheaper in the long run.

Careful, don't bite off more than you can chew

Q. How do you eat an elephant? A. One bite at a time.

For god's sake, don't give yourself indigestion by tackling the whole trunk at once! I had a cousin who did that, and she still can't ride a bike properly.

Slow and steady wins the race.

Careful, don't break the stuff that's already working

Software's not easy, you know. It gets complicated inside that big box. And hot. You might accidently trip over some important wires while you're in there installing the new fnord-wangling module.

You know those automated tests, ummm I mean requirements, you captured earlier? Just run them again. Actually, run them as frequently as you can; that should alert you to any inadvertent mistakes as soon as they occur.

Careful, don't let it fail in production

Oh boy, if it goes wrong in production, your users are going to be mighty grumpy. That's embarassing. And these things tend to happen whenever it's least convenient. You might just have to cancel that ski-trip.

Careful, too, to have good processes for finding and fixing production issues if and when they do occur. Make sure you can turn fixes around quickly. You may make the ski-fields yet!

Careful, don't step on your own toes

Make sure that the team is all working towards the same goal; all pulling in the same direction. Yeah, unfortunately that means talking to each other. All the time. But otherwise, you'll just get in each other's way.

Careful, don't be left holding the (ugly, vomiting) baby

There's a chance (actually, let's call it a certainty), that the rest of the project team will desert you. The clever ones are likely to leave first.

So, I suggest you ensure you have a decent understanding of the system before they go. Documentation might help. But probably not: most of it tends to be kind of useless. You're probably better off working with them a bit while they're still around. That way you can ask them questions.

And if you work together, you'll likely produce a more maintainable result, anyway.

Okay, then

In the immortal words of Sergeant Phil Esterhaus:

"Let's be careful out there."

Thanks for listening.

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.