lixo.org

On an application I’ve been working during my spare time, I had the need to ask my loyal friends and guinea pigs to give me some feedback, in order to help me fill in the gaps between what I think they want to do and what they really want to do in this application.

A quick, cheap and really useful solution I came up with was adding a feedback form right there, on every page the application renders. This can certainly be improved by people more knowledgeable in Rails than myself, as for now it doesn’t even use AJAX to post the data back (shame, shock and horror!)

After running scaffold_resource Comment body:text uri:string created_by:integer created_at:timestamp, you should be pretty much set to go. Now, on your application.rhtml, you can do something like:

<%= render :partial => "comment", :collection =>
Comment.find_all_by_uri(request.request_uri) %>

<% form_for :comment, Comment.new, :url => comments_path do |f| %>
  <%= f.hidden_field :uri, :value => request.request_uri %>
  How would you improve this page?
  <%= f.text_area :body, :rows => 5 %>
  <%= submit_tag 'Add comment' %>
<% end %>

The _comment.rhtml partial is something like this:

<%= comment.body %>
Created by <%= if comment.created_by.nil?
    'unknown'
else
    link_to(comment.created_by.name,
      profile_url(comment.created_by.profile))
end %>

<%= time_ago_in_words comment.created_at %> ago

[<%= link_to 'Destroy', comment_path(comment.id), :method => :delete %>]

Customize the Comment controller slightly, and that’s it — instant feedback forms everywhere!

At my current project, we have a good definition of what the real data in the system will look like, since the first few releases are basically migration with the addition of some new features.

But, a couple of weeks ago, something started happening to the test code: instead of creating a place like ‘France’ and a non-place word that goes with it, like ‘skiing’ – which is something you’d be likely to see in the production database, people were choosing their test data based on wacky and unrelated concepts. Places like ‘plate’ and non-places like ‘cheese’ were popping up left ,right and centre. Converting an object from ‘cheese’ to ‘pizza’ seemed quite odd when said out loud, but made sense in the code, just as converting a legacy object to the new domain model, after some validation and filtering did. But it’s a much shorter and visual sentence.

What happens when you do such a thing? Your test code looks like something you’d never put in production. No production code would have variables like ‘cheese’, ‘bacon’ or ‘sausages’. But test code can afford that, as long as it expresses the behaviour you’re trying to test clearly, and weird variable names or test data don’t detract from that.

Plus, the hilarity that ensues when you get your customer talking about the stories in half-breakfast, half-business terms is enough to bring the team morale up a bit.

Any experiences on that? I’d like to hear’em!

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.