Jakob Nielsen on the use of Agile methods:

Agile’s biggest threat to system quality stems from the fact that it’s a method proposed by programmers and mainly addresses the implementation side of system development. As a result, it often overlooks interaction design and usability, which are left to happen as a side effect of the coding.

In my experience, mostly as a developer, it is really easy to dismiss interaction and usability design for two reasons.

The first comes from the developers themselves, trading prettiness and consistency of user experience for cleaner and sounder domain models whenever they go in opposite directions. Signs this is happening are developers crying YAGNI when the stakeholders ask for a zoomable chart or DTSTTCPW when a sortable, paginated data table is required.

Next time you see a system where there are enormous listings of items with no search, pagination or sorting, ask the developers if they have ever watched a typical user at work; chances are they have only thought about the system as they see it: since the testing dataset is usually small, a loop spitting out a bit of HTML for each element isn’t such a big deal. They might even say there’s a story to implement all that lovely stuff later on, but they just get moved over and over to the bottom of the backlog barrel… until everyone watches a person struggle to find needles in a tabular haystack all day. This is a simple example – almost too trivial actually, but one I’ve seen happen way too many times.

Changing the perception that usability is just the icing on the cake draws attention to all that wasted time to the stakeholders, and should enable a much better dialogue: developers get to write an application users will love, stakeholders spend their money wisely on something that will actually increase return on investment (as productivity gains), users feel empowered and less likely to make mistakes. Everybody wins.

The second reason UI design and usability get overlooked, and this is the one Frank alludes to in his latest post, is that some agile teams rely a bit too heavily on the stakeholder’s descriptions of what is wanted. It instantly reminded me of one my favourite quotes from Cars:

Lightning McQueen: All right, Luigi, give me the best set of black walls you’ve got.

Luigi: No, no, no! You don’t know what you want! Luigi know what you want. Black-wall tires, they blend into the pavement, but these white-wall tires, they say look at me, here I am, love me.

Lightning McQueen: All right, you’re the expert.

I find it rare for the stakeholders to know exactly what they want, down to what the end-user experience should be like. Thinking about a reasonably-sized application at this level of detail can only be done as a series of small, incremental steps and having someone on the team who is really obsessed about making every single pixel on the screen be in the right place. And if you read the last sentence and thought “well, that’s not exactly the role of my stakeholder!” you get the point: the stakeholders should not have the final word as to what the usability and experience details should be, in the same way they simply delegate to and rely on the expertise of the development team to flesh out the details of a persistence layer.

Have look and feel expertise in your team, and trust it, in the same way you would trust the database or network connectivity expertise.

A toothpaste factory had a probem: they sometimes shipped empty boxes, without the tube inside. This was due to the way the production line was set up, and people with experience in designing production lines will tell you how difficult it is to have everything happen with timings so precise that every single unit coming out of it is perfect 100% of the time. Small variations in the environment (which can’t be controlled in a cost-effective fashion) mean you must have quality assurance checks smartly distributed across the line so that customers all the way down the supermarket don’t get pissed off and buy someone else’s product instead.

Understanding how important that was, the CEO of the toothpaste factory got the top people in the company together and they decided to start a new project, in which they would hire an external engineering company to solve their empty boxes problem, as their engineering department was already too stretched to take on any extra effort.

The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.

A while later, the CEO decides to have a look at the ROI of the project: amazing results! No empty boxes ever shipped out of the factory after the scales were put in place. Very few customer complaints, and they were gaining market share. “That’s some money well spent!” – he says, before looking closely at the other statistics in the report.

It turns out, the number of defects picked up by the scales was 0 after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the precision scales were installed. A few feet before it, there was a $20 desk fan, blowing the empty boxes out of the belt and into a bin.

“Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.

After reading A Theory Of Fun, I started seeing projects (and many other human activities) modelled as a game. In the book, Raph Koster describes a series of game development rules, and I found that they can be mapped to the software development project domain with some interesting results:

• A project, just like a game, has roles. In projects, they’re specific to each role. These rules define the possible actions for each of them. (This one isn’t described in the book, but I added it just to contextualise.)
• Role-specific rules should be unambiguous, intelligible and apply to all people in that role.
• No project can be developed without the meaningful interaction of the people in all roles.
• The outcome of a project has to be uncertain, otherwise it loses its appeal.
• Rules and representation of a project are not independent but interact with each other.
• People require clear and immediate feedback to understand the relationship between action and outcome.
• People require a clear goal so they can perform meaningful actions within the project world.
• Conflict and competition against time, budget and scope are essential for everyone’s motivation.
• The challenges of a project should match the skills of the people involved: neither too easy (boring) nor too difficult (frustrating).
• Projects can be developed without the need for even skill sets among the team. Instead the people learn through interaction, and this should be allowed and encouraged to happen.
• People perform actions within the project world and observe how these actions change the state of the project.
• People form a hypothesis about the meaning of a deliverable or action on the basis of their studies.
• People recognise and learn fundamental patterns within the project and can apply these to different situations (and, of course, other projects).

The more I look at these, the more this matches the way I see people working in agile projects. I’m sure there’s a lesson to be learned here…

Developers in most projects I have seen try to establish some sort of convention around leaving TODOs in the code. The most common seems to be “if you see something funny, try to fix it immediately, but if it’d take too long and you’ve got something else to worry about, leave a comment next to it starting with TODO, your initials and maybe a date”.

You know what? Using comments for that is not as cool in Ruby, Python or Java, which has had static imports for a while now. How about creating a TODO method that takes in the initials, date and comment text, or whatever else you might find useful?

import static my.project.DevelopmentUtils.TODO;

...

public void doStuffThatSmellsFunny() {
   TODO("CV, 21/jan", "Clean this mess up after fixing #3849");
   ...
}

There are some advantages to this: you can actually put some code inside that method to do, say, logging. Another good thing is that now the TODOs can be tracked using the same refactoring tools and features of modern IDEs as just any other code in the project.

It may seem a bit cumbersome, but I’ve been trying that for a few days now and it feels quite pleasant to use. I got my TODO method to just spit out the message to the console so when I run tests, I can quickly get an idea of what areas of the code touch stinky or incomplete ones.

We’re using Oracle at my current project. I wanted to run some reporting scripts on the database to do some nice graphs with Graphviz and yEd. “Well, that’s been done before, should be pretty easy to hook up ActiveRecord to Oracle”, I thought.

It turns out that’s nearly impossible to do on an Intel Mac running the x86 version of Ruby, since the Oracle Instant Client SDK only ships with PowerPC binaries so far (hence the title). Unless you recompile your whole Ruby install to PPC, something that to me sits somewhere between unspeakable and atrocious, you can’t link to its libraries, as far as I can tell.

But you can get SQLPlus to run on Rosetta. And you can get SQLPlus to spit out reasonably parseable HTML. And it’ll run slow – but for a quick-n-dirty report that you want to generate once every couple of months or so, it’s… ok.

def select_all(sql)
  html = `echo "#{sql};" | sqlplus -r 3 -l -s -m "html on entmap on" #{@user}/#{@password}@#{@host}`
  doc = Hpricot(html)
  (doc/'tr').collect do |tr| 
    (tr/'td').collect do |td|
      td.innerText.strip if td.innerText 
    end if (tr/'td').size == (doc/'tr/th').collect do |th|
      th.innerText.strip if th.innerText
    end.uniq.size
  end.compact
end

Look what you made me do, Oracle. You should be ashamed. As you can see, though, I’m not that easily embarrassed. Some people wouldn’t ever show this code to anyone, and deny its existence at all possible cost. I think it’s worth the shock value, though.

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.