Articles

I stumbled across a five-year-old blog post of mine yesterday.  It caught my eye because it's title matched one of the themes of one of my talks at WindyCityRails.  As I wrote in my last post, I've picked up on an analogy that Uncle Bob has been writing and talking about for a the last couple years.  Well, it turns out that my attraction to this analogy was not due to the novelty of thinking that the craft of software development is analogous to the practice of medical surgery.  The idea may have resonated with me because it is mentioned in one of the great books of our field, by one of our most experienced practitioners.  My old blog post quoted the first edition of Code Complete (1993) which quoted Jerry Weinberg saying:

"Opening up a working system is more like opening up a human brain and replacing a nerve than opening up a sink and replacing a washer. Would maintenance be easier if it was called 'Software Brain Surgery?'"

This supports Pete McBreen's assertion in Software Craftsmanship that it's absolutely ridiculous that so many teams entrust the "maintenance" of software assets to our least experienced developers.  The strength of this analogy seems to be growing (in my mind at least), and I wonder how it might inform our work in other ways?

I had the privilege of speaking twice at WindyCityRails on Saturday.  It was a one day conference near and dear to my heart since I spend most of my days in the Windy City working on Rails projects.  My official talk was about what I learned developing Mad Mimi.  (I learned that having a good customer is an incredible advantage.)  My unofficial talk was 10 minutes of whatever I wanted to talk about in front of the 100+ conference attendees (immediately after an excellent Q&A with David Heinemeier Hansson).  So, being the untalented speaker that I am, I decided to channel Uncle Bob, one of the best presenters I've ever heard, and talk about washing your hands.  After being inspired by his talk at Agile 2008, my team and I have ratcheted our craftsmanship up a few notches, and I hoped I could spread the momentum to other teams.

So I talked about washing your hands?  Yes, particularly about how surgeons "scrub in" before they perform an operation.  I think there are many parallels between surgeons and programmers, and I'm going to be researching this a bit further (I helps that my college roommate recently became an attending orthopaedic surgeon).  The simplest parallel is between Test-Driven Development and sterile procedure.  This is something Uncle Bob started talking about 2 years ago: "It has become my position that TDD is a necessary discipline for professional developers. I consider it rather like sterile procedure for doctors. It's simply what you have to do to write professional code." (comment from Agile People Still Don't Get It).  I find this analogy particularly appropriate when you have an existing codebase and you've been asked to fix or enhance something.  Like a surgeon you need to ensure you do not infect your patient, and in order to prevent that, you need to create a sterile environment.  If you don't have tests in place, you retrofit them in order to prevent regressions (similar to cleaning a dirty patient).

I mentioned a couple other implications from this line of thinking.  First, it seems like it wouldn't be too much of a stretch to think that, like doctors, we should subscribe to the principle of Primum non nocere, "First, do no harm."  When we work with a codebase, we should always be improving it, we should never do harm.  How would we know if we are harming it?  Our tests would fail.  Our metrics would be heading in the wrong direction.  Second, when it comes to washing your hands, consider when surgeons wash their hands.  They wash them before, not during, not after, the operation.  Imagine how ridiculous it would be for the doctors to try to keep their environment sterile after beginning an operation with dirty hands.  Similarly, we need to setup our tests before we begin our fix or enhancement or feature development.

Like Uncle Bob, I'm beginning to think that Test-Driven Development is a mandatory practice for people who call themselves professionals or software craftsmen.

When I started Obtiva's Software Studio at the beginning of 2007, I had a lot to learn. A lot. I had focused a lot of my learning prior to 2005 on Extreme Programming, Java, Design Patterns, and Object-Oriented Design. In 2005 I made a decision to put my writing about my apprenticeship experiences on hold and take advantage of the opportunities that Ajax and Rails presented. This led me to leave ThoughtWorks and join Obtiva in 2006, and start our Studio the following year. Starting the Studio meant I had to step outside my cozy world of objects, patterns, and process and into the messier, and unfamiliar world of SQL, web servers, CSS, performance tuning, and system administration. I also had to step outside my cozy world of corporate consulting where missed estimates meant little more than some slight disappointment to a middle manager and into a world where missed estimates meant serious problems for a small business owner. There is no better testing ground for your devleopment ideals than having to justify them to a small business owner whose livlihood is depending on your delivery expertise.

I've written a bit about this before, but I had lunch on Friday with Jay Fields and he was talking about learning the financial domain for his first post-ThoughtWorks gig. He said he was enjoying it but pointed out that it wasn't something that would be directly beneficial to him since he wasn't ever planning on being a trader. Thinking about this on the way back to the Studio, it drove home the power that a generalist possesses. Since I have Software Craftsmanship on the brain, it reminded me of a quote from McBreen's book:

"The step from apprentice to journeyman is very significant and represents the coming of age of the developer. It is a public recognition that the developer is a skilled generalist, able to undertake application development projects without assistance."

Without assistance. While there are countless things that I appreciate about Obtiva's Software Studio, one of the most valuable assets I have developed there is my ability to undertake application development projects without assistance. Not that I have actually developed anything in the Studio without assistance. We are a team, and the Studio was started with apprenticeship in mind, so we strive to pair program and collaborate every day. But when I have a few days or nights to myself, perhaps a long plane ride, or a long weekend, I have the opportunity to quickly turn ideas into a reality. While there is nothing sexy about deployment scripts or web server configuration, the power of the knowledge to develop and deploy software without assistance is literally priceless.

We're starting to put the beginnings of actual structure into Obtiva's apprenticeship program and yesterday I met with each of our 4 software apprentices to talk about their progress and/or map out the next steps in their journey.  One of the new tools we're using to help with apprenticeships is our Apprenticeship Skills Sheet.  This maps out the optional and mandatory skills that an apprentice needs to focus on.  It's basically a tool to focus your learning.  With our 2 senior apprentices I reviewed the skills and, not surprisingly, many of the skills were already completed.  But we also had some really important realizations as we reflected on each skill.

A key realization started to hit home for me when we hit the JavaScript skill.  The reaction was, "well, if I never met Fred, I'd say I was pretty much there."  And then the TDD skill, "well, if I never met Renzo, I wouldn't have realized how clearly tests can be written."  And then the Customer Collaboration skill, "well, if I never met Joseph, I'd say I was OK."  This was music to my ears.  Our apprentices are being exposed to people with diverse skills and interests and a healthy dose of excellence.  They are comparing themselves to some of the best in the business, and that's what an Accurate Self-Assessment is all about.  It's too easy to be satisfied if you compare yourself to the industry average.

I'm still thinking about Uncle Bob's talk at Agile 2008 after returning to Obtiva's Software Studio after a few weeks away.  One of the things he talked about was valuing "Craftsmanship over Crap".  After I spoke briefly with him afterward, it didn't seem like there was much more to his statement than simply promoting craftsmanship.  And that's fine by me, but I tend to be someone who picks up ideas like this and play with them for a while.  In my last post, I reworked "Craftsmanship over Crap" into "Craftsmanship over Heroics", and I'd like to say a bit more about why I chose heroics.  But first, I'll need to rewind the clock a bit.

In 2002, I read Pete McBreen's Software Craftsmanship.  I read a ton of great books that year.  Pete's book ranked near the top because of the ideals and structure that it described.  Similar to Kent Beck's Extreme Programming Explained, as I was reading the book I kept telling myself "this is how I want to work".  One of the themes of Pete's book is that "Software craftsmanship is built on top of long-term relationships that are grounded in a reputation for delivery."  One of the most satisfying aspects of pioneering Obtiva's Software Studio has been building the foundations of long-term relationships with our customers.  It's incredible how much ceremony and waste can be thrown out the window once a customer and development team can trust each other.  Watching some of Pete's ideals unfold in front of my eyes has solidified these ideals into hard won experience.

Unfortunately, like most developers who find a technique and use it successfully, it can be overused.  And by this I mean, letting all process fall away and simply execute your customer's every whim at maximum speed.  For me, this inevitably devolves into heroic programming.  There are times when you need a bit of heroism on a project, but this shouldn't happen more than a few times a year.  I recently found myself in a feedback loop of doing heroic programming at 2AM (and injecting bugs in the process), seeing some benefits, receiving praise from customer, fixing bugs the following night at 2AM (and injecting bugs in the process), seeing some benefits, receiving praise from customer, and on and on.  This is why the term "heroic" came to mind so quickly for me when I heard Uncle Bob. I've seen first-hand how a relationship with a customer can be taken too far and produce crap.  The obvious superior alternative is to stay disciplined, to maintain a healthy relationship with your customer, protect your sleep habits so that you're at your best, and to uphold your standards of craftsmanship.

I had the pleasure of listening to "Uncle" Bob Martin last night at Agile 2008 while we were eating dinner.  Bob is hands down the most entertaining speaker I've ever heard at a conference, and I've had the pleasure of listening to him at several of the Agile conferences.  The beautiful part is that while he entertains, he always has an important message, and his message this year was right on the money.  Never one to shy away from big ideas, Bob proposed to add a 5th value to the Agile Manifesto: Craftsmanship over Crap.  It was great to hear Bob continue to beat the craftsmanship drum, and Bob's slant on craftsmanship is all about professionalism.  He drew a wonderful comparison to the history of medicine when some hospital administrator discovered that having his doctors wash their hands lowered the hospital's mortality rate.  The critical tie-in for me was Bob's final words that "doctors don't have time to wash their hands," drawing a parallel with how often developers rush through our work without writing tests and keeping our code clean.

The problem with Bob's proposal is that it doesn't quite fit with the other agile values. There is no value in the item on the right!  I suggest we reword it to "Craftsmanship over Heroics".  While there are times that we need to be heroic for our customers, making a habit of heroic coding ends up producing crap and burns people out.

I just returned from a visit to my parents with my family.  My siblings and I are in kid-mode right now, with 7 cousins between ages 1 and 9, so we had some DVDs playing periodically as the cousins wore each other out.  One of the movies was Ratatouille.  The theme of that movie is near and dear to my heart because it shares the same grassroots, bootstrapping quality as the craftsmanship model and the way that apprentices are found and developed.  The movie is all about cooking and the theme is "Anyone can cook".

I believe that the Internet and Open Source have made this true for software developers.  Anyone with an Internet connection can learn some basic skills.  That's how I got my start, by reading an HTML tutorial online.  Just like most people have food and some tools for preparing it, many people have access to all the information they need to become a novice programmer.

A food critic at the end of the movie built on top of the "Anyone can cook" theme with "Not everyone can become a great artist, but a great artist can come from anywhere."  This quote hit home, particularly after giving my OSCON talk last week, which was fairly heavy-handed about Obtiva's success with people lacking a computer science education.

In one of the final sessions at OSCON today, Brian Tatnall and I spoke about our experiences with apprenticeship at Obtiva's Software Studio.  The slides are available for viewing from 280 Slides.

I attended my local Ruby Brigade on Monday and listened to Chris Hicks talk about sneaking Ruby into a Fortune 500 company. It was an interesting talk and I was impressed by Chris's ability to learn Ruby (his first programming language) over the course of a few months, and then present his experiences to a bunch of experienced Rubyists.  Afterward, a bunch of us grabbed some beers at a local pub and I had the pleasure of talking to Paul Pagel of 8th Light about apprenticeship.  Paul recently started mentoring an apprentice, so we had a lot to talk about.

I've thought about our conversation ever since and the different approaches that Obtiva and 8th Light are taking with their apprenticeship programs.

Obtiva hires apprentices into our Software Studio where apprentices are somewhat insulated from our clients and therefore have a relatively safe environment for learning.  The apprentices aren't assigned to a specific mentor, it's the Software Studio team's responsibility to ensure that apprentices are making progress and getting enough mentoring.  Sometimes we've failed to ensure that this happens as we balance client needs and team growth and the correct ratio of apprentices to more senior developers.

8th Light hires apprentices and attaches that apprentice to a mentor.  The apprentice shadows that mentor every day.  The mentor is responsible for finding and hiring the apprentice.  It's a more traditional approach to apprenticeship, and I assume that it's done in the context of on-site consulting work rather than in a remote environment like Obtiva's Software Studio.

It occurred to me this morning that while there are some business reasons for our different approaches, there is also some biographical reasons: my apprenticeship was less traditional than Paul's.  When I first met Paul, he was an intern at Object Mentor, a company led by Bob Martin, a long-time proponent of software craftsmanship.  Paul went on to work for Object Mentor and then moved onto 8th Light.  I, on the other hand, had a much bumpier (and perhaps typical) journey through several different companies, none of which emphasized apprenticeship.  I had to create my own apprenticeship in less than ideal circumstances (which is really what this book is all about).  My hope for Obtiva's apprentices is that they find themselves in much more ideal circumstances: within a culture of learning, a place to be mentored, and a place to stretch your skills.  Yet Obtiva's approach is closer to my own apprenticeship experience than Paul's.  At Obtiva, the quality of one's apprenticeship is largely in the hands of the apprentice, who will hopefully apply the Apprenticeship Patterns to maximize their experience.  Perhaps that's true of apprentices at 8th Light as well, though with a more traditional apprenticeship it would be easier to put the responsibility on the mentor.

I'll be interested to watch both Obtiva's and 8th Light's apprenticeship programs evolve in the coming years.  I'd like to see Obtiva's program take some steps toward becoming more traditional.

Michael Hunger asked whether we were including non-authors in our Basecamp collaboration.  I say: "yes!"  Please comment on this thread and let me know if you are interested in collaborating via Basecamp.  We would be looking for some help with reviewing and possibly offering some of your own stories to support the patterns.

One of the lessons I'm learning as I read through The Art of Learning is the importance and power of a peaceful state, and how periodic relaxation helps with this. One of my most thoughtful co-workers is Renzo Borgatti, who introduced my team to the concept of the Pomodoro technique.  When Renzo introduced it, I wasn't open to it.  I believed I could power through the intensity of my days without any breaks.  But coming back from a week off while reading The Art of Learning, I have an inner peace that is incredibly helpful to the sort of conceptual work that software developers do.  Yesterday was a typically hectic day for me, with many clients and co-workers vying for my attention, followed by an evening full of the same sort of thing, watching the kids while working through a long to-do list (fix sink, email uncle, plan anniversary).  Throughout the day I could feel my inner peace being challenged and sapped.  I could see the opportunities to step back and take a 5 minute break, though I didn't take them.  But unlike 6 months ago, I'm now open to the practice of the Pomodoro, just as I'm also beginning to research Tai Chi.

As I rode my bike to the train this morning, I was in a peaceful state. (I actually left early enough that I didn't have to rush.)  And I was thinking about next steps for the Apprenticeship Patterns and ways I could shift or jiggle my approach in order to jump-start the process.  I needed to get back to Mary about next steps.  And then a simple thought occurred to me.  Just use Basecamp.  For simple, small-team projects, Basecamp is a fine tool. We've used it effectively in developing Mad Mimi, so why not use it to manage the project of writing a patterns book, along with organizing the slides for my upcoming OSCON talk on Apprenticeship and Open Source?  I believe a tool like this, combined with periodic recovery periods should help create the rhythm and sustainable peace that I need to wear my many hats effectively.

And as a meta-example, this blog post is the second in as many days. Hopefully a rhythm is developing in my time of public reflection as well.  Stay tuned.

I've officially declared myself "blocked" as a writer. Declaring this will hopefully help pull me out of writer's-block-denial-land and help me get back on the path to developing these patterns into a publishable form.  I should say that my editor, Mary O'Brien, has been patient, understanding, and supportive through this process, particularly when I've been slow to respond (or unresponsive) to her inquiries.

I just spent a week offline and on holiday with my wife and children. It was an important and well-timed retreat and an opportunity to reflect on why I'm out of flow. Just before I left, Kevin Taylor, my business partner, handed me The Art of Learning (by Josh Waitzkin) just after he finished reading it. It's full of deep insights on learning and performance. It's also full of compelling auto-biographical stories from the chess champion who was the subject of the book and subsequent movie "Searching for Bobby Fischer", who went on to become a Tai Chi Push Hands world champion. The book is all about mastery, but digs deeper into the mechanics of elite performance and what separates the good from the great from the elite.

Two thoughts keep coming back to me as I read the book.

First, Josh has a lot of time on his hands. To be fair, he has exactly the same amount of time that I do.  He has 24 hours per day, in fact he has less time than I do since I'm older than he is. But when I read about him spending several hours a day refining his forms and literally taking hours to move his arms six inches, I realize that his days have very different structure than mine. I am a husband and father of three who tries to spend quality time with his wife and children every day. I am a software developer, team leader, mentor, and business owner who has projects, customers, teammates, and apprentices who need my time and attention. When I was describing Josh to my wife, I told her to imagine my focus on excellence and multiply it by 10. Despite the demands on my time, I have always carved out time to learn about and improve upon what I am currently focused on. For a long time that was American football, and then it was family systems and narrative therapy, and now it is software craftsmanship. I've also taken diversions into the martial art of Kenpo and explored Texas Hold'em poker. Like Josh, I love to learn, and I agree that it's an art. I appreciate that Josh has been able to structure his life in such a way that he can throw himself so fully into the art of learning and then benefit his readers with what he has discovered. But we all must strike a balance in our lives, and when we sacrifice our responsibilities for the sake of learning and mastery, we have slid into obsession.  That said, if I was neither a husband nor father nor business owner, it would be unlikely that I would be as disciplined as Josh to focus so much of my time on learning.  It's too easy to say, "well, he's a genius" or "he only has to worry about himself", but in reality, there are thousands of Josh's out there who lack the discipline to do what he does.

A second thought keeps coming back to me as Josh touches on the importance of allowing your personality to express itself in your craft. For Josh, this meant he played best when he could create chaos on the chessboard and then thrive in that chaos, just as he did in his normal life. When I read this, it was immediately obvious that over the last few years there has been an aspect of my life that is not congruent with who I am.  This incongruence between the various aspects of my life has caused various problems for me. I'm obviously not going into detail about what the incongruence is, but I feel comfortable writing about the effects of it in my professional life. The effects are simple but powerful: I'm off my game and out of flow. When you wear a lot of hats (father, team leader, consultant, husband, etc.) being out of flow feels exponential, as mistakes in one arena spill over into another, and another, and cascade into a mountain of disappointment. These mistakes can be technical, such as rushing through a software feature and choosing not to write tests for your code, or these mistakes can be relational, such as ignoring a customer's needs and missing out on an opportunity to innovate. Recognizing this incongruence was the first step toward correcting it. It is too easy to focus on the symptoms and problems caused by the incongruence, rather than dig down to the root cause and solve the fundamental problem. For example, if an alcoholic wants to overcome their addiction, they generally can't just focus on drinking less alcohol, they need to address the underlying issues that drove them toward alcohol abuse. Likewise I am in the process of digging deep to address my incongruence and turn things around.

This blog will get back on topic shortly! Please forgive my digression into self-improvement and introspection but it's an important step for me to overcome this blockage.