The results are in: In-house software craftsmanship day

On Friday Nov 12, we hosted an in-house "software craftsmanship day".  The format was similar to many of the software conferences I have attended, with multiple tracks, some more technical than others.
The schedule and session notes are in my previous blog post.
The raw retrospective notes are on the learning group's google site.
The event was an unqualified success, based on feedback from the participants.  Some of the most valuable things we found:

• Relationships: getting everyone talking to (and pairing with) people on other sub-teams is an end worth pursuing by itself.
• Sharing knowledge: having different people pair on hands-on exercies spread out some of the micro-patterns that people follow in their day-to-day work.

The feedback was entirely positive and constructive.  In my experience, people here are not at all shy about sharing criticism, so I took that at face value.
I believe the two main keys to success were...

• Preparation: most of the people who hosted sessions did a dry run with a handful of people first, and adjusted their presentation and delivery.

• Food!  Having grub for everyone (donuts in the morning and a big lunch mid-day) kept us all together and underlined the importance of the event for all participants.

I'll chat more about the event in the google software craftsmanship group.

Software Craftsmanship Day at my workplace

Well, we finally pulled together a schedule and planned out all of our sessions for a Software Craftsmanship day at my workplace. 

The coolest part?  I didn't have to beg anyone to make it happen.  One of the VP's suggested that we could devote a day per month to honing our development skills.  How many organizations do that?  Very few, I think.

Since I was already leading a craftsmanship group, my boss asked me to lead the effort to put this together.  I just asked for volunteers, called a weekly meeting to work out what we wanted to do, and we did it!

I'll be sure to report what I learned once the first one is over.  I expect this to be a very useful and interesting day, but I won't know for sure until after Friday, Nov 12.

The best way to describe what we're doing is to paste the invitation I just sent to all of the agile teams here (about 120 people are invited, I expect around 100 to attend).

 

 

Craftsmanship Day (a.k.a. "Craft Day") takes place all day this Friday.  Our management has chosen to give us a full day to practice and define our "craft" when it comes to developing and delivering products.   Your fellow agilists decided to run with this idea, and we put together a day of conference-style sessions, all of which offer hands-on activities.

 

The term "craft day" comes from the "software craftsmanship" movement.  Try googling "software craftsmanship" for more information on the background for this effort.  The movement is software-centric, but encompasses much more than just programming practices.

 

We will have a retrospective at the end of the day, but we will also be gathering feedback in the Gale Agile Learning Group (a google discussion group).  You can post questions, ideas or feedback there any time!

 

The following schedule details the sessions you can choose from.  A description of each of the sessions is below the schedule.

 

When	Space 1	Space 2	Space 3
9:00 - 9:30	Introduction Team 3 & 4 Areas
9:00 – 12:20 (3h20m)	Clean Code Retreat– Erik Przekop, Karen Wasielewski, Tim Taylor, Jerry Hoerig Team 3 & 4 Areas		Story Writing & Splitting – Bernard Grunow, Aimme Keener, Mike Gantz Team 5 & Agile Concept Space
12:20 – 1:00 (40m)	Lunch
1:00 – 2:50 (1h50m)	Refactoring Randori – Erik Przekop, Jerry Hoerig, Sajid Mohammed, Pete Murasky, Mike Seiler Team 3 & 4 Areas	Fun with Jquery – Jason Dinkelmann Team 2 area	Defining / getting to done – Bernard Grunow Team 5 & Agile Concept Space
2:50 – 3:00	Break
3:00 – 4:15 (1h15m)	Legacy Rescue – Aaron Chesny, John Nader Team 3 & 4 Areas		Story Estimation – Aimme Keener Team 5 & Agile Concept Space
4:15 - end	Retrospective Team 3 & 4 Areas

 

The Code Retreat session will focus on clean code

• a series of 20-minute coding sessions
• a retrospective and suggestions for coding practices to try
• rinse and repeat

The Story Writing & Splitting section will focus on writing epics and splitting them into stories

• review stories for some of our current products
• hands-on converting epics to stories - how we should split them
• key realizations about best practices
• examples of good & bad stories

Refactoring Randori will use a Code Dojo format, and work through several refactoring problems

• split into groups of 20 or less
• a pair codes on a machine with a projector
• everyone else shouts out suggestions
• the pair changes every 5-10 minutes

The Fun With JQuery session will focus on programming with JQuery

• Jason will give an overview of the what, why & how of JQuery
• Hands-on programming exercises

Defining / Getting To Done:

• A retrospective approach to determining what "done" means
• Various definitions of "done" for a story to move to the next stage

Legacy Rescue:

• "Travel light", "do no harm" and "avoiding rabbit holes" - how we assess legacy code
• Hands-on programming exercises
• Review of the exercise
• Tips & pointers

Story Estimation

• Why it matters
• Exercises involving:

• prior projects
• decomposition
• team estimation
• relative estimates
• overall measurements

At SCNA: Part 4

This is the last post in a multi-part series about the Software Craftsmanship North America conference in Chicago.

Combinator-based design in functional programming: Michael Feathers

I'll be honest - I didn't really pick up a central theme on this one.  It was interesting and I took some ideas from it, but I can't really summarize it well..

My take-aways:

• We have a settled idea of OO, but not yet one of functional programming - the "best practices" are still evolving.
• Haskell is a good functional language to learn with - it forces you to be functional.
• Duplicating objects at runtime is no longer evil.  Duplicating code still is.
• OO increases encapsulation and understandability.  Functional increases immutability and reduces the number of moving parts.

Panel Discussion: Bob Martin, Michael Feathers, Chad Fowler and Enrique Comba Riepenhausen

This was my favorite session of the conference.  Instead of my interpretation of what the presenter was trying to say, here are my favorite quotes from the session, grouped by theme.

On the image we project as developers 

"We are not a bunch of twinkie-eating guys who don't are about their customers.  We are professionals.  That perception is what has to change."

 - Bob Martin

"Programming shouldn't be a 'lifestyle choice', particularly when you reinforce negative 'nerd' stereotypes."

 - Chad Fowler

On the "craftsmanship" movement

"We don't have to evangelize.  What we're doing is enough.  It does not have to include all developers."

 - Chad Fowler

"...but we should welcome everyone who wants to come."

 - Enrique Comba Riepenhausen

On practicing software development

"Coding is relaxing.  When I wake up in the middle of the night and sit down to code, it's refreshing."

 - Michael Feathers

"...I try to practice four hours per day.  Doing that is refreshing."

 - Enrique Comba Riepenhausen

"I don't do anything I have to do after 5:00 PM.  Only things I want to do."

 - Bob Martin

Wrap-up: Corey Haines

In a lot of ways, this conference is Corey's baby.  He is (as far as I know) the driving force behind the "craftsmanship movement".   (Credit where credit is due: Uncle Bob Martin's cohorts were the organizers of the event, and they did a great job.)

Corey's talk  can be summed up by his own words: "What will allow us to take over the world?"

My take-aways:

• Happiness is what sets craftsman apart from non-craftsman.  if you're not happy, figure out why not & change that.
• "Division and negativity are what will keeps us from total world domination."
• Stay positive about yourself, your work and your craft.  Above all, stop bitching about other developers and our customers.  More civility is needed, and we can all contribute to that!

 Great stuff.  I can't wait for next year.

At SCNA: Part 3

This is the third post in a multi-part series.  The conference covered two days, with many presentations, lightning talks, and conversations about software craftsmanship.

Chad Fowler: McDonalds, Six Sigma and Saxaphone

Fowler, like many other people at SCNA is a "musician/developer" - he chose software development as a career after trying to make his way as a musician.  Exactly how much that influences his craft is hard to say, but it seems to happen often enough to take note of it.

He described what we do as in the middle of a continuum with "Art" on one end and "Commodity" on the other.  A parallel is that art is about form, while commodity is about function.

My take-aways:

• Treating your work as "art" means that you can talk about it subjectively, which is a cop-out.
• Internal quality is irrelevant.  Customers don't care about "form", only "function".
• We can't make software better than McDonald's sells burgers.  Having a system for what you do matters.  He cited the Standish Chaos report to support this idea.
• Having a training program with objectives for each phase helps for marathons.  A training program is essential for each of our careers.
• The Six Sigma Design->Do->Measure->Refine->repeat cycle likewise applies to our on careers.

After Chad's talk, I told him I bought his book twice, not realizing "The Passionate Programmer" was the same as "My Job Went To India".  His answer was that they tried to make it very clear that it was essentially the same book in all of the descriptions of it.  It may have been the nicest way anyone has ever called me an idiot.

Keavy McMinn: Fine art and software development

McMinn talked about her transition from fine art to programming.

My take-aways:

• Keep in mind both the internal (what are my motivations?) and external (what are the fears and motivations of my customers?) questions in any project.
• Keep a sense of play in your work.  Do some things for yourself.
• "As programmers, change is relatively cheap.  We have no excuse." (not to change our work product for the better)
• Group critiques in art can be brutal, but they really move things forward
• • We have processes we can use to do this
  • We're too complimentary to each other - be polite, but dig into what the problems are!
  • Having a culture of blame will kill this - eliminate it.
• Learn from larger problems, then solve smaller ones.  (Backwards from the usual take on this.)
• "The future belongs to the few of us still willing to get our hands dirty." (Piece of art that revealed this message when you rubbed it - done in graphite)

Lightning Talks

The one that stood out the most was done by an oddball guy who claimed that he puts the fact he smokes pot on his resume.  (This wasn't part of the talk - I just overheard him loudly hitting on a pretty French software developer earlier in the day.) 

 

My favorite quote from his talk:  "If I think it's about me, I'm a narcissistic douche."

 

Another talk was on Genetic Programming.  The concept is:

• Use a program to write a program.
• Generations of grammar / evaluator determines which algorithm is the most fit.
• Needs good tests - it isn't "fit" until it meets the expectations.

Enrique Comba Riepenhausen: The Forsaken Value

I spent quite a bit of the in-between session time (and at the bar the previous night) talking to Enrique.  He's a great storyteller, and a very good photographer.  I stole the photo of Corey for this blog entry from his Flickr site.

 

My take-aways:

• "Why become as good as you can?"  To create productive partnerships.
• Try to find the right customer to create such partnerships.  You're better off saying "no" to potential customers that you know you can't serve well, whether because you aren't able to meet their needs, or simply because you can't do it within their budget.
• Some customers don't need top value.  They need something quick & dirty that will tell them if they have a market (and help them find investment if they do).  You can still work with them later if you advice them during start-up.
• "We're not going to work for you.  We will work with you."
• • We're the experts in producing software.  Don't just do anything the customer asks.  We do have the right to refuse if it is foolish and will derail the project.  Just be diplomatic about why and make sure that you understand all of the assumptions.
• Beauty is how we build our software, but that's purely internal.