lixo.org

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!