Software Craftsmanship North America Conference

27 Aug 2009

This was the first ever Software Craftsmanship conference and it was put on by my company Obtiva and 8th Light (a company I have pretty strong ties to). It was a pretty big day for the Craftsmanship movement and our little companies.

Software Craftsmanship Manifesto is:

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.

The idea is to build on the Agile Manifesto toward better software and the community that surrounds it.

Swimming Upstream, Sprouting Legs, and Running Free – Ken Auer

This is by far the most provoking talk I’ve heard in awhile. At the beginning Ken announced that he wasn’t going to be politically correct. And as the talk went on I kept wondering what that was going to be. Would he go after women drivers, Mexicans, president Obama…? I kept waiting for the other shoe to drop.

Ken had a fairly happy childhood where he desperately wanted to be a baseball player. But, alas, that dream doesn’t often come true. But he was good at math so he played a lot of “Strat-O-Matic Baseball” which is a game where you use the stats of baseball players. He developed a series of algorithms so that he could beat all his friends. This, of course, lead to a career in computers.

The other theme in Ken’s life is religion. This, apparently, is ‘not politically correct’ part of the talk. I gotta say that it’s takes a lot of chutzpah to talk about religion at a software development conference. I have never heard somebody say “Do you accept Jesus Christ as your personal saviour?” at any conference before, but I have now.

Ken attended church all throughout childhood going there “whenever the doors were open.” But he feels that he was sort of passively religious during that time. He didn’t know much about the bible or question any of the church’s practices.

In Ken’s software life he had his eyes opened by the Object Oriented revolution when he attended the first ever OOPSLA in 1986. He and his company got into OO and Smalltalk very early on and produced a bunch of working software before anyone could tell them that Smalltalk wasn’t for ‘real’ software. It’s funny how often people succeed because they didn’t know it was supposed to be hard.

Also, around this time, Ken started attending Bible study groups and thinking more about his work/life balance. He spent a few years ruminating about how to affect a change and eventually came up with the idea that he would start his own company “Role Model Software.” Over the years Ken has:

Ken seems pretty happy with the current of his life. He’s managed to combine a bunch of the formerly separate aspects of his life into one unified whole.

Late in Ken’s presentation he ran out of time and had to skip past a bunch of slides (I think I saw Darwin in there somewhere) and wound up with a slide that said “I don’t believe we came out of the mire. But we need to.” Which I take to mean that he doesn’t believe in Evolution but that he feels that our current software situation is a bit of a mess and needs to be changed.

Again, easily the most provoking conference presentation I’ve ever seen.

Self Eduction and the Craftsman - Michael Feathers

Michael’s talk was mostly a list of things he thought that people who were self taught or apprenticed might not have learned (because they weren’t in a formal Computer Science program).

Things you need to know about:

Books that you might not have read:
Structure and Interpretation of Computer Programs
“Designing Object Systems” Cook and Daniels (Syntropy)
“Graphs: Theory and Algorithms” Swamy (Graph Theory)
“Compilers” Aho, Sethi, Ullman (The Dragon Book)
Discrete Mathematics - Anderson
Theory of computation - Michael Sipser

Observations from an Old Warhorse - Fred George

This talk, by the highly engaging Fred George, was a series of completely unrelated observations from a guy who’s done a lot of Agile and non-Agile projects.

What is considered a big application?
1970 - 10K Lines
1980 - 100K
1990 - 1M
2000 - 10M
2010 - 100M

But effort seems to rise and fall to build big applications because we keep getting advances in writing software and all advances have this in common: Simplify the problem. Get rid of duplication.

Discard to Make Languages more Robust:
goto
Tektronics School of Objects: ‘if’ is suspicious ‘else’ is almost always wrong.

I’ve heard this ‘If/Else’ claim before but without any examples, it’s hard to understand how to purge my code of all the ‘Else’s.

(Rails - TDD) == Productive VB
If application is less than a page of code would you..
- write tests?
- pair?

Fred doesn’t write test or pair on micro projects.

Feedback => Quality
1. Frequent releases
2. iterations
3. Stand ups
4. Tasking Cycle 1-2 hours (all the way through a story in 1-2 hours? This guy is big into Lean.)
5. Pair Programming

Lean: Identify and Eliminate Waste
What are you making?
How do you make it faster

Story life cycle.
Finger charts are useful.

Iterations are dead
From scrum’s couple of months
to xp’s 2-3 weeks
to ThoughtWorks 1 week
to Daily (part of the stand up)

Fred uses a Kanban board to track stories in progress.

Developers pick up the most important thing next. If management wants to have a meeting – let them.

Continuous Deployment

Holy Grail of Software Development: Short lead times

Right now on Fred’s team: Over 50% of stories are deployed within 2 days of the story surfacing. Which reduces the need for branching.

Grand Unified Theory of Software Design – Jim Weirich

This was an interesting attempt to find a unifying principle underlying all software principles (Don’t Repeat Yourself, Single Responsibility, etc.). Sort of like how physicists are looking for a single underlying law to the four fundamental forces.

Jim thinks that using ‘connascence’ he can derive many of the principles. Connascence is defined by thefreedictionary.com as:
Con`nas´cence
n.
1. The common birth of two or more at the same tome; production of two or more together.
2. That which is born or produced with another.
3. The act of growing together.

For software connascence is when changing one piece of software requires a corresponding change in another place.

As the distance between the software increases we want to use weaker forms of Connascence

A weak form of connascence is connascence of name
def foo(bar)
bar + 1
end
if I change the name of ‘bar,’ I have to change the next line too. If I change the name of the function ‘foo,’ I’ll have to change all the places that call the ‘foo.’ So, even within connascence of name there are levels.

Connascence of position is when order matters (worse than connascence of name):
def foo(a,b,c,d,e)
….
end

People calling this method have to remember the order of the arguments. A common solution in Ruby is to use a hash to move to a lower form of connascence (connascence of name):

def foo(options)
…
end

so you can call the method like so:
foo(:position => 54, :height => 10, :width => 20, :depth => 3, :solid => true)

A common connascence of meaning problem is magic numbers. If many places have to know that -999 means a bad response this is connascence of meaning.

Connascence of timing is race conditions

Connascence of Execution is when the order of the steps matters.

Unfortunately I wasn’t able to get down all his examples of how Connascence is the common link for all software problems (and I think this is a work in progress) so hopefully Jim will write this up in more detail some day.

What if Bacteria Designed Computers? – Ward Cunningham

Ward Cunningham is legend in Agile, XP, and computing in general so he can pretty much talk about what he wants and everyone will applaud at the end. Today he was talking about buying tiny IC chips, wiring them together, and getting them to communicate like cells. By doing this he was able to build completely new and seemingly complicated devices (such as a flag waving robot) simply by swapping some parts around. Was this a powerful metaphor for having a reusable tool set or just a guy talking about geeky stuff? He never came out and made it explicit. I enjoyed the talk none the less.

The Business of Craftsmanship - Kevin Taylor, Micah Martin, and Carl Erickson

The owners of three craftsmanship oriented shops got together and took questions from the audience. Carl Erickson founded Atomic Object in 2001 in Grand Rapids, MI. Kevin Taylor started Obtiva in 2005 and Micah Martin created 8th Light in 2006.

This discussion rather quickly became about how the Apprenticeship programs work at each company. At Atomic object it seems to be a summer thing for college students and it continues from summer to summer as long as it’s working out. If it goes well, it leads to a hire. Obtiva brings in apprentices and the apprenticeship may continue for a year or two before they are moved out of the apprenticeship. Apprentices can be moved into billable work whenever they are ready which could be a matter of weeks or months but no more than 3 months (it’s a paid position so the company can only afford to carry someone for so long). At 8th Light apprentices are assigned to one of the higher level consultants and are non-billable for 3 months. After a series of challenges they are either given another 3 months, promoted, or let go.

All three companies have experimented with different types of overseeing the apprentices and have generally found that someone needs to ‘own’ the mentor-ship of an apprentice otherwise, as Carl Erickson said, “You’d see two apprentices off in a corner working together” and that didn’t work.

At that point I had to run off and give my “What’s the Right Level of Testing?” talk at Agile 2009. Since the two conferences were held a city block apart, the commute wasn’t too hard. The talk went pretty well, there were about 40 attendees but they mostly seemed kinda sleepy. 4 or 5 people were pretty engaged though and seemed to enjoy it. 90 minute presentations are the rule here at Agile so when you have a 45 minute talk two of them get squished together into a 90 minute slot with no time for transition. So to attend my talk someone would have to see the 45 minute talk before me and hang around, leave another talk mid-stream, or sprint from one 45 minute talk (which could be in another tower) to mine in zero seconds. So with these rationalizations firmly in place, I feel good about the turnout and how it was received.

Tomorrow I’ll be able to see some of talks but I’ll have to leave early to fly to Austin to present at Lone Star Ruby Conf.