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.
Work Agile
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.
Work ThoughtWorks
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?
Work Craftsmanship
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!
Work Coding Dojo, Ruby
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.
Work Coding Dojo, Ruby
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.
Work Programming
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.
Work Java, Programming, Ruby
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!
Work Coding Dojo
We had some years to digest the Agile Manifesto. Now it seems like the next step is being defined in the Software Craftsmanship Manifesto:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
We’ve been learning to produce better software for a long time so it seems natural to start asking ourselves to be more responsible about what and how we deliver it.
Work Agile, Craftsmanship
One of the highlights of the Software Craftsmanship Conference 2009 came from outside the original programme. Someone had the excellent idea of proposing the following topic for an open space session: “Why I hate frameworks”. It was enough to get my attention and before I realised the room was so full that people had to sit on the floor to be able to participate.
The discussion obviously started with frameworks for Java. It seems everyone agrees that the enterprise culture of Java introduced a huge amount of tools many developers can’t live without even though their actual benefits are at least questionable. The next question then was whether developers should be so dependent on such tools.
On one side they allow them to think on an higher level of abstraction and follow standards shared by many other professionals. As consequence it becomes easier to find people to work on these projects, specially if the most popular frameworks were chosen.
On the other hand, this approach produces a great number of programmers who only know how to work with those specific tools without even understanding the problems that are actually being solved. Then it becomes harder and harder to evaluate if a framework make people produce more and better.
A point most people agreed is that in some cases frameworks just move the complexity from one place to another, and the productivity at the end doesn’t pay off. And in many cases when people start facing the problems brought by a framework it’s normally at a stage where abandonning it means almost recreating the whole system from scratch.
The fact that many projects are trapped by frameworks brought up the question whether developers should be looking for libraries instead. It seems there’s a lack of libraries because people prefer to develop their solutions integrated to frameworks and then reach a bigger community instead of just solving a problem in isolation and letting programmers mix and match tools to use.
At the end of the session there was no real conclusion on how justifiable is the hate towards framework. Instead, there was a common sentiment that programmers should be more responsible when choosing frameworks. And maybe a clear list of problems they are solving and comparing them with the new challenges they bring may be a good starting point.
Work Craftsmanship, Programming