Red Squirrel's Nuts

The Publication of Apprenticeship Patterns

Sun, 25 Oct 2009 00:13:00 -0500

Now that I’ve had the pleasure of holding my book in my hands I feel like it’s time to (re-)tell the story of how this book was born.

In the Spring of 2002, I worked at a big, old (bloated) non-profit organization in Chicago. My boss (IT manager) handed me a book that had been given to him by some local consultants. He had seen my accelerating appetite for software development books and figured I might be interested. I was skeptical of a book coming from my boss, but I knew the consulting firm had some respected software developers, so I took a look at it. The name of the book was Software Craftsmanship: The New Imperative. I read the back cover, set it on the shelf, and went back to reading yet another book on Extreme Programming.

Toward the end of that summer, I took some time off up in Ontario with my wife and some friends. Since I’d finished reading all the available XP books, I thoughtlessly grabbed Software Craftsmanship on my way out on my last day of work. Later that night, we were hurtling northward on the overnight road trip to Ontario. I had already put in my time as driver and everyone (except the driver) was asleep so I figured I’d try to get some sleep too. Naturally, I couldn’t, so I pulled out the book and started reading (with a flashlight). I read almost all of Software Craftsmanship that night. It was one of those “right book, right time” moments for me. Although the target audience for the book was managers and leaders, and I had been programming for less than 2 years, I was old enough (28) to understand what Pete was getting at despite my inexperience. When I put the book down, I had a direction for my career. The context that Pete had set in his book gave me a (albeit vaguely defined) path to follow, and showed me where I was on that path: I was an apprentice.

A few years later, I had switched employers and was working at ThoughtWorks. One of the main advantages of working at ThoughtWorks (2004-2006) was the doors it opened for me. After working on the dream team for my first gig, I gained a lot of confidence (and some competence) and started trying to make some waves. So, I rolled onto my second ThoughtWorks gig and started explaining how I had pair programmed with Dave, Obie, and Aslak. I realized it would be nice to have a name for the style of pairing we practiced. And so I wrote a blog post that helped name the practice of “Ping Pong Programming”. After I wrote this I felt compelled to email Brian Marick to see if the blog post might make sense to publish in Better Software. It apparently didn’t, but it did end up on StickyMinds (thanks to Brian). As a result of that article, I got a call from a StickyMinds editor who told me she just signed up the Prags to write about Software Craftsmanship and asked if I would like to write a column on the same topic. (The Prags didn’t really write much about craftsmanship, it was more a precursor to Andy’s excellent Pragmatic Thinking and Learning.) Whoa! Cool! I immediately agreed to write the column. But then I had to ask myself, what was I, an apprentice, qualified to write about?

The only aspect of Software Craftsmanship that I was qualified to write about in 2005 was developing one’s own apprenticeship. And then it dawned on me that there was a gaping hole between Pete’s Software Craftsmanship: The New Imperative and The Pragmatic Programmer: Journeyman to Master. Where does someone learn how to become a journeyman? And so, in March of 2005, I let my tiny corner of the blogosphere know what I was hoping to do. Earlier that month, a blog post by Chris Morris planted a seed that quickly grew into the first apprenticeship pattern: Be the Worst. Not surprisingly, Chris’s blog post inspired another aspiring author, Chad Fowler, who included a section on “Be the Worst” in his My Job Went to India book (now rewritten as the excellent Passionate Programmer). But I digress. A small pattern language started forming in my mind and I quickly dumped it into a private wiki so I could access it from anywhere (like, say, the hedge fund where I was consulting at that time, hey, the build took a long time!).

The pattern language format felt like a natural fit for the material that I was imagining, mostly because I had been profoundly inspired by A Pattern Language when I read it in 2003. For a while there, all I could “see” were pattern languages. One of the advantages of using the language format was that it connected me to the patterns community, who provided us with excellent feedback and encouragement when Ade and I presented at PLoP. But I’m getting ahead of myself! Who is this Ade character?

A month or two after I had started writing Apprenticeship Patterns, I contacted the Prags about having it published through their new publishing company. Andy had a look at my wiki and asked me to write him a sample chapter (they later passed on the book). This was just the sort of push I needed to get me out of wiki-land and into book-writing land. I soon realized that the book wasn’t going to work if it was just “the stuff that worked for Dave”, and I knew enough about patterns that they needed to be tried-and-true solutions to common problems. So I set out to test the Apprenticeship Patterns against the experiences of other software developers and look for new patterns in their stories. I started interviewing both experienced (Ron Jeffries, Norm Kerth) and less experienced (Desi McAdam, Micah Martin) developers. Working at ThoughtWorks made it easy for me to connect to a worldwide network of excellent developers which helped this process a ton. The most enthusiastic participant in these interviews was Adewale Oshineye. His responses were so well thought out and well written that after a few interchanges, I felt compelled to ask for his help.

Ade and I cranked out a bunch of solid work on the pattern language in 2005, but even before we met at PLoP, I had lost my momentum. It was getting to be late 2005 and I had just spent the better part of the year writing about learning, and I was missing out on actual learning. This was the year when Ajax hit the mainstream and Ruby on Rails exploded. I couldn’t not take advantage of the opportunities I saw, so I set Apprenticeship Patterns aside and started reusing the patterns I had been writing about to learn these new techologies. I ended up leaving ThoughtWorks to join Obtiva, which at the time was a 6-month-old 3-person software development consultancy. A year later, in 2007, we started Obtiva’s Software Studio so that we could more easily take on end-to-end Rails projects and bring on our first Apprentice.

Later in 2007, I was contacted by an editor at Manning who saw our patterns online. (We always kept our most “polished” patterns online to elicit feedback.) The editor from Manning encouraged me to finish the book. And then I remembered Mary Treseler from O’Reilly, who found our patterns back in 2005, encouraged us to continue, and even did some pro-bono editing for us. Before I proceeded with Manning, I wanted to talk to Mary. Once I contacted her, publication was immediately assumed and a contract was signed before the end of the year. Cool! They even gave Ade and me some advance money as we progressed through the milestones toward publication. And progressing we were!

Throughout this little story, I’ve been referring to the book as Apprenticeship Patterns, but up until March 2008, I had usually referred to the book as Software Craftsmanship: Apprentice to Journeyman. The name was a mashup of our inspirations from Pete’s book and the subtitle of The Pragmatic Programmer (Journeyman to Master). To be honest, I still like Apprentice to Journeyman quite a bit, but a couple things happened (some painful) in March 2008 that convinced me we should change the title to Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.

Obtiva grew a ton in 2007 and 2008, and madmimi.com launched in mid-2008, so my life got crazy busy. I started missing deadlines, a lot of deadlines. We were supposed to be finished by mid-2008. We didn’t actually finish until mid-2009. We did a huge push in December 2008, and that was basically the end of my work on the book. After that push, it turned out there was still more work to do, so I asked Ade to see the book through to publication, and if he could make it happen, we’d alter our royalty split from 75:25 to 50:50. Obviously, Ade got it done. He added a bunch of content and polish, and oversaw a ton of details that I would have missed. Along the way, I asked Ward Cunningham to write the foreword and I was surprised that he not only accepted, but wrote an excellent little story about him and Kent back in the old days to provide an introduction to the concept of an apprenticeship pattern.

And so, our little pattern language got printed. I hope you were able to learn something (or at least laughed a bit) from reading this story. More importantly, I hope that you have a look at the patterns and give a few of them a try. Let us know what happens!

What are you practicing for?

Wed, 07 Oct 2009 07:13:00 -0500

I’m running the Chicago Marathon this Sunday. I’ve done a bad job of preparing for this race, so I don’t expect my time to be better than my first two marathons. One of the reasons I haven’t had much time to prepare is that I’ve been coaching football 3 days a week. We practice Monday, Tuesday, and Thursday evenings, with games every Saturday. So, between the marathon and football season, I’ve got sports and practice on the brain, and like I’ve been prone to do in the past, I’m going to compare sports with software. Right, so, if you want to improve as an athlete, you need to practice. Furthermore, if you want to be competitive, you need to practice specific techniques. Guess what? Both are true for software development too. You’ll find that the best software developers have had a series of toy/side projects that they’ve used to practice ideas and hone techniques on. If you’re not practicing, and practicing well, your performance will suffer.

One of the patterns in our soon-to-be published book is named “Practice, Practice, Practice”. This pattern is all about creating a safe environment to make mistakes so you can experiment and learn. For the apprentice, questions about practice are generally “Why? Why do I practice?” The answer is simply, “To get better!” And you could keep drilling down and play the 5 Whys and you’d eventually get to something like “to make more money” or “to work on a project I enjoy”. For the journeyman, the question evolves to “What am I practicing for?” Now that you are a competent software developer, practice is still important, but I think it’s important to focus your practice a bit more.

Something I’ve noticed in my journeyman years is that I’m starting to learn what sort of work I like best. During my apprenticeship years, I was learning how to learn, becoming generally competent as a software developer, and experiencing a variety of different projects. After experiencing nine years of variety, I know what I like. And I’ve noticed that my peers have learned what they like too. Some of them like coaching, some like to teach, others like to facilitate change, others like to architect enterprise systems, and on and on. People in the software craftsmanship community tend to enjoy writing code, but of course, each of us has our favorite contexts and mixtures of activites that we enjoy best.

The software craftsmanship manifesto states “we are raising the bar of professional software development by practicing it”. And I notice that many of us are living up to this. Corey does katas. Micah creates tournaments. Jim leads small groups of learners through the exercises of the Wizard Book. Now, all of these are great forms of practice, but I chose to participate in just one of them, the Wizard Book.

Why did I choose the Wizard Book over other alternatives? Because I felt that learning and practicing examples in Lisp would bend my brain in new directions. You see, I’ve learned that the sort of work I like best is the sort of work that lets me work directly with “the business” and deploy code every day. These sorts of collaborative, fast-paced situations are typical of startups, so when I practice, I focus my practice on becoming a better “startup developer”. I’m not learning Lisp so I can write my next project in Lisp, but I am planning on taking what I’ve learned and applying it to help me write more expressive code more quickly, which is super-important in startup-land.

Why didn’t I choose to spend time on a tournament or a kata? I’ve done the code competition thing and I know how much fun it can be, but I think it would provide diminishing returns for me right now. I’ve done kata, but since I’m self-taught, I prefer to couple practice with reading since I’m light on theory. Both of these types of practice could help me be a better “startup developer”, but I felt that the Wizard Book fit best for me right now.

So, if you’re in the first 5 years of your career (yes, you’re probably still an apprentice), practice as much as you can! Try out a bunch of different types of practice. They will likely lead you into interesting and unexpected places. If you’ve transitioned into your journeyman years and have learned what sort of work you like best, focus your practice!

OK, I need to go for a run now. :)

The Growing Role of UX at Obtiva

Fri, 11 Sep 2009 17:07:00 -0500

[P]eople are recognizing that UX work is important, but I don’t think they realize quite how important yet.
Michael Feathers in Thoughts on the Future of the Boutique Software Shop

In his post about “boutique software shops”, Michael pondered the future of companies like 8th Light, Obtiva, Hashrocket and Edge Case. I can’t speak for those other shops, so I’m going to focus exclusively on Obtiva in the post. Except for this: these 4 shops, along with others like Atomic Object and Relevance, are slowly but surely starting to connect with each other and form a loose network of businesses that I predict will create some interesting opportunities for themselves and for our industry in the years ahead. But that’s a different story.

Michael’s point about the importance of UX for “the high-end restaurants of software development” was bang on in my experience at Obtiva. We started as a developer shop, and we’re still more focused on development than other activities like coaching, training, or user experience. That said, the role of UX has significantly increased for us over the years, particularly since we started our Software Studio in 2007.

In the past, when Obtiva has used a design firm for a customer’s user experience needs, we have sometimes had our customer engage directly with the design firm. To stick with Michael’s restaurant metaphor, this is like asking a restaurant customer to interact with two different servers who are collaborating to serve a single meal. Not surprisingly, this situation was annoying for our customer. Even if we acted effectively as a single team, the customer still had to negotiate with two different companies. Lesson learned: now we act as a subcontractor to design firms, or vice versa, so customers have a more coherent experience.

Michael goes on to say…

[I]n a high-end restaurant it is completely about the user experience. Everything is subordinate to that. I don’t mean subordinate in the sense that if a customer wants a quick and dirty burger rather than what is on the menu he’s going to get it, but rather that he’s going to get something special which reflects someone’s deep knowledge of the art of cooking, something which they can’t get any place else. Now, here’s the trick. That thing which constitutes that specialness in software probably isn’t clean internal structure. It’s more likely wonderful experience as a customer both in the engagement and in their experience of the application. To put it more boldly: it’s not that development teams need UX people, it’s more like UX teams need developers.

Michael’s bold statement overstates it a bit, but the spirit of the statement is true. In the past we may have needed a little design work here and there, but these days we find ourselves partnering with firms like Webitects (who presented at Agile2009) on projects in order to give our customers the sort of exceptional experiences they expect. To be clear, Webitects employs some of their own developers. And Obtiva employs a few of our own designers. But when either firm is faced with a project that requires deeper knowledge of a discipline that the other firm possesses, we partner.

Michael’s next point is near and dear to my heart…

What do you need to be a world class Chef? You need an incredible work ethic, talent, and taste. It’s hard to find all of that bundled in a single person, but typically the people who have it rise through the industry. Steve Freeman was telling me a story the other day about a master Chef who got so angry at his crew that [he] threw them all out of the kitchen and did the entire service himself. He was a master because he could do it all.

Two weeks ago, Jeff Patton and David Hussman gathered 12 agile developers and UX practitioners at Obtiva’s office to discuss what the two communities could learn from each other. Most of the people there were community leaders, people like Brian Marick, Ward Cunningham, Alan Cooper and Hugh Beyer, so they were often looking at things from a macro level. Being the inexperienced one in the room, I was looking at things from a micro level. It is (currently) less interesting to me to figure out how to get two communities to come together than it is to encourage developers to learn the fields of User Experience Design. I see this as similar to how Extreme Programming encouraged many developers to learn about testing 10 years ago. At the end of the workshop I was excited about learning UX because I see it as a crucial step toward mastering the craft of software development. I aspire to be a strong enough software developer that I can take on any aspect of a project, and when necessary, every aspect of a project. Ultimately, I want to work with a team of multi-disciplinary developers, rather than a multi-disciplinary development team. Which one sounds more like a kitchen to you?

If you’re interested in what each of the participants took away from the workshop that day, Ward Cunningham recorded our thoughts and posted them on his Youtube channel.

Be careful what you are good at

Thu, 10 Sep 2009 01:19:00 -0500

Michael Feathers wrote about his shift in focus from people to programming, which got me to thinking. To me, the two pivotal points of Michael’s post were:

He feels himself pulling away from a deeper involvement in teams and organizational change
Be careful what you’re good at

Being the self-centered guy that I am, I immediately wondered how I might fit into Michael’s post. I feel similar to Michael about pulling away from a deeper involvement in teams and organizational change. One of the reasons I felt compelled to start Obtiva’s Studio was because I had grown more interested in developing software than consulting. Coming from my previous career as a family therapist, I suppose I shouldn’t be surprised by my tendency to move from people into programming: I was drawn from a people-centered career into one that involves a balance of technical mastery and teamwork.

Michael’s post sort of implies that there are only 2 activites for him to choose from: 1) agile transitions, and 2) legacy code improvements. I think I know what he’s saying when he advises us to “be careful what you are good at.” Michael is probably better than most everyone on our planet at these 2 complex endeavors, but it sounds like he’s reached a point where they have become less interesting. Maybe I’m wrong about that? Michael can correct me. :)

But he makes a super-important point: be careful what you are good at. I have found myself purposely holding myself back in certain situations because I didn’t want to distinguish myself at something that I didn’t enjoy. I feel strange about that, but I feel like it has helped me grow into a role where I am best suited. Now, imagine writing a book about legacy code but not enjoying improving legacy code. Or writing a book about apprenticeship but not enjoying apprenticing people. Can it actually be dangerous to blindly do your best with every opportunity that comes your way? Do you risk finding yourself promoted into a role that you’d rather not be in? For instance, should you write a book just because a publisher has agreed to publish it?

I think one of the critical tasks to maximize your career is to know yourself. It sounds like for Michael, he has recognized that learning and sharing the deep, fundamentals of programming are what makes him tick. I have recognized that working closely with startup founders and delivering rapidly for them energizes me like few other activities. What makes you tick? Are you carefully becoming good at that activity?

Who are you comparing yourself to?

Tue, 01 Sep 2009 08:25:04 -0500

One of most important moments in my 9 year career came in year 2. I had spent the previous two years diving head first into Perl and had quickly become a strong-ish Perl developer. But then I saw some of the leaders in the community talk about books and ideas that were not Perl-specific, and they made it sound like reading these books (like “Code Complete”) and understanding these ideas (like Functional Programming) were important. Intimidated but interested, I branched out, started reading fewer Perl books, and eventually wandered onto Ward’s wiki. It was there I first learned about Extreme Programming. Soon after I grabbed a copy of Kent’s white book and I was completely hooked: he was describing the way I wanted to spend my working days. I found out the XP conference was going to be near Chicago that year so I paid my own way and took some time off work to attend. It was there that I had that uncomfortable, critical moment: I discovered a group of people who were many orders of magnitude beyond me in the knowledge, wisdom, and implementation of complex software systems. It was overwhelming, but inspiring.

To me, these moments are the hallmark of a successful conference. So many of us can quickly grow into big fish in little ponds and it’s important for us as craftsmen to connect to the larger pond and witness the mastery of the people ahead of us. This was one my goals for Software Craftsmanship North America: to help our community achieve an accurate self-assessment. Our speakers continually pointed at foundational books and concepts that we need to understand: Michael Feathers pointed us to the Wizard and Dragon books, Paul and I pointed us to the Mythical Man Month and the Pscychology of Computer Programming, and Uncle Bob pointed us to Structured Design and studying the Quicksort algorithm. I doubt anyone left SCNA with a warm fuzzy feeling of competence. I believe all of us came away with a uncomfortable (or overwhelming) feeling of how far we each have to go on the long road to mastery.

One of the things that motivates me to continue on that road to mastery is comparing myself to masters rather than the average programmer. I don’t want to slip into the false sense of confidence that comes from localized success. Just because I’ve reached a few small peaks doesn’t mean I should look down around me and feel satisfied, it’s when I’m on those peaks that even higher peaks are most visible! I haven’t worked with Fred George on a project yet, but I have the sneaking suspicion that he is one of the few practicing master software craftsman on our planet. When I get a warm, fuzzy feeling about the success of Obtiva, Mad Mimi or the publication of my book, I motivate myself by thinking about Fred. The guy loves delivering software more than anything, and he’s been doing it for decades. Why do I call him a practicing master? (I’m using the term “practicing” in the sense of actively engaged, like a “practicing physician”.) Because he’s still actively delivering software under the constraints of a business! He is not a trainer (though he constantly trains his people) or a consultant (though he engages people at every level of his company), instead he stakes his reputation on delivering software for a business, and he delivers. I think we need more of our masters behaving this way.

(Inspired by Seth Godin)

Alternatives

Sat, 08 Aug 2009 11:16:08 -0500

My colleague and friend Todd Webb and I were riding the train to the office discussing my motivation for writing my Breeding post. Todd is very good at asking questions and our conversation helped me verbalize my motivations for a couple ideas I’ve been pushing recently. The two ideas are that:

Software developers can remain technical for their entire career
Software developers can become exceptionally good at what they do AND enjoy marriage and parenthood

One of my goals for Software Craftsmanship North America is that the attendees are exposed to alternative career paths. Our speakers have all had extraordinary careers. They have all had opportunities to trade in their credentials for better pay, better titles, and a more normal-sounding life. But they have all chosen to cultivate their craft, to not allow themselves to stop doing what they love, even as they’ve broadened their careers into writing, business leadership, project management, and coaching. I want people to understand that while this sort of career isn’t normal, it is possible, for far more people than are currently choosing it. And we need people to choose this alternative path. We need people to retain their ability to code, even as they develop skills in user experience, business analysis, exploratory testing, marketing, and sales. As our technical tools become increasingly powerful and technical knowledge becomes easier to acquire, the opportunities for generalists and multi-talented individuals will flourish. The result is that in the coming decades, our generation will bring up more master software craftsmen than any previous generations.

My primary motiviation for blogging about Obtiva’s birth and divorce rates was not to pimp Obtiva (that was a secondary motivation :), it was to simply share some statistics that might encourage some geeks who are weighing the pros and cons of marriage and parenthood. Similar to my motivation with SCNA and lifelong programming, I believe there is power in alternatives. My thinking about these alternative paths stems from my training in graduate school.

I was trained as a family therapist in an approach called narrative therapy. Fundamental to this approach is the notion that we live our lives through the lens of our stories about the world. These stories are constructed socially, usually derived from the stories of our parents, our families, our friends, and our cultures. Often, the psychological troubles that people face can be traced back to unhelpful stories (or narratives), and usually these unhelpful stories are dominant cultural narratives, such as: a beautiful woman is a thin woman, or the sign of a successful person is his bank account. Now, it’s not that these dominant narratives are wrong. There are most definitely a lot of thin, beautiful women in the world. Just as there are many successful people who have a lot of money in the bank. The problem comes when these narratives dominate a person’s life to their detriment. If thin is beautiful, then thinner must be more beautiful, right? If money means success, then more money means more success! And so part of what narrative therapists do is help people find alternative stories, exceptions to the dominant narratives, and help people build up their own narratives that better fit their lives. Because it is absolutely possible for a woman to be beautiful and not thin, and for a person to be successful without having a lot of money in the bank.

Nine years ago, I chose to become a software developer because I fell in love with the creative act of crafting software. My definition of success for me has always been that I love my job while providing for my family. I hate the idea of yearning for retirement. I understand that life is a reality for many people. But I am lucky, I found a career I love that pays well enough to sustain our family. I am not alone! Geeks all over the world have discovered the power of software development and have experienced its rewards. What breaks my heart is when I see some of them giving up what they love in order to move up an organizational chart. Several years later, they hate their jobs and have fewer career options because their concrete skills have atrophied. If you enjoy what you do, cling to it. Cultivate it. You can have your cake and eat it too. And it tastes great.

Breeding

Thu, 16 Jul 2009 10:48:23 -0500

been around the world and found
that only stupid people are breeding
Flagpole Sitta, Harvey Danger

As Obtiva has grown to about 20 people in the last few years, we made a key decision that was guided by a simple principle. We decided to make Obtiva a Chicago-focused company. At the time, this felt like a big move to me, but it’s actually not that big a deal. After all, Chicago is an enormous city with a ridiculous number of businesses that need our help. We made this decision based on a principle that our founder Kevin Taylor has often repeated to me: “We’re not going to ask Obtivians to do anything the owners of Obtiva wouldn’t be willing to do themselves.” Since Kevin and I both have kids at home and place a ton of importance on seeing them everyday, we’re not going to ask people to travel very often.

What strikes me (and is a source of pride for me) is how we’ve been able to cultivate a developer-friendly culture while creating an environment where families flourish. This is a stark contrast to my time at ThoughtWorks where there was a signficantly high percentage of people who were divorced, single, or married without children. Now, there’s nothing wrong with singlehood or marriages without children. And while there are certainly valid reasons for getting a divorce, I think most of us can agree that divorce sucks. I feel stupid even having to say that. But families and children are the foundation of our society, and it certainly is a good thing for our country to have a strong birth rate relative to the rest of the world. Yet, I’ve heard echoes of Harvey Danger’s “Flagpole Sitta” lyrics among some of the software elites I’ve hung out with. I still get looks of shock (and sometimes horror) when I tell people I am married and have 3 kids. I don’t blame anyone for being surprised, my situation is just not normal for people my age, I guess. Over time though, I’ve definitely picked up on the vibe that you’d have to be a bit stupid to sacrifice your career, your money, and your freedom to raise a family. But now I find myself helping to lead a company of very smart people who are doing exactly that. These people love delivering software, and they love delivering babies too.

In Obtiva’s four year history, we’ve had 6 births, 1 adoption, 2 marriages and 0 divorces. We currently have 14 married people who have 21 children, with 4 more kids on the way, which includes our first pregnant programmer. There are a ton of stories behind these numbers. And while they’re just numbers, I find them to be significant. Maybe companies like Obtiva are the norm? I’m not sure, it doesn’t feel that way to me. I do feel that these numbers are good indicators that:

We’ve stayed focused on local clients
We work at a sustainable pace

After all, when you’re on the road all week or in the office late at night, you just don’t get as many opportunities to make babies (with your spouse).

50% Time

Wed, 24 Jun 2009 08:56:00 -0500

A couple weeks ago, Uncle Bob tweeted:

At the time I was finishing Malcom Gladwell’s Outliers, a book that digs deep into the stories and counter-cultural explanations of successful people. Having someone so close to my context tweeting about a topic related to the book I was reading helped me see something I hadn’t noticed before. I’ve spent years trying to make sense of how a person evolves from a novice programmer to an accomplished software developer. And up until now I haven’t paid enough attention to the raw number of hours spent deliberately working to improve oneself. Uncle Bob calls us to work a sustainable pace in our day jobs (40 hours), so we have time (20 hours) to improve ourselves in the off-hours. Most people don’t do that, though. It’s not considered normal. People who spend time doing more of what appears to be their job in the off-hours are seen as obsessed or workaholics. Maybe we are, there is some grey area there, and I know I’ve taken it too far before. One of the ingredients to being an outlier, though, is an opportunity to work hard. Sure, many outliers have had some good breaks, like being born in the right decade (American entrepreneurs in the 1830’s) or even the right month (Canadian junior hockey players in January), but that luck only provided them with an opportunity to work hard at something that they wanted to do.

I’m not calling myself an outlier, but I certainly aspire to be one. In the little corner of the software development world that I live in, we call our outliers master craftsmen. My journey toward mastery began in an uncommon way. I started programming when I was 26, after I was married, after I had children, and after my wife and I decided she would stay at home with the kids until they were older. For better or worse, I also suck at personal finance (ever so slowly getting better at it), and that means that I have a fairly constant pressure on me to make sure I’m increasing my income. All of those forces provided me with an opportunity/motivation to work hard on an activity I enjoy while limiting my “day job” hours to 40. Uncle Bob’s tweet took me back to 2001 when my interest in programming exploded. Thanks to the constraints that my family provided, I stood my ground on working no more than 40 hours with my employers. But once the kids and Staci were asleep, I was working on my own projects, reading programming books, and blogging about what I was learning, all with free or very cheap tools and information. I didn’t sleep much between 2001-2007, and I had never considered condoning that sort of obsession in anyone else. It was certainly a sacrifice, and took a toll on my health and my marriage. Looking back on it, though, I realize that this sort of intense effort is what makes a successful apprenticeship.

And so I find myself looking back on 2 years of Obtiva’s apprenticeship program. We’ve had 6 people join us as apprentices, and I’m seeing some patterns. I’ve learned some things that I will look for in future apprentice candidates, such as what they do in their spare time. Are they already contributing to or reading open source? Are they working on side projects? Are they already blogging and/or tweeting about what they’re learning? Are they seeking out book recommendations? These are the sorts of behaviors that indicate they will likely be successful apprentices. As their “boss”, as an owner of Obtiva, I’m certainly not going to require anyone to work more than 40 hours. So I’ve found myself fooling myself into thinking that if only we could make those 40 hours as positive and learning-friendly as possible, apprenticeships will flourish. I fooled myself into thinking that if only I had had a “real” apprenticeship, I wouldln’t have had to spend all those sleepless nights striving for mastery. But nowadays, I’m getting the feeling that there really is no substitute for those 20 hours devoted to your own self-improvement. The 40 hours will teach you all sorts of things, but that time is constrained by business concerns, and this is a good thing, it’s a healthy dose of reality. The 20 hours are yours though, constrained only by your energy, passion and boundaries.

I worry that by blogging these thoughts our current and future apprentices will feel I’m implicity requiring them to spend 20 hours per week outside of work on learning activities. First off, I can’t legally do that in the state of Illinois. But secondly, I don’t want you to do it if you don’t want to do it. I only worked that hard because of the pressures I had on me and because I genuinely enjoyed the process. I think it would be silly to try to force yourself to do it, you’d end up burning out. Really, I’m talking to two groups of people. To those who are already spending their spare time on becoming a better developer, I want you to know that your efforts will pay off, but understand that it will take between 5-10 years to see the most significant benefits of your efforts. To those who want to become a great developer but hold themselves back out of fear of failure or hard work, I hope to inspire you to give it a shot. We work in an exciting field and everything you need to become great is available to you.

I’ll leave off with my favorite quote from The Mythical Man Month:

To only a fraction of the human race does God give the privilege of earning one’s bread doing what one would have gladly pursued free, for passion. I am very thankful. p. 291

Fails on Rails

Tue, 23 Jun 2009 10:55:29 -0500

Todd and I met with a couple guys last week who are in the process of bootstrapping a web startup, specifically, a web startup using Ruby on Rails. First off, I need to say that I love talking with people who are trying to bootstrap, especially when these people are in Chicago. We have such a huge amount of talent around here, but too many of us are unwilling to take the red pill and be measured. But I digress. During our discussion, I was trying to explain to the non-technical, though passionate and inquisitive, startup founder the advantages of using Rails. I found myself telling him something that surprised me:

The total cost of development for a successful Ruby on Rails system is probably not that different from a successful Java EE system.

To be clear, I have absolutely no data to back that up, other than my gut instincts after working on Java and Ruby projects for the last 7 years. The point I was trying to make to the startup founder was that while total development cost might be the same, the time to market with Rails was much faster. A startup founder who chooses Rails is putting a priority on getting her vision out into the real world as soon as possible. Once her idea is out there, the work is far from over, though. Ruby is a relatively slow language, and that means that as you have success, you are going to need to optimize or replace the bottlenecks in your system sooner than you would with a faster language. If you’ve built your system correctly, though, these improvements should be relatively straightforward thanks to Ruby’s amazing conciseness and flexibility.

As Todd and I were walking back to the Studio, I was thinking about what I said, and I realized there was a flip-side to my first assertion:

The total cost of development for a failed Ruby on Rails system is much less than a failed Java EE system.

There’s a good reason this line of thinking didn’t come to me while we were talking with the startup founder. The guy was infectiously enthusiastic about his business, and talking with him about its failure didn’t even occur to me. But I think that like Agile Software Development, Ruby on Rails gives visionaries the opportunity to fail fast, learn from their first attempt, and regroup for a second effort. Or in the less likely event that they succeed, Rails is no less capable than any other platform to be optimized, tuned, or chunked into separate sub-systems in order to scale.

Power and Resposibility

Thu, 30 Apr 2009 06:44:00 -0500

I’m always a few degrees separated from current events in technology, so the conversations are already dying down about the GoGaRuCo CouchDB presentation while I’m just getting up to speed. So if you’re even further removed than me and don’t know what I’m talking about, please educate yourself about the situation by reviewing the offending presentation, reading the presenter, Matt Aimonetti’s, response, reading the conference organizer, Josh Susser’s, response, and finally, Liz Keogh’s thoughts on the topic.

I usually stay out of software community drama, but this situation is impacting people that I care about and I feel compelled to state my opinion publicly. One of these people is Victoria Wang and the other is Leah Welty-Rieger. I feel a responsibility to both of these women because they either worked for Obtiva or are currently working for Obtiva. And it’s not just that they worked for Obtiva, a company that I own a part of, these women work/ed closely with me, and I hold/held a position of power over them.

And I agree with Liz on the topic of power. People with power don’t have the luxury of absolute creative freedom. I mean, they do actually have that freedom of course, but there will be repercussions when you wield that power, even with the best of intentions. Matt was in a position of power when he gave his presentation, and once you’re in that position, you can’t rely on people understanding where you’re coming from when you color outside the lines. Once you’re in a position of power, you need to consider where other people are coming from. Once you’re in a position of power, you are representing many different things to many different people and you shouldn’t be surprised when a misstep has unforeseen consequences.

The consequences in Matt’s case was that many women in our community were offended, including Victoria. And when we discussed the situation with Leah yesterday afternoon, she was equally offended. I want Victoria, Leah, and all future Obtiva geek women to know that the sort of humor that Matt was attempting is not OK with me. I believe presentations like that contribute to the objectification of women. Call me a prude, mid-western American, but I feel compelled to give my opinion so that there isn’t any nagging doubts in the minds of my female colleagues.

This is not about understanding where Matt was coming from when he decided use those images of women. Instead, people in positions of power, like Matt and me, need to consider where our audience is coming from, particularly people in the audience who are in the minority. Please consider the power that you have when you are in positions of authority. This situation has certainly been a reminder for me that I need to consider the power I wield in my many relationships at Obtiva and with my family.

View Source

Mon, 20 Apr 2009 00:23:00 -0500

Jason Gorman riffed on a blog post by David R. Heffelfinger in which David was lamenting the move away from the sort of setups that computers of the 80’s shipped with. Specifically, David misses BASIC and the way that “it was expected for end users to write their own applications.” According to David, ever since the 90’s, it has become increasingly difficult to simply buy a computer and start programming…

So I wonder, how do new generations of software developers get their start? It is not as easy to “get your feet wet” these days like it was back in the day. —David R. Heffelfinger

I can tell you from personal experience how the new generation of software developers get their start. It’s called “View Source”…

It was almost exactly 10 years ago this month that I was sitting in my 1 bedroom apartment in Seattle, a couple months from completing my master’s degree in family therapy. I worked construction in the mornings, I had an internship in the afternoons, and classes every night. My daughter Rose was a few months old (she slept in the closet) and we were planning to move to Chicago to be closer to Staci’s family. I was, not surprisingly, looking for ways to supplement my income and had fallen in love with the World Wide Web over the previous 3 years. A friend had tried to explain HTML to me and showed me that you could tell your browser to show you the code it was running. So I started periodically perusing “web page code”. It was reassuring that there was so much English in there, and this made it less intimidating when I decided to learn HTML in order to apply to become a guide at About.com to earn some extra money. I learned by typing HTML into Notepad and executing it with Internet Explorer. A few months later, I did the same thing with JavaScript.

So although David says that in the mid-90’s there weren’t many baked-in options for programming, by the late 90’s we were back in action. And we still are. Is there an operating system that ships today that doesn’t ship with a web browser that runs JavaScript and a text editor pre-installed? Is there a web browser that doesn’t allow you to “View Source”? And the best part about the whole thing? The software that’s running your code usually has Google built into it! Any question you could ever think to ask about HTML or JavaScript is milliseconds away. Seriously, I can’t imagine learning how to develop software without having a web browser at my beckon call. How did those BASIC guys do it?!? (I know I tried and failed with BASIC on my Apple IIe in ‘87.)

Now, I’m sure there are some purebloods out there who are rolling their eyes at me, concerned that I would hold up coding HTML and JavaScript in Notepad and Internet Explorer 5 as the replacement for BASIC and a command prompt.

But that’s exactly what I’m saying. It’s amazing how powerful these 2 languages are when combined with free, instantaneous, and limitless information about them and a world-wide delivery mechanism to let newbies show off their skills. Combine them with a free server-side language like PHP and a free database like MySQL, and people’s lives start changing. Now, again, the purebloods will likely curl their lips and lament the hordes of incompetent programmers who haven’t learned the correct theories, who inflict untold damage on the term “programmer”. But be careful who you push away when you start pushing away these newbies! I guarantee there are some future world-changers in that bunch. People like, say, my friend Obie who has a similarly bootstrapped career.

Sure, many of these developers will not ultimately succeed. And, of course, many of them will write horrendous code along the way, just like so many of us did as we learned from our mistakes. But I view these hordes as an opportunity rather than a problem. What these readily available tools mean to me is that our apprentices always come to us with existing skills. I never get a blank slate. Because if you’re interested in becoming a software developer and have access to a computer, there’s nothing stopping you from starting other than your own lack of motivation. And if you are applying to become a software apprentice at Obtiva, then you’re obviously motivated. Therefore, the ubiquity and relevance of tools (such as web browsers, HTML, and JavaScript) allows our apprentices to become productive members of our teams more quickly. And with these skills in place we can get down to the more interesting business of helping them learn the deeper lessons of our craft.

Sudoku Scanner

Fri, 17 Apr 2009 01:26:00 -0500

A few months back I was riding the train home from the Studio. I had recently finished a big writing push on my book and so I finally had some free time on the train again. So I just sat there for a while doing nothing (not as easy as it sounds). That’s when I noticed a woman playing Sudoku. I considered passing the time by playing Sudoku myself. And then I remembered writing an unbeatable Tic-Tac-Toe robot and how much more fun it was than actually playing Tic Tac Toe. So I got it into my head that I wanted to write a Sudoku solver. So I did. I put it up on GitHub for all to see. And then Jim Weirich did the same. And then Corey Haines did too.

For the next couple weeks I was a obsessed with the solver and was always blabbing about it at geekfest. And that’s where the idea of a Sudoku Scanner was born. I decided then and there that I would write some software that could comprehend a photo of a Sudoku board. I burned the midnight oil on more than a few nights researching the domain, stumbling through problems, and rewriting solutions, but eventually I got my 4 test photos scanned perfectly! And I’m excited to announce that in the upcoming weeks, we will be launching a web-based version of the Scanner which should help us get more diverse test data to improve its accuracy.

I’ll probably do another rewrite in the coming months thanks to an excellent Neural Network lesson from Aslak Hellesøy at speakerconf. I’ve also received a ton of excellent ideas, feedback, and support from my fellow Obtivians, particularly Nate Jackson and Tyler Jennings. And I can’t not mention my friend and customer, Gary Levitt who generously developed and donated the Sudoku Scanner website’s design.

My Take on Master Craftsman Teams

Sun, 05 Apr 2009 05:00:00 -0500

I enjoyed reading Uncle Bob’s post on Master Craftsman Teams. My first reaction was that I was happy that Bob was focusing on the people-side of software craftsmanship to balance out his ongoing message of technical excellence. My second reaction was that of being slightly amused since I knew that Bob was theorizing and proposing these ideas based on his decades of experience, but not based on an actual team that’s using the exact structure of 1 master, 3 journeymen, and 9 apprentices. I was amused because I know how much people respect Bob (myself included) and I knew that they would take his description very seriously.

Some people did take it very seriously and the comments are still coming in. Many of them are excellent, some are misguided, and I’m going to share my thoughts on them in this post. I feel compelled to post this in parallel because I have focused a lot of my time and energy on software craftsmanship, and specifically apprenticeship, over the last six years. I feel like my experiences could shed some light on Bob’s ideas. I know that there are other people like Micah, Paul, and Karl who could chime in with their experiences too, and I hope they do.

The most interesting theme that has come out of Bob’s post is that of education. Bob asked:

Why should a young aspiring software professional spend four years and $200K+ to attend an institution that will teach them less about their chosen profession than 3 months of working on a real project with talented mentors?

Not surprisingly there were some people who disagreed with Bob’s take on this. Unfortunately, many took Bob’s post as an all-or-nothing proposition. As if Bob would be in favor of completely shutting down all university computer science education.

Ronald Woan commented:

I would hate to start signing people up out of high school for a career in software development.

I assume Ronald means that he would hate if that were the only way people became software developers. Because there is certainly nothing inherently wrong with people trying to become software developers right out of high school. Nathaniel Talbott was an apprentice right out of high school and has become a successful software developer and entrepreneur. My company’s third apprentice was hired at the age of 20, lacking any formal training in software development. He has been a constant source of innovation and technical excellence since the day he was hired.

Several people brought up the idea of either intermixing apprenticeship and formal education or going back to school after you’ve learned enough to know what you need to learn. I think there is a lot of potential in both of these ideas. Jeff didn’t like Bob’s proposal because he thinks it would “rob the profession of prestige” and thought Bob was being “unfair and reductive about what CS students learning college.” But Jeff goes on to say that he was in fact self-taught and has gone back to school recently to get a MS in computer science. I think this idea of experienced software professionals going back to obtain formal education makes a lot of sense. As a self-taught software developer, I can imagine how much more effective this education would be for me now compared to when I first started programming.

Jeff comments again later:

As I said above, turning software engineering into the sort of profession that does not require a college education will greatly reduce any prestige associated with the field.

I feel the need to point out that software engineering is already the sort of profession that does not require a college education, so what Bob is proposing isn’t earth-shattering. To be clear, one of Bob’s points is that the ever-increasing cost of a college education has in many cases exceeded its value. If someone is already motivated to learn a specific subject, an apprenticeship is probably a better choice than an expensive college degree. When I was 18, I wasn’t a motivated learner, so college made sense for me because I still had a lot to figure out. I majored in psychology and learned all sorts of things that have helped me in my subsequent careers. When I was 25 I discovered I had become a motivated learner during graduate school. And when I needed to make some extra money after my daughter was born, I taught myself HTML. This learning process eventually morphed into me teaching myself how to develop software and eventually I forged my own apprenticeship. Along those lines, Renzo points out that what you learn in college, regardless of your major, can benefit you as a software developer:

Why not learn physics, maths, chemistry or other high abstraction disciplines with the specific goal to move to computer science right after? I know a lot of successful examples of cross-discipline CS professionals and the success seems to depend on their ability to think “differently” than the subject of their studies.

Brad Appleton proposed combining “college education and on-the-job training together, in some kind of work-study vocational program,” which I think has merit. Michael Hunger solidifies this idea by relating:

In Germany we have an apprenticeship education for all people not going to University. They work part time in companies to learn their craft and part time go to school to get some additional theoretical background.

This approach sounds like it has legs. Michael also reaffirms Jeff’s approach to going to school “AFTER gaining practical experience.”

I was surprised that I found myself disagreeing with Michael Feathers in his comments:

I don’t think any of us can conceive of a world where seat of the pants learning ever replaces institutionalized education for the bulk of the industry.

Well, it’s not hard for me to conceive of that world. That’s the world I live in, and most everyone I’ve met in the industry lives in that world, regardless of their academic background. In fact, some of our brightest people at Obtiva have either no college degree or have a degree in philosophy, economics, or theology. We’re professional learners. We’re learning to become great software developers. Craftsmen even. How is this possible? The INTERWEB and Open Source! The barriers to expert knowledge have largely been removed by our ability to instantly and cheaply access endless amounts of online discussions, articles, books, screencasts, and source code that pertain to problems we are solving. I think the bulk of our industry does not actually need much school-taught computer science theory for the majority of what we do, and that these things could be self-taught later, or we could use computer science specialists as mentors and implementers for tasks that require these skills. What our industry needs most is people who are passionate about learning and can communicate effectively with their customers.

Michael also commented that:

When you learn theory you gain a startling amount of practical insight into problem solving. Programmers who don’t do a rigorous CS degree are lucky if they find it on their own. Most won’t, even with apprenticeships. It doesn’t have to be that haphazard.

I disagree. Programmers who don’t do a rigorous CS degree can gain that insight through hard work and a lot less money. I suppose there may be some luck involved, but mostly it’s about reading a ton of books, coding all the time, and setting up learning opportunities for yourself by seeking out great mentors. Plus, you can always go back to fill in some gaps by taking courses after you’ve identified the holes in your knowledge.

Another theme of the comments was on the difficulty of finding master craftsmen. Pascal was one of the early commenters on this topic and it sounds like he has had a rough go. The most experienced programmers he worked with were “terrible mentors” and “kept some bad habits from their Fortran days.” Pascal thought “four years” was a better threshold for master craftsman in his workplace. And I can’t argue with him. He was talking about his experiences and his workplace. But it’s also very sad that this is true for him.

There seems to be a belief that master craftsmen are impossible to find or retain. I think this is bullshit. Ronald Woan lamented:

The master programmer is very difficult to scale even in smaller organizations. Most organizations can’t even afford to recruit and retain one that many of would think to qualify for this level.

It’s not that organizations can’t afford a master craftsman, they simply don’t understand how to attract them. The organizations that could most easily afford them (the large ones) are almost always full of middle managers who want to manage as many people as possible so they can tell their next boss, “I successfully ran a 50 person project.” These people are going to be much more interested in hiring several mid-level developers than hiring a single master craftsman who makes more than they do. Consider how much money a 30 person application development department spends on its people. Now, I wouldn’t propose a structure exactly like Bob’s, but I do believe that having a master craftsman is critical, along with a healthy mixture of apprentices and journeymen. I assert that a 30 person application development department could be replaced with a team of 10 craftsmen for half the cost and would deploy better software more frequently. Yes, some of those people would make a lot of money, but it’s still less than what you were paying before.

The team ratios that work for us at Obtiva is 1 master, 6 journeymen, and 3 apprentices. And to be clear, we don’t actually have a master, we are growing them. My job is to play the role of master craftsman while learning how to become one. I think the “grow-your-own-master” model can work well for small organizations who can’t afford an established master craftsman and have a solid team of journeymen.

While we’re talking about apprentices and team structure, I have to agree with several commenters that I would not make throwing away apprentices’ code a standard practice. In the 2 years since starting Obtiva’s Studio, I have brought in 6 apprentices, so I have some experience on this topic. I think there is an assumption that “apprentice” means a blank slate, someone without a clue about what they are doing. In my experience, thanks to the INTERWEB and Open Source, our self-taught apprentices all come to us with some practical experience. If you’re motivated to become an apprentice, then you must be motivated to at least build some toy projects on your own, before you even start. And that’s always been the case for us and while our apprentices have made mistakes, we rarely throw their code away. More often, we would pair program with them and refactor it into a better design.

By the way, our most recent apprentice was fresh out of university, where he got a computer science degree at Carthage College. He has been highly successful thus far and his computer science degree prepared him well for his daily work with us.

There were also some concerns raised about the master craftsman taking on too much leadership versus allowing the team to self-organize. We encourage our teams to be self-organized. There is nothing inherent in software craftsmanship that prohibits self-organizing teams. Naturally the master craftsman and senior journeymen will tend to be in leadership roles, but we often have apprentices speaking up and questioning decisions, and ultimately influencing our projects’ direction. Along those lines, a few commenters raised concerns over the structure of a traditional master/apprentice relationship. I hope that people understand that the apprenticeship experience can be incredibly diverse, and can vary widely between one organization and another. Being self-taught, I have always felt that an apprenticeship is the responsibility of the apprentice. It’s not my job to act like a professor or a drill sergeant for our apprentices. Master craftsmen and journeymen are certainly accountable to guide the apprentice in the right way, but ultimately the apprentices must take responsibility for their learning. An apprenticeship is a learning activity, not a teaching activity.

I believe our field, along with our entire society, has fallen into the trap of believing that we need to be taught, rather than believing that we need to learn. We need to create ideal learning situations for ourselves, and especially for newcomers to our field, in order for us to continue advancing the state of our art. We need to create better learning situations both in our academic institutions and our workplaces, and I’m beginning to see that this may be best accomplished by finding ways of intermingling these contexts.

In a society which emphasizes teaching, children and students — and adults — become passive and unable to think or act for themselves. Creative, active individuals can only grow up in a society that emphasizes learning instead of teaching.
A Pattern Language, p. 100

Choosing Measurement and Leverage

Tue, 24 Mar 2009 22:35:00 -0500

I’ve spent almost my entire software development career in Chicago. I say “almost” because the seeds of my career were planted during the years before and after college when I lived in Seattle. It was in Seattle in 1999 that I taught myself HTML to get a side-gig at About.com. It was near Seattle in the 1980’s that I watched Microsoft work its way from a little building near Burgermaster, to 4 buildings across the highway, and eventually took over a huge, ever-expanding campus in nearby Redmond. It was in Seattle that I watched Amazon shape the world of ecommerce. I did some temp work just before I started grad school in 1997 and remember seeing notices in the temp office about warehouse work for something called “Amazon”. Watching these technologists’ ideas come to life and generate wealth for so many people in the Seattle area made an impact on me.

10 years ago my wife, my daughter and I moved to Chicago from Seattle. I love Chicago. I was born here, I went to college here, I have a lot of extended family here. I feel connected to this city and love walking around the Loop on a weekday. It just feels so alive. Much more than Seattle. But Chicago does not love technology and innovation like Seattle does. One of the great aspects of Chicago business is that it loves many things. Its business interests are incredibly diverse, which helps it weather economic storms better than most. But without much love for technology and innovation, Chicago’s best technologists are typically drawn to the most lucrative businesses to support. The most lucrative businesses for technologists in Chicago has been, and remains to be, finance. I quickly learned that most of the best and brightest of Chicago’s technologists gravitated to finance, and were making some great money there. Naturally, and especially as my family’s sole-income-provider, I was attracted to Chicago’s financial industry, just like so many others.

In 2005, I was working for ThoughtWorks. For the first half of the year I consulted at Chicago’s Huge Hedge Fund™. It was amazing. 3 kinds of coffee. As much soda, juice, fruit and ice cream bars I wanted, any time I wanted. Catered lunch every day. Even afternoon snacks. Great equipment too, nice big dual monitors and comfortable chairs. I worked on a team of smart people, led by Jim Northey, a great mentor. I audibly said to myself everyday, “don’t get used to this.” Good thing too. The company did some housecleaning in mid-2005 and pushed out many of its consultants, including ThoughtWorks. I landed at my next ThoughtWorks gig just a couple blocks away at Monster National Bank™. The first week I was there I went through withdrawal for the first time in my life (no more Dove Bars). But it was another great opportunity to work with some great people, like Derek Groothuis, Paul Julius, Mike Ward, Paul Hammant, Ross Niemi, and Ross Pettit.

The upside of these gigs was that I was building my finance resume and setting myself up to permanently join the ranks of Chicago’s finance geeks. The downside was that I didn’t really enjoy much of the work. The most interesting stuff I worked on was building tools to help improve the productivity of those who had to work with these huge legacy software systems. I enjoyed this because what I built was helping people who I was directly working with. The software systems that actually facilitated the businesses were an absolute mess and incredibly difficult to work with. The customers and users of these systems were far removed from me and my teams, so the feedback loops were always very slow and weak. If we screwed up, we fixed it, but it didn’t really bother us. We were still billing our time and working a normal work week. If we blew an estimate, we simply adjusted our velocity. If we did well, no one really noticed. To be fair, these layers and weak feedback loops aren’t always characteristic of Chicago finance IT. My friend Gareth Reeves told me about his days at a small financial firm where he ran an awesome XP shop with tight feedback loops and close collaboration with the business.

Knowing that I wasn’t going to stay at ThoughtWorks long-term (they love weekly travel and I hate it), I started considering my options. By the spring of 2006, I had told ThoughtWorks I was moving onto greener pastures. My manager at Monster National Bank™ caught wind of my departure and offered me a full-time position. I was also considering joining a 3-person, 8-month-old agile consultancy based in the town where I live (Wheaton, IL). The bank was offering a big salary, tons of benefits, 4 weeks vacation, and a hefty bonus. The little company had 2 weeks vacation and I got reimbursed $400 for medical insurance. I had about 24 hours to make my decision. I turned the bank down and joined little Obtiva.

Why?

Well, in 2005 I started reading a lot of Paul Graham. Probably because Hackers and Painters had just been published. This was also the year that Rails exploded. For me, mixing Paul Graham with Rails meant big dreams. Paul’s How to Make Wealth essay had a huge impact on me. Particularly ideas such as…

The people most likely to grasp that wealth can be created are the ones who are good at making things, the craftsmen. Their hand-made objects become store-bought ones. But with the rise of industrialization there are fewer and fewer craftsmen. One of the biggest remaining groups is computer programmers. A programmer can sit down in front of a computer and create wealth.

and

To get rich you need to get yourself in a situation with two things, measurement and leverage. You need to be in a position where your performance can be measured, or there is no way to get paid more by doing more. And you have to have leverage, in the sense that the decisions you make have a big effect.

Therefore, when I was given the option to join the global foreign exchange division of a large financial institution, it didn’t make any sense to me to say yes. I believed that I was talented and hard-working enough that joining a 3-person consultancy would be a better career move than supporting a bunch of filthy rich investment bankers. If I were talented but didn’t like to work hard, then the bank would have been a good move. I could grit my teeth, collect my paychecks and bonuses, look for ways to make more money, yearn for retirement, and try to find some happiness along the way. But, I do love to work hard, and I love taking on audacious tasks, and I love crafting software, and I love being measured, and ultimately, I love making a difference. So Obtiva made perfect sense.

That was 3 years ago. Obtiva is now a 20 person company and I own part of it. I live in a world of incredibly tight feedback loops and deploy software every day to my customers. I believe Paul Graham’s advice about measurement and leverage were bang on. For me it came down to a decision between a large financial institution and a little consultancy. Finance isn’t inherently bad, but I still believe that large is. Consultancies aren’t inherently good, but I will always prefer little companies. These tendencies of mine were formed 2000 miles away, in Seattle, where I watched little companies change the world.

My hope is that this post will offer some insights to people who come to a similar crossroads. Believe in yourself and let yourself be measured! Take the red pill!

Craftsman Swap

Wed, 18 Mar 2009 00:00:00 -0500

In April 2009, 8th Light and Obtiva will each send a senior developer to the other company for a week. Neither will be charging their existing clients for the developers’ time. The presence of the developer will mean exposing client lists, proprietary projects, and the endless details of running a small business to a competitor. 8th Light and Obtiva are both located in the Chicago area and have similar businesses. Why would we open our doors to a competitor? Why would we give up a week of billable time for some of our most experienced people? What are we hoping to accomplish during that week?

First, we feel comfortable opening our doors to a competitor because we trust each other. The trust I have for Micah Martin and Paul Pagel come from knowing them for 6 years, knowing that they were mentored by Uncle Bob, watching them make a difference through their code fests at the agile conferences, and observing their open source work.

Second, we would give up a week of our billable time to swap developers because we believe we can learn from each other. By learning from each other we are going to make each other stronger. By making each other stronger, we are making our companies more competitive. In our conversations about this partnership we acknowledged that we do compete with each other, but more often we are in competition against people and companies that do not share our values. This partnership is a first small step toward building a loose network of small businesses that share the complimentary value systems of Extreme Programming and Software Craftsmanship. We have invited other companies to join this network and are excited to do similar swaps after this first swap in April.

Who would we consider swapping people with? We would swap people with a company that we trusted. I won’t go into detail about how this trust would be established, but knowing Corey Haines probably helps.

Lastly, we hope to establish a deeper trust between 8th Light and Obtiva during that week. The more trust that we have in each other, the more options we will have when we collaborate in the future. Having options is incredibly powerful for a small business because we can so easily and quickly choose the best one, compared to a large company with more inertia. Furthermore, we believe that the journeymen that we send will personally benefit from the experience, and the feedback that they receive and provide will benefit our respective companies. The new techniques and practices that the journeymen bring back with them are going to work their way through our teams as they rotate through pair programmers or present what they learned at meetings like Obtiva’s geekfest.

I will post updates and more thoughts on this fledgling network as we get closer to the swap and set up swaps with other companies. Many thanks to Corey Haines who inspired the idea and facilitated the conversations.

Responding to "Craftsmanship, Quality, Dogma, and Pragmatism"

Thu, 05 Mar 2009 19:21:00 -0600

We had the pleasure of hosting Corey Haines during the week of February 23rd when Steve Smith posted some of his thoughts on Software Craftsmanship. I got to talk with Corey about his reaction, which spurred me to read Steve’s post.

I didn’t have as strong of a reaction to Steve’s thoughts as Corey did, but I did comment on Steve’s followup to Corey’s post. A few aspects of Steve’s original post did jump out at me and I wanted to respond to them here.

Steve said:

I’ve heard from several successful business owners that they don’t want to hire artists and craftsmen devoted to making beautiful and elegant code, they want programmers who can get the job done with a minimum of fuss so they can move on to the next task.

The competitor in me gets energized when I hear statements like these. As a successful business owner myself, I am a craftsman devoted to making beautiful and elegant code. Being a craftsman means being devoted to my clients, and my team and I are committed to deploying business value to them on a daily basis. (We deploy multiple times per day.) We work in messy, legacy codebases, and we work in newer codebases where mistakes have been made, and we work in codebases that we are extremely proud of. We constantly strive to increase the quality and business value of our clients’ software. We believe that simple, beautiful, and elegant code increases its business value, and we take incremental steps toward these ideals every day.

When I hear things like “get the job done with a minimum of fuss so they can move on to the next task,” I think of an assembly line worker. That is not the sort of person I’m interested in hiring. I want to develop software developers who make a fuss when they don’t understand the business value of a feature. Our teams have been working on getting better at questioning our clients about their priorities so that we can better understand their businesses, and therefore provide them a higher level of service as we expand these relationships. Teams of assembly line software developers cannot compete over the long-term with teams of self-organizing software craftsmen.

Steve said:

A software craftsman takes pride in his work, but more than that they should take pride in delivering value to the customer.

I could not possibly agree more with this statement. This is the difference between an artist and a craftsman. A craftsman has a customer, and therefore has to balance an entirely different set of variables than the artist, who is creating something beautiful for its own sake.

If the current Software Craftsmanship movement is in danger of anything, it is focusing too much on techniques and practices, and not enough on the foundation of Software Craftsmanship: long-term customer relationships built on successive software deliveries

Steve said:

In many cases, as Bob Martin says, building quality software makes everything go faster, so trading quality for speed makes no sense. However, in my experience this is only true if the team already has all of the necessary skill to do so. If some or all of the team requires training, and worse, if they are resistant to changing their typical modes of writing code, then trying to deliver higher quality is likely to require significant investment in time and energy. The customer should be the one who gets to choose if this is a worthwhile investment for the project at hand.

For teams that don’t have the necessary skill, yet are aware that they could do better, then I would expect to see steady improvement. I would also expect to see the team bring people on board who do have the necessary skill so that the rest of the team can be mentored. And this is definitely expensive. This expense comes from the debt that is accumulated by a bad team’s ignorance, and the sooner you pay off this debt, the better.

For teams that are resistant to changing their typical modes of writing code: I have absolutely no pity for you. I yearn to compete with you for business. This competition will force you to improve or you will be forced to find a different vocation. I want your customers to witness the power of a team that is constantly evolving and improving the way that they work and are open to new ideas and innovations, and get energized when they leverage newly acquired knowledge in order to deliver value to their clients. Teams that are resistant to changing their typical modes of writing code are a millstone around the neck of our industry. We must either inspire these teams to improve or educate their customers about what they should expect from a team of software craftsmen.