Nesta quarta-feira aconteceu mais uma reunião do grupo TaSafo, em Belém do Pará. Foi um prazer poder re-encontrar antigos amigos e conhecer pessoalmente os responsáveis por movimentar a comunidade Paraense de desenvolvimento.

O encontro foi composto por duas apresentações, seguidas da ‘Hora do Desapego’.

Meu amigo Mateus Linhares falou sobre sua experiência implantando práticas e métodos ágeis no Ikwa.

Eu falei sobre ‘Comunidades Dinamicamente Tipadas’.

In our most recent Coding Dojo session here in Orlando I realized something really interesting about our team’s velocity. I feel like other people doing Coding Dojos may have realized this as well, so I’ll try and put it into words properly.

Briefly, below is how we run our sessions:

Planning

The Coding Dojo session starts with an initial planning involving the problem we picked. Stand up style, focused on early results and the-simplest-thing-that-could-possibly-work kinda features. We usually take about 10 minutes and write down some things on the board.

Our goal at the planning is to set up expectations. Everyone involved in the planning gets to make suggestions (add/remove/renegotiate goals). We also decide on an initial design (classes, methods, test cases, etc.).

Coding

We start coding, 7 minutes a pair, and try not to have too many interruptions. Everyone gets a shot and this usually takes us from 40 to 50 minutes, depending on the number of people attending.

Half-time

Coding stops and we talk about what we have done so far.

A little retrospective about the code and how close/far we are from our initial expectations. If we think we can add things, we usually do. Maybe we think we should replace things, or even remove some.

More coding

Another round of test-driven development with a 7 minute pairing cycle.

Done coding

Once everyone gets a shot, that’s it.

We avoid making further changes once the last 7 minutes has been over with.

Retrospective

The way we do this is as a both technical and social retrospective. Usually ends up being pretty much social. We talk about things that worked well and things that need improvement.

Velocity

On a real life project, back on the planning meeting, setting up expectations usually involves making estimates.

Most agile teams agree on estimating using story points rather than hours. I see this as a valid approach, mostly because you get to let each member of the team make their own point <-> time association.

Velocity does not mean productivity, thus, greater velocity does not mean greater productivity. The focus here is consistency.

Consistency is knowing that every [S, a time-scope ] you have potentially shippable software, with additional business value to the product.

The question during planning should be something along the lines of:

“Out of all of these things that the team agreed on being delivered by the end of the iteration, how much of each should we be able to have ?”

Then, try and settle on the simplest thing that could resemble what the client has in mind. You still have room to impress him with something really cool - and by cool I mean simple.

By the end of the iteration, when the team should be about done with the things they estimated, the client should be seeing and using the software.

Even when I write code for fun, I like to set clear goals based on my velocity. For things that are still unclear, or if I’m not familiar with some technology involved, I reduce my scope and try to extract the first thing that would made me simply go “oh, that’s cool.”

The client, on the other hand, should be worried about the first thing that goes “$” (is there a sound for money?).

By reducing the scope with a client, we’re also reducing the time the client spends thinking about features he will probably never need.

We could tell him “YAGNI !!”.

That would sound totally extra-terrestrial, but totally awesome.

Learning your velocity

Since the people attending the Orlando Coding Dojo have been pretty much the same lately, with a few variations, we’ve been able to meet our expectations and always end the session with tests passing and working software.

It wasn’t always like this, though.

In the first few sessions we had no idea of how much work we were able to accomplish as a team. We would end our sessions kinda frustrated, because we weren’t able to meet our expectations.

The same thing happens with other Coding Dojo groups who are just getting started and also with agile teams in the first few iterations on real life projects.

Even without writing down estimates (in points or hours), but because we are constantly planning and running retrospectives to improve our process, we are becoming more familiar with our actual velocity.

This means we are able to have about 6-9 people, who don’t even work professionally on the same technology, agreeing on something and getting it done in about 2 hours. I find this fantastic!

Software development is a continuous learning process. Learning your team’s velocity (and your own velocity when you go solo), enables you to deliver early, deliver often and deliver always.

Here is the slides for the Refactoring talk I did last Thursday at the Orlando Ruby User Group meeting. In case you want to hear me speaking along with the slides, I’ve put it up on vcasmo also.

So you’ve probably heard of ZenTest/Autotest, right?

In case you haven’t, it is a Ruby gem that (among other things) automatically runs your tests whenever it notices that a file in you project has changed. It’s a great productivity boost, because it saves you from having to run your tests each time you make a change to your program. The perfect tool if you are doing TDD.

So I wanted to get this autotest functionality going for projects in other languages - like PHP, for example - but apparently ZenTest/Autotest only works within Ruby projects.

Talking to the EnvyLabs’ guys I was told about Watchr, a Ruby gem that monitors files matched by a regular expression and triggers a user defined command whenever a file changes. That’s enough to get you started in an autotest-like tool for PHP - or just about any other language.

I’ve setup an example PHP project of Watchr playing an autotest role in a PHP project:

View on Vimeo.

The source code from this example can be seen at http://github.com/caike/watchr_running_php

Software developers read a lot more code than they actually write. An application source code is nothing but a story written using a specific language. It has state and describes behaviour.

Code written once, will be read millions of times. For the most part, it will be read by a compiler who doesn’t really look for anything but correct syntax. Compilers are not into reading stories. They are too busy for that. Just like assembly-line workers, they follow a plan and do exactly what they were told. As soon as they pass things over to the runtime, they are done. On the other hand, we developers are not like that, are we ? No, we are not!

We are software craftsmen. We like to read stories and even get paid to write some every once in a while.

http://www.flickr.com/photos/dhammza/91435718/

Think about it the next time you hack that magic one-liner in an application. Do you think you will be able to read that code-golf champion piece of code the next time you look at it ? What if it is not you, but someone else reading it ?

“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live (…) Alternatively, always code and comment in such a way that if someone a few notches junior picks up the code, they will take pleasure in reading and learning from it.” - Ward Cunningham, CodeForTheMaintainer

An example I like to use for expressive code is method parameters in Ruby. Let’s say you want to stay fit and write a method to calculate a body fat percentage. You write the following:

def body_fat_percentage(name, age, height, weight, metric_system)
end

Apparently it looks nice. Let’s see how it could be invoked:

# fred's height in meters and weight in kilograms
body_fat_percentage("fred", 30, 1.82, 90, 1)

# barney's height in feet and weight in pounds
body_fat_percentage("barney", 32, 5, 300, 2)

In order to write those two calls you would probably have to check the right order for the parameters in the method’s signature. Even worse, every time you read that line you would have to check back its signature just to make sure that the last argument determines the metric system or that the third argument is actually the height and not the weight.

That sounds like a pretty boring story to read!

Let’s make this piece of code more expressive:

# fred's height in meters and weight in kilograms
body_fat_percentage("fred", :age => 30, :height => 1.82,
  :weight => 90, :metric_system => MetricSystem::METERS_KG)

# barney's height in feet and weight in pounds
body_fat_percentage("barney", :age => 32, :height => 5,
:weight => 300, :metric_system => MetricSystem::FEET_LB)

All we need to do to the method signature is to replace the standalone arguments for a hash.

def body_fat_percentage(name, params={})
end

From the method body, the values can be accessed using the keys, like params[:age], params[:height], etc.

In a real life situation, this expressiveness would be achieved from writing our expectations as unit tests. We would first write our failing tests as how we wanted our code to look and act like. From that, we would head towards making the tests pass. When all is green, the tests would turn out to be the reference for how to call the method (running and never-obsolete documentation) so there’s no need to go back to the implementation of the method itself to learn how to to use it.

Writing expressive code often means writing more code, but it also means writing better code. It’s not about making things work, it’s about making things right.