Fred George has broken developers into three broad groups of apprentices, journeymen, and masters. Based on this classification our team is moving from apprentice to journeymen currently.

He defines apprentice level programmers as:

An apprentice in OOP is a effective programmer and can construct loops, methods, and classes, but is still learning how to separate the business problem into objects. Encapsulation is being learned (which means no getters or setters for the classes). Code is being placed into the appropriate classes rather in giant god class. if statements litter the code as the apprentice is still learning design patterns to eliminate them. Class sizes and method sizes tend to be larger than smaller. Code requires comments to aid in understanding, and blank lines are common in the middle of methods to group code together. An apprentice is beginning to understand the patterns of bad code (the imfamous code smells), but lacks the tools to understand how to eliminate them.

Some of our developers are still dealing with this level, especially considering object oriented concepts can take a while to bake in. Lots of if statements in some code is still a sign that we have a ways to go. The blank lines in the middle of methods are great visual clues that a developer still needs some help refactoring.

Journeymen are defined as:

The journeyman is adept in OOP techniques. The classes exhibit crisp conceptualizations distinguishing them from each other. Boundaries are clear; methods are small. Design patterns are common, and exist in inverse proportion to the number of if statements. else statements are quite infrequent, and case statements have vanished. (I write about one case statement every 18 months or so.) Given a problem and a broad outline of a design, journeymen will implement it with little need for supervision or support.

When I see the rare if statement in a code review it will be a happy day.

Sacramento’s Ruby community is beginning to organize for regular meetings. Our first meeting about three months ago was more of a introduction and chat session. Several members had been to Rails Conf 2007 and had plenty to talk about.

We met again at Invision in Old Sacramento and talked about some organizational items:

• Ryan is acting as our organizer and we’re glad to have his energy in the role.
• Starting up regular monthly meetings. Looks like we’ll vote on the Google groups mailing list and the first Tuesday or Thursday of the month will be the candidates.
• Meetings will be held at Invision as Old Sacramento is reasonably central to where everyone comes from.
• We should have some short talks next time. One on the newer version of Capistrano and one on RSpec by myself. There was also a Django developer there who may do a talk on comparing current Rails and Django.
• People were interested in hearing from Mike Culver on Amazon web services so I’ll try to contact him about scheduling a talk.

We also grew our second meeting from four to five people so we’re a bustling community.

I was testing a method that did some validation of a 2 character state. It’s legacy code, very few tests so I’m learning about how the code really works as I go along. I was writing a test for the following line:

else if (!BasicUtils.isState(state.trim()))

I wrote a test set the state property to “AA” and asserted that the validation failed. Problem was the validation passed and the test failed. OK, I found a weird defect. I took a bit of digging through layers until I got to the EJB layer where I found my answer:

stateValue.add("Armed Forces the Americas");
state.add("AA");

Turns out “AA” is a valid state code defined by the US Post Office.

When you do Agile development you really need good people otherwise things won’t work. And my answer is have you ever seen a waterfall project delivering good software by putting baboons on it and giving them bananas.

This average thing is completely wrong. To produce software you anyway need good developers no matter what. You choose whatever methodology you want you are not going to deliver anything.

— Giovanni Asproni

Scrum – Getting Started without Getting Burned

At the end of the day the best predictor of any project success is the people. Scrum can help good people work better, but you actually need the good people or you need to grow them.

We’re still using Fitnesse and its coming in quite handy for testing over 100 edits on some code we inherited. I still wonder how much it will catch on. Jeremey Miller has been thinking along the same lines:

Long term, all the testing gurus I know of seem to be driving towards scripting tests in Ruby and I’m thinking of moving in that direction in the future. I’ll still use Fit tests for set-based logic where it excels, but otherwise it just seems, I don’t know, clunky.

What do you guys think? Does Fit have a future, or is it just a little blip that’s never really going to take off?

I think FIT/Fitnesse gets a lot less use than your average JUnit framework, but the download numbers suggest Fitnesse is catching on:

• fitnesse20070619.zip 2551
• fitnesse20060719.zip 78608
• fitnesse20050731.zip 17551

The numbers for the 2006 version show some real promise. Hopefully the idea of automating acceptance tests is becoming a more widespread practice.