Many people tried different ways to define what “done” means in a software project (as you can see here, here and here). My experience, however, is making me believe that the problem may be in the word itself. Saying something is “done” always creates different expectations depending on who we’re talking to. And having to create a specific definition for a word means it will only be valid for the people who agree on it, and as long as they remember it.
The solution? Well, maybe we should simply be using a different word(s). For instance, my gut feeling is that “ready” could probably do a better job. The main reason is that it invites further questions (“ready for what?”), whereas done ceases the communication (“if it’s done, let’s move on.”).
On October I’ll have another great reason to travel: running a coding dojo at the Latin-American Conference on Agile Development Methodologies (or simply Ágiles2009). And if having an event like that in back in Brazil wasn’t good enough, the conference will be in Florianópolis, the city where I studied and used to work before moving to London. How cool is that?
For this session, it seems like once more the challenge will be how to prepare a session for more people than we’re used to. So Victor Hugo and I still have to come up with something special for this occasion.
Anyway, If you’re lucky enough to be around at the conference, please don’t hesitate and come say hi 
After working with stand-up meetings for a while I feel that this practice acts like a thermometer for an agile team. As a constant status report, it demonstrates how most of the other practices are being applied and how good is the team communication in general.
That’s why I believe is important to be conscious about what happens during them. A stand-up meeting may hide problems if:
- It doesn’t have an exact time to start
- It doesn’t happen because someone is not present
- It’s a trigger for technical discussions
- It’s not focused on to the plan
- It doesn’t contribute to continuous improvement
- It’s a report for a single person, not the team
- People don’t stay close to each other
- It’s frequently interrupted
- It doesn’t include the whole team
- People don’t remember what they did on the last day
- It’s moment where most of the problems are raised
- It takes more than 15 minutes
- It doesn’t happen every day
- It doesn’t feel good
These are all simple issues which can easily be addressed. In fact, most of the items on this list are discussed on Jason Yip’s article about stand-up patterns. The most important thing is that it may as well be the a good starting point to identify and improve other aspects of a project.
On the last April’s fool, Philip Calcado announced that ThoughtWorks was about to start an office in Brazil. At few months later and this message on Martin Fowler’s twitter proves the affirmation was not that far from reality:
“My colleague Sid Pinney is investigating setting up a ThoughtWorks office in Brazil – talk to him at [...]“
The interesting thing about this is not the fact itself, but the reaction it’s causing. Not only dozens of Brazilian developers are forwarding the message, but there are people already asking how they can join the company.
The biggest strength of TW is their ability to attract good developers by having on their staff people who influence the whole software development community. In my opinion that’s the result of a good recruitment process and giving opportunity for employees to publish and work on their own projects.
I really hope they open a company there because, as far as I know, very few companies have this kind of culture in Brazil. Open a company there and they can probably have the best developers around.
The following parable has made me think about the different views on the software development work:
A traveler came across three individuals working with stones. When asked about what he was doing, the first one replied, “I’m a stone cutter. I cut stones because I need the money to support my family“. The traveler then decided to ask the second worker, who answered, “I’m a great stone cutter. I can use all my techniques to produce the best shaped stone“. Surprised by the two distinct responses, the traveler finally asks the third man what he was doing. The worker stopped for a moment and then said, “I’m a stone cutter and I’m building a cathedral” .
Sometimes I have this feeling that we as professionals are frequently trying to be more like the second stone cutter than the the third one. Am I the only one?
The next coding dojo will happen on the 4th June (Thursday) at the Skillsmatter office. The registrations are already open.
For this session we’ll work on the Minesweeper challenge in Ruby once more, but this time with the Randori rules slightly changed:
- A pair will work on the solution for 10 minutes
- The pair must use Test-Driven Development and Baby Steps all the time
- The pair must follow the Ping Pong approach:
- One person writes a failing test
- The other person makes the test pass writing a minimum amount of code
- The same person writes the next failing test
- After 10 minutes one of the developers switches place with someone from the audience
Who attended the dojo before knows the minesweeper problem was solved a few times before, but trust me, it doesn’t matter. The idea of this session is focus more on the pair communication rather than the technical challenge. And if you never tried Ping Pong programming, it will be a good chance to experience one of the most enjoyable forms of pair programming.
See you there!
This Wednesday (April 22nd) we’ll have another coding dojo at Skillsmatter. This time the challenge will be the Poker Hands:
[...] Your job is to compare several pairs of poker hands and to indicate which, if either, has a higher rank.
Here’s some initial code generated at a previous dojo that may serve as starting point for the solution. The session format will be a Randori, which means everyone is welcome to code.
As usual, registration is required and should be done at Skillsmatter’s website. If you have any questions or suggestions for this session please feel free to participate in the Coding Dojo London mailing list.
Reading Mark Needham’s post about how inexpressive an API can be when using booleans in method parameters, another clear example came to my mind.
A few weeks ago we were using a method similar to the following:
public List listUsers(boolean showDisabled);
We’d expect that once you call this method passing false, it would return all enabled users and if the parameter is true it included all the disabled users in this list, right? Well, not exactly.
Only when we tried passing true we discovered it actually listed ONLY the disabled users. And unfortunately it was simply impossible to predict this behavior by reading the interface.
What if we used a better representation for this boolean instead?
public enum UserFilter {
ENABLED_ONLY, DISABLED_ONLY;
}And the interface now would look like:
public List listUsers(UserFilter filter);
Notice that I didn’t change any behavior, but now it’s clear what this method call will return:
myUsers = service.listUsers(UserFilter.ENABLED_ONLY);
Besides, if we were really interested in having a list including ALL the users, we could easily extend the filter without having to change the original method or loosing in readability.
The problem with booleans is that they are intentionally inexpressive. They are an essential part of our code when it comes to evaluate conditions and control the flow of execution, but when it comes to define domain-specific concepts, my gut feeling says in most cases they should be avoided.
Is it just me who’s loving this whole Ruby vs. Scala debate going on lately? So far it shows that:
- No language can prevent bad code.
- There will be never an ultimate language, but there will always be people to defend the one they are using.
- Java (the language, not the platform) is dead.
I know it’s not the first time we have a language war and I have to confess I was missing that a little. Years ago it was Visual Basic vs. Delphi, then C++ vs Java, now it’s Ruby vs. Scala. And I have to confess: I’m already curious to see what will be the next one.
For this dojo, instead of working on a challenge from scratch, we’ll start from an existing solution and try to improve it.
The starting point will be the Minesweeper implementation created on a previous coding dojo. It contains only 272 lines of Java code (source + tests) and a lot of room for improvement.
Some guidelines for the session:
- Two programmers will work on the code for 7 minutes. After this period, one of them switch his place with someone from the audience.
- The pair decides their next step and make sure the audience understand what they’re doing. Discussion with the audience is acceptable, but the final word is always from the pair.
- The pair should follow the 3 Rules of TDD:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
- At the end there will be a retrospective to identify all the lessons learned.
This coding dojo will take place on the 25th March and to participate you need to register at the session page on the Skillsmatter website. If you want to start playing with the code now, it can be downloaded here.
See you there!