Showing posts with label best practice. Show all posts
Showing posts with label best practice. Show all posts

Wednesday, December 31, 2008

Is estimating a bad practice?

According to Naresh Jain, writing in response to a LinkedIn Agile Alliance discussion, it is:
Estimates are a hang-over from the waterfall world. For the last 6 years, I’ve been very happy and successful building products and delivering projects without all the estimation related ab-ra-ca-dab-ra. No more real-time, ideal-time, story point, function point; non-sense. I’ve realized the key is to focus on the flow of the deliverable and not whether your are delivering according to the estimates.
He goes on to make a pretty compelling case for the abolition of estimates (he provides some useful back-and-forth with his detractors in the comments, too). Since some of our teams have started down the kan-ban path, it would be interesting to know how much of our experience squares with Jain's claims.

Jain also references Joshua Kerievsky's Agile 2008 presentation on the same topic.

Tuesday, December 16, 2008

Pairamid

A few teams at Asynchrony have used pairing charts as a mechanism to help us pair and change pairs frequently so that we gain the benefits of sharing knowledge, widening our understanding of the code, etc. Here's an example of something I call the "pairamid" (pun intended):
In this particular pairing chart, we put a tally for each pairing session, color-coded by day of the week. It serves as a gentle reminder in our war room that we shouldn't let one of the squares have too many more tallies than any other and that person x should try pairing with person y (which we obviously weren't doing very well that iteration!).

Tuesday, October 07, 2008

Finally-close your resources

You are a java programmer. Do you read from databases? Perhaps you write to files? If you aren't careful, you might be creating memory leaks and inadvertently leaving database connections open. Java is notorious for making simple things like file i/o complicated. Consider the try-catch block inside the finally block, which is necessary because the close() method throws an IOException; what is an application programmer supposed to do if the operating system won't allow him to close an open file? Witness the following code:

1 myFile.open();
2 contents = myFile.readContents();
3 myFile.close();
If an exception occurs while reading the file's contents on line 2, your program will skip over line 3 where the file is closed, as the exception interrupts normal execution flow and propagates up the stack, leaving the file ambiguously open. Fortunately, you can invoke this simple solution. Behold:
1 File file = new
File("/shared/home/richard.green/.bashrc");
2 BufferedReader reader = null;
try {
reader = new BufferedReader( new FileReader(file) );
String line = reader.readLine();
// Deal with line
}
catch (IOException e){
// Deal with exception ...
}
finally {
try {
reader.close();
} catch (IOException e) { /* ignored */ }
}
When execution leaves the try block (line 3), code inside the finally block (line 5) is executed under any circumstance. Therefore, in the above solution, if an exception occurs while reading the file's contents on line 3, the file will still be closed on line 5 before the exception propagates up the stack.

Frameworks like Commons IO from the Apache group ( http://commons/apache.org/io) take much of the pain out of dealing with Java I/O. Commons IO provides variety of utility classes which safely implement common I/O operations without dealing with the ugly Java Reader/Stream/Exception semantics.

Resource leaks due to exceptions are a problem in more-or-less every programming language. Each language has its own idioms for dealing with them. C++ coders wrap resources in their own classes and use the language's constructor-destructor semantics to allocate and de-allocate the resource. In Ruby, you use the IO::open method with a block; this automatically closes the resource when the block ends. Familiarize yourself with these idioms as part of learning a new language.

Tuesday, September 23, 2008

Standups and communication

Communication is the first core value of XP. So how does your team communicate with each other? How well do you do it?

One way that our development teams communicate is via daily standup meetings. But what is a standup meeting, anyway? How about this definition: a self-organizing daily gathering to gain shared understanding of the state of our team, focus our day and remind ourselves that we're all in this together. As one comment on Ward Cunningham's wiki puts it, "Our aim is modest: to identify short-term obstacles. The agenda is minimalist: What does the day look like?" Some teams eschew standups because they’re not helpful; perhaps understanding the objectives can help you reshape your standup. How do you know if your standup meetings are effective? Here are some possible outcomes:
  • Everyone knows what he or she is going to do -- and with whom -- as soon as the standup ends (rather than finding a pair partner or figuring out what to do after the meeting ends).
  • Everyone understands where the team is on all the stories -- if an outsider were to ask you about any story, you could answer (rather than merely “the story I'm working on”).
  • Everyone knows high-level problems facing the team for the day (rather than not knowing).
  • Everyone has a sense of how complete the iteration is, and what needs to be done to "make it" (rather than being surprised on the last day).
  • The team has decided to have breakout meetings to resolve specific problems (rather than try to solve bigger problems in the standup).
  • Everyone knows what the team is pledging to accomplish for the day (rather than being unfocused).
If you're not accomplishing these, check out the standups article on Martin Fowler's site, which provides useful patterns and identifies "smells" for standups. Now for some best practices that we’ve seen around Asynchrony:
  • Prompt start: The way a team starts its standup is indicative of the way the day will go; when everyone arrives on-time (or, heaven forbid, a minute early!) the meeting tends to have a snappier pace. Use a fun disincentive to cut down on lateness (e.g., tardy MFKR team members having to wear a PPE jumpsuit).
  • Story-based: Rather than focusing on individual check-ins, the team talks about its progress in terms of stories. Facing the story posters on the board, the team talks about the unfinished stories in order of priority and how to complete them. The team can set a goal by determining which stories it will attempt to finish that day.
  • Know what’s next: Before the standup meeting is over, know who your pair partner is (consult the pairing chart for help) and what task you’re going to work on, and go to it.