Articles

At the Software Craftsmanship Summit last weekend we sat in groups of 5 or 6 and put each other on trial.  We were looking for the types of questions we would ask someone to determine whether they were a "craftsman" or not.  I volunteered to go first for my group and Scott Pfister asked me a real head scratcher:

Rank the following 3 project attributes in order of importance and explain why.

• Test Coverage
• Timely Delivery
• Code Quality

I thought about it for around 30 seconds and then gave my answer. Micah Martin was asked the same question and gave the same answer as I did.  Interestingly, I brought up the question at Obtiva's Geekfest and Tyler Jennings, someone I have a ton of respect for as a craftsman, gave the opposite answer.

How would you answer this question?  Explain yourself!  (You'll need to register and login to comment.)

The following is an excerpt from my recent post to the software craftsmanship group where I followed Matt Heusser's lead and described why I am a part of the group:

I think this sort of "why I am here" declaration is a good idea.  And Matt's email made me ask myself why I am involved in this group and how I ended up here.

First, I would like to start out by recommending that anyone who is serious about software craftsmanship go out and read Pete McBreen's book "Software Craftsmanship".  I think it's a critical starting place for these discussions, and on a more personal note, the book had a huge impact on me.  Probably the biggest reason I am a part of this group is that I have no where else to go.  :)  I was a later-in-life self-taught programmer who had a wife and child(ren) to support from the day I wrote my first for loop, so I have no formal scientific or engineering education, and I don't have the option of taking time off to obtain one.  And yet I want to become great at what I do.  In my first two years as a programmer I started to despair about my lack of relevant education.  It seemed that without computer science or software engineering credentials, I was going to have a hard time making progress.  But then I read "Software Craftsmanship" and I felt like I could fit into the world that Pete was describing.  I could see myself in the story, and I recognized that I was an "apprentice".  This gave me the "career map" I needed which allowed me to take the steps I needed to make progress.  Neither computer science nor software engineering provided this map for someone like me.  So, unlike some people (like Pete) who argue strongly against software engineering, I am mostly ignorant of it and choose software craftsmanship because I didn't have any other options.

The steps I took after reading Pete's book obviously shaped the way I look at software development.  And because these 6 years since I read Pete's book have been largely positive for me, I would like to encourage other people to walk a similar path, to help them make similar progress.  That is one of the reasons I wrote "Apprenticeship Patterns".  I would also like to improve the apprenticeship experience and raise the bar for what we expect from someone with 4, 5, or 6 years of experience in our industry.  That is one of the reasons I started Obtiva's apprenticeship program.  I want to instill a desire in people to become master craftsmen, which is a very counter-cultural, yet increasingly important role to play (see http://search.safaribooksonline.com/0201733862/ch11lev1sec1).

So, I wonder what we as a community can do to improve these things even more.  I wonder how we can make it easier for companies and individuals to take on apprentices.  I wonder how we can make it easier for companies and individuals to host and send journeymen to spread great ideas between development shops.  And most critically, I wonder how we can ensure that our master craftsmen stick with the fundamental activity of actively developing software for long-term customers (see http://search.safaribooksonline.com/0201733862/ch08lev1sec7).

I'm honestly not interested in any criteria that would allow us to distinguish an apprentice from a journeyman or a craftsman from a non-craftsman.  When it comes to a set of principles that a software craftsman should adhere to, I think Pete's book serves as a good enough starting point.  I realize now that I'm here because I hope that we can organize a network of people to encourage the 3 activities that I've seen make the biggest impact on people becoming software craftsmen.  I'm here because I'd like to see us:

1. Facilitate the introduction of apprenticeships, similar to 8th Light's and Obtiva's
2. Create a structure that encourages journeymen to journey between development shops, similar to Corey Haines' tour
3. Seek out master craftsmen and identify their masterpieces and contributions to the craft, to provide the rest of us with something to aspire to

Yesterday I attended the Software Craftsmansip Summit hosted by 8th Light.  I'm still processing everything we did and talked about, so I thought I would write down some of my initial impressions.  One of the questions I had in the back of my mind was "what is the summit trying to accomplish?"  Paul Pagel's open invitation to the summit talked about finding a consensus about what software craftsmanship means, and then creating a guild or organization to represent the ideals of software craftsmanship.  But the question that Corey Haines and I brought up toward the end of the day is "what problem are we trying to solve?"  It was exciting to be a part of this group of people who all shared many common passions about quality, learning, and mentoring.  It was tempting to imagine that we might be at an historic gathering, which happened to include a couple of the authors of the Agile Manifesto.  But as the day went on, I became increasingly skeptical about why software craftsmanship would need anything similar to the Agile Manifesto or the Agile Alliance.  I'm not saying that I don't want to be convinced otherwise. Nor would I mind at all if the rough draft of values and principles we sketched at the end of the day evolved into a significant document.  I'm just struggling to see what value that document is going to provide.

I was thrilled to see us spend quite a lot of time talking about apprenticeship.  We actually spent the first half of the day telling our own apprenticeship stories and looking for common themes.  This was a little nerve-wracking for me since I'm done writing (this edition of) the book, so if any themes were identified that contradicted the Apprenticeship Patterns, I'd be in a tough spot.  Thankfully, I found myself in familiar territory, and I had to bite my tongue to not call out the different pattern names as people were describing them.  David Chelimsky even quoted Pat Metheny's seminal Be the Worst statement, and I didn't even say a word. :)  As I was driving back home, carpooling with Jake Scruggs and Joseph Leddy, we discussed that one of the benefits of a software craftsmanship organization would be that it may be able to spread the word about apprenticeships.  This aspect of the day is sticking with me most, and I'm hoping it's not just because I've invested so much of myself into "apprenticeship" and therefore I have a vested interest in seeing apprenticeships more widely adopted.  I'm hoping it's sticking with me because apprenticeships are good for our industry, and therefore they're ultimately good for our customers and end users.

So, right now, my takeaway from the summit is a question. Why aren't there more apprenticeship programs out there?  Or if there are, why are we not hearing about them?  I suppose this is the problem that I'm most interested in helping to solve.  My Call for Apprenticeship from 16 months ago is still on my mind quite a bit, and I'm disappointed I haven't seen more movement in the right direction.  I'm hoping that as the apprentices that come out of Obtiva's and 8th Light's apprenticeship programs make their own waves that it will open people's eyes to the power of a strong(er) apprenticeship.

I started a discussion about Apprenticing over on the Software Craftsmanship Google Group that readers of this blog may find interesting.  It's focused more on the people taking on apprentices than the apprentices themselves. http://groups.google.com/group/software_craftsmanship/browse_thread/thread/afa7899234869c90

Whenever I've thought of Software Craftsmanship, I've always focused on apprenticeship, and the apprentice's transition to journeyman.  I suppose that's because I've always been fascinated by the learning process, particularly the rapid learning process of the relative newcomer.  These days I'm becoming more focused on the long road to mastery, hoping to someday become a master craftsman myself.  On the other hand, "Uncle" Bob Martin has always focused on the practices of a craftsman, the day-to-day conduct and techniques that a craftsman should adhere to. Lately I'm seeing Micah Martin and Jason Gorman pick up on that theme and assert that the Agile community has moved too far toward process, as opposed to its original focus on working software.  I agree with them and I admire their willingness to distinguish themselves from mainstream agile thinking.  Both of these guys are trying to rally developers around software craftsmanship. Micah is hosting a software craftsmanship summit. Jason is organizing a software craftsmanship conference.

I believe the time is right for us to refocus on working software and pay a bit less attention to process. The main reason I believe this is because of the game-changing productivity gains that we've seen over the last 4 years.  I'm basing my belief on my experiences in the Ruby and web development communities. Do you realize that a few weeks ago over 200 teams competed in a contest to develop a working application in 48 hours? Yes, 48 hours, start to finish. Starting from nothing other than a blank slate Linux distro, you had 48 hours to build a functioning Ruby on Rails application.  Sure, Rails gives you all sorts of stuff out the box, and that's what makes the competition possible, but the real competitive advantage comes when teams can leverage all sorts of robust JavaScript libraries (we used Flotr for graphing interactive data) and, better yet, web APIs to consume services provided by Google, Twitter, and Netflix, to name a few.  When 4 people can self-organize to create something that fast, the game has changed.  A process that was born and bred in 8-man Java-land is just going feel heavy-weight in this sort of hyper-productive environment.

And now more people are banging the software craftsmanship drum, myself included. I've always tended to bang the little apprenticeship drum, but I think I'm ready to bang the bigger, louder drum that's all about raising the bar on code quality and professionalism. So I'm excited to attend the software craftsmanship summit next month, and I'll be paying close attention to the London conference as well.

I tweeted a link to my Do No Harm post, where I relayed some re-discoveries I had made about the analogy between software craftsmanship and medical surgery.  I quickly heard back from two respected software developers Bil Kleb, Rubyist at NASA, and Bret Pettichord, creator of Watir.  Both of them pointed me at an even older book: The Mythical Man Month.  I read this book back in 2003. It reminded me of The Psychology of Computer Programming because despite its focus on certain out-dated concepts, the core principles it communicated are as true today as they were 35 years ago.  I had forgotten that Brooks wrote an entire chapter entitled "The Surgical Team", based on a propsal by Harlan Mills in 1971.  It outlines the structure for a multi-disciplinary team, with roles such as: surgeon, co-pilot, administrator, editor, secretaries, program clerk, toolsmith, tester, and language lawyer.  I would assert that many of these roles have been automated over the last 35 years, with the most notable being toolsmith replaced by open source software.  Yet the roles of surgeon, co-pilot and administrator resonated with me because this is very much the structure of my daily work in Obtiva's Software Studio, where I (the surgeon) work with Joseph Leddy or Turner King (co-pilots), and depend on Todd Webb (administrator) to help manage our workflow.

After reading the chapter on surgical teams, I wandered to the first chapter and found a section on page 6 entitled "The Joys of the Craft", followed by "The Woes of the Craft". These are two excellent sections, particularly for aspiring software craftsmen, because it provides some insights into the road ahead.  Here are some highlights:

"Why is programming fun? What delights may its practictioner expect as his reward? First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.... Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both."

"Not all is delight, however, and knowing the inherent woes makes it easier to bear them when they appear. First, one must perform perfectly... Next, other people set one's objectives...One rarely controls the circumstances of his work, or even its goal. ...The next woe is that designing grand concepts if fun; finding nittly little bugs is just work. With any creative activity come dreary hours of tedious, painstaking labor, and programming is no exception."

I highly recommend this classic book to anyone interested in developing software.

There's still some work left to do on the book, but I've made a ton of progress over the last few weeks, which is a great feeling.  If you feel the need to pre-order, you can choose O'Reilly or Amazon or elsewhere.  The O'Reilly store says it will be available next month (cold), while Amazon says February 15 (getting warmer).

I am wrapping up the manuscript for this book (deadline on 10/17) and just wrote the first pass at a "Perpetual Learning" pattern named "Expand Your Bandwidth".  I ended the pattern with my 3 experiences using it. I thought it would make sense to post my stories here:

When I was given the opportunity to learn my first programming language by my employer in late 2000, I began Expanding my Bandwidth immediately. I felt like I had a lot of catching up to do, so after I read a couple Perl books, I looked for any possible opportunity to learn more. I was determined to reach the next level as a Perl developer as quickly as possible and knew that just taking one book at a time wasn't going to be fast enough (I'm competitive, OK?). So I joined perlmonks.org, asked and answered questions on comp.lang.perl.misc, attended a couple Perl Mongers meetings, and started playing Perl Golf (yes, competitively). After about a year of this, I had to scale down my intake for the sake of my sanity and marriage. But I had made progress, and had many more resources at my disposal when I found myself stumped.

Then, in the spring of 2002 I read Kent Beck's Extreme Programming Explained and saw an opportunity to grow beyond Perl into the world of test-driven development, pair programming, object-oriented design, and design patterns. Once again I Expanded my Bandwidth and read a pile of excellent books, started attending a local agile software development user group, paid my way to XP/Agile Universe conference (thankfully held near my home that year), participated on the extreme programming mailing list, started reading relevant blogs, and subsequently started blogging. The outcome of this season of Expanding my Bandwidth won me a job at ThoughtWorks, a transnational agile consulting company. My career and apprenticeship were forever changed by the learning opportunities that ThoughtWorks presented me.

As I transitioned from apprentice to journeyman toward the end of 2005, I saw another opportunity on the horizon: Ruby on Rails was on the rise. I strategically Expanded my Bandwidth in order to take advantage of the market opportunity that this presented. This allowed me to join Obtiva, a local consulting company that better fit my lifestyle, where I founded Obtiva's Software Studio and kick-started Obtiva's apprenticeship program. Expand Your Bandwidth is an extremely powerful pattern when used strategically. Just remember to turn it off periodically. :)

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.