Monday:
We started the day by registering, getting our swag bags,
and sitting near a “if it’s your first time” presentation. Nothing terribly useful there. Then at 9:30, we all went to Simple
Design Applied: Spend More Time Creating Valuable Code. The main focus here was on writing code using
simple design. By simple design, we don’t
just mean design that is simple. Instead,
they defined simple design as the following four rules:
1.
All tests must pass
2.
No code is duplicated
3.
Code is self-explanatory
4.
No superfluous parts exist
In the name of
simplicity, the presenters then whittled these four rules down to do, taking
the others kind of as a given:
·
Remove duplication
·
Fix bad names
It was a great reminder of how to think about the code we
create.
Next, we went to Better
Code, Littler Classes: Refactoring to Separate Concerns. In this class, we started with a fairly
simple wiki project that was on flash drives at each table. We worked together through several different
refactorings to make the code easier to understand, having smaller methods and
classes.
Tuesday:
Tuesday morning started slowly, with Bob Martin’s Clean
Code presentation. This is an
always-useful rehash of what Uncle Bob’s been preaching for years. If we’re professional programmers, our code
should be well written, which means something a whole lot different than “it
works”. I’m sure I would benefit from
seeing this talk every year, possibly less.
Uncle Bob’s energy is refreshing and contagious. He also talked about laser pointers, and the
$12 ultraviolet one he got on Amazon.
Next I attended Testing
System Qualities. This was a
thought-provoking session about what aspects of quality we should be testing,
and when. The answers tend towards all
and earlier, respectively. One major
takeaway for me is that we should be doing availability/load testing on much
more than we are, and a way to do so came to me during the session (see
previous email).
Wednesday:
I started the day Wednesday with Does
Pair Programming Have to Suck.
This was a great discussion about some do’s and don’ts in helping people
want to pair. It contributed to one of
the loudest messages that I got from this conference, and that is that you can’t
force agile principles on people. You
can make a personal commitment to follow them yourself and you can work hard to
help others see the benefit, but as soon as you take away someone’s choice, you’re
likely to create a bias and waste all the benefits of agile methodologies. The main message that was intended from this
session is that pairs need to be willing to be vulnerable for pairing to be
most successful. Trust is vital.
Next we had another chance to see Bob Martin in Craftsmanship
or ‘The only way to go fast is to go well’. This was a fantastic new session type where
they have a couch, a chair and a coffee table on a platform in the front of the
room, and, after a brief opening statement from Uncle Bob (for those who don’t
already know, Uncle Bob is Bob Martin), anyone who would like to can go sit on
the couch and have a comfortable chat with Bob about whatever they feel
like. Like most people, I was hoping to find
a magic bullet that I could use to force
people to enjoy the benefits of pairing.
Another person asked my question about this, and Uncle Bob reiterated a
previous message that you can’t force it.
So I decided to take the question to the next step and asked about how
to overcome biases against clean code
in an organization. After some playful “Hi
Bob, I’m Bob.” “Oh nice to meet you Bob.
How’s it going, Bob”, he suggested that a key to making the organization
progress is requiring the results of
professionalism, rather than the mechanisms.
For instance, if a team or person doesn’t want to pair/test
drive/[insert agile practice here], don’t make them. Simply require the results that would come if
they did. At some point, they are bound
to notice that other teams/programmers are able to attain these results, and
will want to find out how they can too.
We ended Wednesday in a fantastic pairing exercise called Hands
on Keyboards! Coding with Corey Haines.
It was here that I learned that a gentleman we had been speaking with
casually somewhat frequently was the Corey Haines. Now Corey is no Bob Martin, but he’s in the
same class. A name that I’ve heard in
many conversations about how to write code and nerdy stuff like that. Matt and Parker were very entertained when I
looked that them and said “That’s Corey Haines!
We’ve been speaking with Corey Haines!”
In the session, we worked to create a Conway’s Game of Life simulation
using pairing and TDD, but with some very uncomfortable restraints: no method
may have more than 4 lines; no method may return anything other than void or this; method calls cannot accept
primitive types or collections; constructors and private methods may take
primitive types. This was probably the
most fun session from the whole conference.
Thursday:
I started with an excellent session called Deliberate
Practice – becoming a better programmer. In this session, I participated in a FizzBuzz
randoori in Java about good names and removing duplication. Then we talked about how to enable developers
to improve themselves through practices like this randoori. A significant takeaway from this session is
that we can and should be doing weekly randoori sessions at
1-800-Contacts. There are certainly
enough developers that would be interested to make this successful. After this session, I had a lengthy chat with
Bill Hanlon of Microsoft. He said that
measuring and reporting on bug lifetimes (the time from bug submission to bug
closure) has been his most useful metric for getting teams to improve overall
quality.
The last session that I saw was again Bob Martin, presenting
Demanding
Technical Excellence and Professionalism. This was mostly a rehash of what he’d said in
the previous two sessions that he did, but was again energizing.
I think the main thing I’ve learned over and over at this
conference is that you can’t force agile on people – you can constantly improve
yourself and you can employ metrics that clearly demonstrate the benefits of
agile practices. Those around you that
are interested in improvement will catch on and join you, if they’re not
forced.
Thanks to all the organizers and presenters, and thanks to 1-800-Contacts for sending me!
