lixo.org

In the 1890s, a guy named George Stratton decided to build a pair of glasses that made the world upside down. He wanted to explore the effect of presenting the retina of our eye with an upright image, since the image that it sees is inverted.

The conclusion of his experiments demonstrated that, after some hours of adaptation (and probably making everyone in the room collapse in laughter seeing him trying to drink a cup of tea), most things he saw looked normal using those glasses and, upon closer inspection, looked weird again. Since then, tens of scientific experiments have based on his conclusions to find out about other interesting and wacky situations our brains can adapt and readapt to.

Today, I opened IntelliJ again, after about 3 months of heavy Eclipse usage. Trying to use the keyboard shortcuts felt like taking those glasses off.

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).