lixo.org

At ThoughtWorks and many other workplaces all over the world, employees are given SecurID tokens, a tiny and nearly indestructible device with an LCD screen that shows a different sequence of six random numbers every minute.

So, what do you do with a sequence of random numbers, apart from logging into your corporate intranet and email using secure two-factor authentication? You play Poker, of course!

The rules are pretty much the same as a Draw Poker game, only without any card changes or betting round. Ordering is also different, 0 being the lowest and 9 the highest values. There are no suits, but the time left to the next sequence change, displayed in bars at the left-hand side of the token, can be used to settle ties. A new round is usually more convenient, though.

As two fobs don’t change sequences at the same time, it makes sense to shout out your hand as soon as you look at it, or see if you can get away stalling everyone until your next hand shows up, if you have nothing. Of course, there’s room for the High-Low Split variation, but that could get a bit messy and has been discouraged.

I was introduced to this brilliant little game last night, and it has instantly gained my preference over Rock, Paper and Scissors to settle small arguments such as who’s going to get the next round, fix the build, pay the restaurant bill or drive the rental car.

Interesting quote from my colleague Obie after my comment that software development projects have five variables (time/duration, budget/price, scope, people/rates and quality) and that we should be able to respond to change in all of them, on this post:

(…) Letting quality slip has never, ever produced good results in my experience. I’ve been in situations where the client was explicitly demanding it, but it was still a bad idea and has all sorts of negative repercussions on the team.

Some might argue over the exact definition of those variables and how they play together. I write specifically in the context of consultancies, in what I may have some experience in.

In this context, budget/price equals time/duration of the project times people/rates including the management overhead. It’s a simple and easy equation which has traditionally left the scope and quality variables out, up for discussion. And those discussions can go on and on until the last pointy hair is yanked in despair.

To us and most people in the Agile world, quality is not even really a variable - we like to think it’s a constant, and hopefully fixed way up high close to 100%. To clients, not necessarily so - while some definitely know the importance of a good QA, some might be willing to take the risk and compromise the quality of the product in order to gain some market advantage by reducing the duration of the project, or to save some money on the short term.

As long as everyone understands what playing with that variable causes to the sustainability and risk of a project, and there is a justifiable reason to do so that the whole team can buy into, I don’t see a problem. But, you see, that’s only a theory of mine - I’ve never actually seen that compromise being made with a reason I could believe myself.

PS: I need some feedback on this! If you know - or even better, was involved in - a project where that happened, please get in touch.

I think retrospectives are the most informative and fun kind of meeting you can have with a bunch of software developers without involving large amounts of some kind of alcoholic beverage. Okay, maybe seconded by giving them a huge set of Scalextrics.

When doing retrospectives, the facilitator often chooses to do what’s called a ’safety check’. It’s about trying to get a feel for how much confidence there is in discussing the current topics with everyone else in the room. The facilitator gets everyone to write a number from 1 to 5 on a post-it note, anonimously, and sticks them up in a wall or whiteboard, tallying up the results. Usually, a safety level of 1 means ‘I don’t feel safe here, I’ll nod and agree to what everyone else says’ while 5 goes something like ‘I feel I can talk about anything and anyone in this room freely’, and that is a very important measure to have as it can completely change the discussion. Sometimes, asking a one or a few team members (project managers, for instance) to step out of the room can improve confidence, and everyone’s happy.

But what about the other measurements that may affect the effectiveness of a retrospective and work in general? My colleague Tim Mackinnon (get a blog!) brought a very nice idea to one of our monthly meetings this week: using the same mechanism to scale how much fun, productivity and enthusiasm people are having at work. If I had an equivalent of MS Paint on my Mac, I would amaze you all with my drawing skills, but for now, picture this: you draw as many axes you want on a whiteboard, ideally three or five, as choosing an even number can look a bit confusing. Each axis represents some measurement you want - fun, safety, productivity, effectiveness, collaboration, you name it. And get everyone to tick their level on those, preferrably anonimously.

I’m still yet to be a facilitator on a retrospective, but I’ll be definitely trying this out.

Oh, and if you’re interested in the subject, make sure you’re subscribed to Pat Kua’s blog. He has some very interesting thoughts on timelines and other retrospective tools.

Every complex enough piece of software does some sort of integration. And every point of integration is a point of failure waiting to happen, from the simplest network delay to larger scale horribleness. So, testing it all properly is quite often a great idea.

Conditions like what to do when one of those external systems comes down or becomes unavailable are a bit hard to spot in TDD’ed code, and in my experience become difficult to visualize in code and unit test form. And when I’m sitting there with images of train wrecks, mass murder and Britney Spears doing a cover of Stairway to Heaven, I want to be able to see things clearly.

One of the tools we recently reused at our current project was a testing pattern that proved itself very useful, making it possible to have all possible failure scenarios in one or two screenfuls.

We’re using a table like this (Foo and Bar are our integration points):

You can add as many integration points as you like, and maybe some other variables or specific error conditions as well.

We’re using Fit, and it’s pretty easy to write a test to do that. Plus, we get 100% coverage (or find that we didn’t actually need to catch some exceptions), something otherwise difficult to achieve when not using higher-level test automation tools (and a whole universe of pain when doing manually).

I had an interesting chat last week with some colleagues from ThoughtWorks about a situation we currently have at a few of our clients. It’s an interesting economical challange and, even though I’ve missed most of my Economy classes, I still like the subject. Point is, companies and IT contractors tend to develop a variation of the Stockholm Syndrome over time because of the way incentives play out.

It goes like this: FooCorp has a big IT project ahead of them, which will need about a dozen developers. They’ll only need a third of that to maintain the application once development has finished. It makes sense for FooCorp to hire the remainder of the staff as contractors, so that they can show them the door without too much hassle when everything goes to production use. Contractors, therefore, take the risk of having to look for another gig sooner than expected, in case the project gets cancelled, and adjust their rates accordingly. Those high rates may lead to a project management working under budget pressure, which might drive managers towards shrinking the feature set and/or the schedules. Here’s where the fun bit starts: are there any incentives for a contractor to actually deliver any quality software at all?

As I see it, there are two positive incentives: peer pressure in justifying rates, and collecting good contacts and references. In the situations we have been witnessing, those pale next to doing whatever is possible to extend the contract, which more often than not are some incarnation of finger-pointing, back-stabbing or just plain inaction in order to make the project as late as possible. By extending the contract, they can ensure there’s always time to fix the mess created by blaming everyone else but their contracting buddies (those who’ll happily point them to new gigs) and pretending to work harder than everybody else by assuming authorship of other people’s work and ideas, while happily surfing the web all day.

Wouldn’t anyone at FooCorp notice that? They may have, but by the time they realize how serious the situation is, it’s usually too late to dismiss the contractors without seriously bleeding knowledge from the project and risking the schedules too much. In a way, there’s all this business knowledge being held hostage by the contractors, and the ransom is to be paid in monthly installments, until FooCorp’s employees pick it up and are able to run maintain the project on their own. Keith Henson wrote, in Sex, Drugs, and Cults:

Fighting hard to protect yourself and your relatives is good for your genes, but when captured and escape is not possible, giving up short of dying and making the best you can of the new situation is also good for your genes. In particular it would be good for genes that built minds able to dump previous emotional attachments under conditions of being captured and build new social bonds to the people who have captured you. The process should neither be too fast (because you may be rescued) nor too slow (because you don’t want to excessively try the patience of those who have captured you).

Of course, there are contractors with good ethics and who manage, against all odds, to deliver some truly amazing code.