April 2010 Entries
At the end of my visit to 8th Light Justin Martin was kind enough to give me a ride to the train station; for my train back to O’Hare. Just before he left he asked me an interesting question which I then posted to twitter:
Liam McLennan: . @JustinMartinM asked what I think is the most important attributes of craftsmen. I said, "desire to learn and humility". What's yours? 6:25 AM Apr 17th via TweetDeck
several people replied with excellent contributions:
Alex Hung: @liammclennan I think kaizen sums up craftmanship pretty well, which is almost same as yours
Steve Bohlen: @alexhung @liammclennan those are both all about saying "knowing what you don't know and not being afraid to go learn it" (and I agree!)
Matt Roman: @liammclennan @JustinMartinM a tempered compulsion for constant improvement, and an awareness of what needs improving.
Justin Martin: @mattroman @liammclennan a faculty for asking challenging questions, and a persistence to battle through difficult obstacles barring growth
I thought this was an interesting conversation, and I would love to see other people contribute their opinions. My observation is that Alex, Steve, Matt and I seem to have essentially the same answer in different words. It is also interesting to note (as Alex pointed out) that these definitions are very similar to Alt.NET and the lean concept of kaizen.
Over the past twelve months I have been thinking a lot about executable specifications. Long considered the holy grail of agile software development, executable specifications means expressing a program’s functionality in a way that is both readable by the customer and computer verifiable in an automatic, repeatable way. With the current generation of BDD and ATDD tools executable specifications seem finally within the reach of a significant percentage of the development community.
Lately, and partly as a result of my craftsmanship tour, I have decided that soon I am going to have to get a job (gasp!). As Dave Hoover describes in Apprenticeship Patters, “you … have mentors and kindred spirits that you meet with periodically, [but] when it comes to developing software, you work alone.” The time may have come where the only way for me to feel satisfied and enriched by my work is to seek out a work environment where I can work with people smarter and more knowledgeable than myself.
Having been on both sides of the interview desk many times I know how difficult and unreliable the process can be. Therefore, I am proposing the idea of executable resumes. As a journeyman programmer looking for a fruitful work environment I plan to write an application that demonstrates my understanding of the state of the art. Potential employers can download, view and execute my executable resume and judge wether my aesthetic sensibility matches their own. The concept of the executable resume is based upon the following assertion:
A line of code answers a thousand interview questions
Asking people about their experiences and skills is not a direct way of assessing their value to your organisation. Often it simple assesses their ability to mislead an interviewer. An executable resume demonstrates:
- The highest quality code that the person is able to produce.
- That the person is sufficiently motivated to produce something of value in their own time.
- That the person loves their craft.
The idea of publishing a program to demonstrate a developer’s skills comes from Rob Conery, who suggested that each developer should build their own blog engine since it is the public representation of their level of mastery. Rob said:
Luke had to build his own lightsaber – geeks should have to build their own blogs. And that should be their resume.
In honour of Rob’s inspiration I plan to build a blog engine as my executable resume. While it is true that the world does not need another blog engine it is as good a project as any, it is a well understood domain, and I have not found an existing blog engine that I like.
Executable resumes fit well with the software craftsmanship metaphor. It is not difficult to imagine that under the guild system master craftsmen may have accepted journeymen based on the quality of the work they had produced in the past.
We now understand that when it comes to the functionality of an application that code is the final arbiter. Why not apply the same rule to hiring?
Thursday morning the Illinois public transport system came through for me again. I took the Metra train north from Union Station (which was seething with inbound commuters) to Prairie Crossing (Libertyville). At Prairie Crossing I met Paul and Justin from 8th Light and then Justin drove us to the office. The 8th Light office is in an small business park, in a semi-rural area, surrounded by ponds. Upstairs there are two spacious, open areas for developers.
At one end of the floor is Doug Bradbury’s walk-and-code station; a treadmill with a desk and computer so that a developer can get exercise at work. At the other end of the floor is a hammock. This irregular office furniture is indicative of the 8th Light philosophy, to pursue excellence without being limited by conventional wisdom.
8th Light have a wall covered in posters, each illustrating one person’s software craftsmanship journey. The posters are a fascinating visualisation of the similarities and differences between each of our progressions. The first thing I did Thursday morning was to create my own poster and add it to the wall.
Over two days at 8th Light I did some pairing with the 8th Lighters and we shared thoughts on software development. I am not accustomed to such a progressive and enlightened environment and I found the experience inspirational. At 8th Light TDD, clean code, pairing and kaizen are deeply ingrained in the culture.
Friday, during lunch, 8th Light hosted a ‘lunch and learn’ event. Paul Pagel lead us through a coding exercise using micro-pomodori. We worked in pairs, focusing on the pedagogy of pair programming and TDD.
After lunch I recorded this interview with Paul Pagel and Justin Martin. We discussed 8th light, craftsmanship, apprenticeships and the limelight framework.
Interview with Paul Pagel and Justin Martin
My time at Didit, Obtiva and 8th Light has convinced me that I need to give up some of my independence and go back to working in a team. Craftsmen advance their skills by learning from each other, and I can’t do that working at home by myself. The challenge is finding the right team, and becoming a part of it.
I like Chicago. It is a great city for travellers. From the moment I got off the plane at O’Hare everything was easy. I took the train to ‘the Loop’ and walked around the corner to my hotel, Hotel Blake on Dearborn St. Sadly, the elevated train lines in downtown Chicago remind me of ‘Shall We Dance’.
Hotel Blake is excellent (except for the breakfast) and the concierge directed me to a pizza place called Lou Malnati's for Chicago style deep-dish pizza. Lou Malnati’s would be a great place to go with a group of friends. I felt strange dining there by myself, but the food and service were excellent. As usual in the United States the portion was so large that I could not finish it, but oh how I tried.
Dave Hoover, who invited me to Obtiva for the day, had asked me to arrive at 9:45am. I was up early and had some time to kill so I stopped at the Willis Tower, since it was on my way to the office. Willis Tower is 1,451 feet (442 m) tall and has an observation deck at the top. Around the observation deck are a set of acrylic boxes, protruding from the side of the building. Brave soles can walk out on the perspex and look between their feet all the way down to the street. It is unnerving.
Obtiva is a progressive, craftsmanship-focused software development company in downtown Chicago. Dave even wrote a book, Apprenticeship Patterns, that provides a catalogue of patterns to assist aspiring software craftsmen to achieve their goals. I spent the morning working in Obtiva’s software studio, an open xp-style office that houses Obtiva’s in-house development team.
For lunch Dave Hoover, Corey Haines, Cory Foy and I went to a local Greek restaurant (not Dancing Zorbas). Dave, Corey and Cory are three smart and motivated guys and I found their ideas enlightening. It was especially great to chat with Corey Haines since he was the inspiration for my craftsmanship tour in the first place.
After lunch I recorded a brief interview with Dave. Unfortunately, the battery in my camera went flat so I missed recording some interesting stuff.
Interview with Dave Hoover
In the evening Obtiva hosted an rspec hackfest with David Chelimsky and others. This was an excellent opportunity to be around some of the very best ruby programmers. At 10pm I went back to my hotel to get some rest before my train north the next morning.
While I was in the New York area Stephen Bohlen graciously organised an Alt.NET dinner. I left Rockville Centre on the 17:15 train, thinking I had plenty of time to get to Toloache Mexican Bistro on W 50th St. However, when I changed at Penn Station I took the service downtown, instead of uptown. I corrected that mistake and made it to 51st St, but then ended up in completely the wrong place because I did not understand the street numbering system. For future reference I now have the following rules for NYC navigation:
- Uptown means North, Downtown means South
- Streets run East-West, Avenues North-South
- Street number are symmetrical on the 5th Avenue axis. That is, street numbers increase from zero both east and west of 5th Av.
Having gotten totally confused I called Steve, who helped me find the restaurant. I still had my luggage, which we stowed in a corner. Over some descent Mexican food we had some great discussions about Alt.NET, the 2010 conference, and other things of interest to Alt.NET folks.
Thanks to Steve for organising and to all the guys who turned up.
Arriving at JFK, at dawn, is beautiful.
From above 1,000ft I can see no crime, poverty or ugliness – just the dark orange sunrise-through-smog.
The Atlantic appears calm, and I take that as a good sign.
Today is the first day of my software craftsmanship tour. I will be visiting three of the shining lights of the software industry over five days, exchanging ideas and learning. Arriving on the red eye from Seattle I feel like hell. My lips, not used to the dry air, are cracked and bleeding. I get changed in the JFK restroom and make my way from the airport. Following Rik’s directions I take the airtrain to Jamaica. Rik is an engineering manager at Didit in Long Island, the first stop on my tour. From Jamaica I take the Long Island Rail Road train to Rockville Centre, home of Didit.
The refactoring I’m talking about is recommended by resharper when it sees a lambda that consists entirely of a method call that is passed the object that is the parameter to the lambda. Here is an example:
public class IWishIWasAScriptingLanguage
{
public void SoIWouldntNeedAllThisJunk()
{
(new List<int> {1, 2, 3, 4}).Select(n => IsEven(n));
}
private bool IsEven(int number)
{
return number%2 == 0;
}
}When resharper gets to n => IsEven(n) it underlines the lambda with a green squiggly telling me that the code can be replaced with a method group. If I apply the refactoring the code becomes:
public class IWishIWasAScriptingLanguage
{
public void SoIWouldntNeedAllThisJunk()
{
(new List<int> {1, 2, 3, 4}).Select(IsEven);
}
private bool IsEven(int number)
{
return number%2 == 0;
}
}The method group syntax implies that the lambda’s parameter is the same as the IsEven method’s parameter. So a readable, explicit syntax has been replaced with an obfuscated, implicit syntax. That is why the method group refactoring is evil.
Talking about GIT
Closing circle
One of this morning’s sessions at Alt.NET 2010 discussed BDD. Charlie Pool expressed the opinion, which I have heard many times, that BDD is just a description of TDD done properly.
For me, the core principles of BDD are:
- expressing behaviour in terms that show the value to the system actors
- Expressing behaviours / scenarios in a format that clearly separates the context, the action and the observations.
If we go back to Kent Beck’s TDD book neither of these elements are mentioned as being core to TDD. BDD is an evolution of TDD. It is a specialisation of TDD, but it is not the same as TDD. Discussing BDD, and building specialised tools for BDD, is valuable even though the difference between BDD and TDD is subtle. Further, the existence of BDD does not mean that TDD is obsolete or invalidated.
Sinatra is a Ruby DSL for building web applications. It is distinguished from its peers by its minimalism. Here is hello world in Sinatra:
require 'rubygems'
require 'sinatra'
get '/hi' do
"Hello World!"
end
A haml view is rendered by:
def '/'
haml :name_of_your_view
end
Haml is also new to me. It is a ruby-based view engine that uses significant white space to avoid having to close tags. A hello world web page in haml might look like:
%html
%head
%title Hello World
%body
%div Hello World
You see how the structure is communicated using indentation instead of opening and closing tags. It makes views more concise and easier to read.
Based on my syntax highlighter for Gherkin I have started to build a sinatra web application that publishes syntax highlighted gherkin feature files. I have found that there is a need to have features online so that customers can access them, and so that they can be linked to project management tools like Jira, Mingle, trac etc.
The first thing I want my application to be able to do is display a list of the features that it knows about. This will happen when a user requests the root of the application. Here is my sinatra handler:
get '/' do
feature_service = Finding::FeatureService.new(Finding::FeatureFileFinder.new, Finding::FeatureReader.new)
@features = feature_service.features(settings.feature_path, settings.feature_extensions)
haml :index
end
The handler and the view are in the same scope so the @features variable will be available in the view. This is the same way that rails passes data between actions and views. The view to render the result is:
%h2 Features
%ul
- @features.each do |feature|
%li
%a{:href => "/feature/#{feature.name}"}= feature.nameClearly this is not a complete web page. I am using a layout to provide the basic html page structure. This view renders an <li> for each feature, with a link to /feature/#{feature.name}. Here is what the page looks like:
When the user clicks on one of the links I want to display the contents of that feature file. The required handler is:
get '/feature/:feature' do
@feature_name = params[:feature]
feature_service = Finding::FeatureService.new(Finding::FeatureFileFinder.new, Finding::FeatureReader.new)
# TODO replace with feature_service.feature(name)
@feature = feature_service.features(settings.feature_path, settings.feature_extensions).find do |feature|
feature.name == @feature_name
end
haml :feature
endand the view:
%h2= @feature.name
%pre{:class => "brush: gherkin"}= @feature.description
%div= partial :_back_to_index
%script{:type => "text/javascript", :src => "/scripts/shCore.js"}
%script{:type => "text/javascript", :src => "/scripts/shBrushGherkin.js"}
%script{:type => "text/javascript" } SyntaxHighlighter.all();
Now when I click on the Search link I get a nicely formatted feature file:
If you would like see the full source it is available on bitbucket.