Red Squirrel's Nuts

The Design of Everyday Doors

Sun, 08 Aug 2010 00:28:00 -0500

Back when I first started learning about software design, someone recommended I read The Design of Everyday Things. This book forever ruined doors for me, because up until the time I read it, I felt like a doofus in situations like the one below. But then I’d get on with my day, having chalked up the mishap to my own obliviousness.

After reading the book, I stopped feeling like a doofus. Instead I’d feel frustrated at the lack of insight/empathy that door designers/purchasers had for the people they were designing/purchasing for. And to this day, I still feel this frustration.

My daily routine changed last week when I started consulting full-time at Groupon. There have been plenty of badly designed doors in my daily routine before, and some particularly bad ones at Obtiva, but it’s natural to feel the dissonance of badly designed doors when you’re interacting with them for the first week.

Let me start by showing you the perfectly designed door. You can interact naturally (aka thoughtlessly) with it and get on with your day. This one is at Jimmy John’s on Clinton in Chicago.

Next is what I call the “worst-case scenario” door. Now, I love Groupon as a client. The people rock. And they’re an awesome company with a brighter future than just about any other company on the planet. So it’s a little mind-boggling that it’s their front door that has the worst design a door can possibly have. By looking at the door, there’s no way to know whether you should breeze on through it, or stop and pull.

My friend Todd Webb and I were talking about this and he reminded me that this concept I’m complaining about is called affordance. When an object has affordance, its possible actions are easily discovered. For a reason that baffles me, some designers seem to love the symmetry of the glass door with the identical handles. They love it so much, they’ll even place ugly labels on their doors to overcome their lack of affordance. I found an example of this in the lobby of 600 W. Chicago St, the large building where Groupon is headquartered.

The funny thing is, I even found perfectly designed doors that someone felt still needed to be labelled! These are in the lower level of Ogilve Transportation Center, my train station.

Yet, take heart all you idealistic door designers who are tired of luddite door users forcing you into asymmetrical designs! Technology has come to your rescue and provided a hinge that can swing both ways! Just inside those unintuitive front doors at Groupon, there are identical doors to their conference rooms that have different behavior. When you approach these doors you can push or pull.

This inconsistency is bizarre and frustrating to newcomers. I’m sure that almost everyone else doesn’t even notice it at this point. I’m sure I won’t notice it in a week or two. But it took me back to the reason I read The Design of Everyday Things in the first place. I’m not actually passionate about door design, but I am passionate about software design. I want the software I develop to feel like that intuitive door at Jimmy John’s. I want it to feel that way on the outside in the web browser. And I want it to feel that way on the inside in the modules and methods.

If you’re interested in where I’m going with this, stay tuned for my upcoming post: The Design of Everyday Software.

Excerpts from Reinersten's "Flow"

Sat, 03 Jul 2010 23:29:00 -0500

I believe it was Aslak who first mentioned The Principles of Product Development Flow: Second Generation Lean Product Development by Donald Reinertsen at speakerconf in February. I finally finished the book on vacation this week. I’m listing the excerpts that resonated the most strongly with me so I can easily reference them in the future. I highly recommend the book if you want to learn why the ideas behind agile development work, and if you want to improve the effectiveness of your development efforts.

Note: I didn’t track page numbers initially, but then started to later.

Another note: You can pretty much substitute “product development” for “software development”.

Final note: You’ll see that Reinertsen likes to use the word “resource” a lot. I tried to give him the benefit of the doubt, but eventually it became obvious he was referring to actual human beings when using that term. I find that term demeaning and counter-productive when used to refer to teams of creative individuals. So, feel free to substitute “resources” for “people”.

Reward generalization, not specialization.

Philosophy of United States Marine Corps: Uncertainty does not inherently favor either side. Instead, the side that can thrive in the presence of uncertainty is most likely to win.

When high quality decentralized economic information is absent, it is too often replaced by the mind-numbing bureaucracy of centralized control.

In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.

To blindly conform to the original plan when it no longer represents the best economic choice is the act of a fool.

Control without [management] participation is control without decision-making delays.

If we make resources available for free, they will tend to be infinitely utilized.

High levels of capacity utilization are actually a primary cause of long cycle time.

When product developers choose to operate their processes at high levels of utilization, they create unnecessary and wasteful variability in their processes. It is important to realize that this variability is a self-inflicted wound.

The key to stable priorities is to link them to economic facts.

We simply cannot rely on randomness to correct the problems that randomness creates. p. 79

We should point out that any specialist can become a queue. p. 82

Either excessive or insufficient probability of failure reduces the efficiency with which we generate information. p. 94

If the cost of improving iteration speed is comparable to the cost of lowering the defect rate, improving iteration speed will have more influence. p. 106

It is usually not productive to work on old bugs, since they may die of old age or irrelevance before we get around to fixing them. p. 108

Batch size reduction can enable us to shorten cycle time, often by an order of magnitude or more, without changing capacity utilization. p. 112

The local efficiency improvements of large batches are completely wiped out by the added rework cause by delayed feedback. p. 116

The 100-fold improvement in manufacturing cycle times was not achieved by finding bottlenecks and adding capacity to the bottlenecks. It was achieved by reducing batch size. p. 133

Zombie projects destroy flow. Kill the zombies! p. 152

Most development organizations have a handful of special people who seem to be able to overpower the most difficult problems. They are the 10% that handles 90% of the most difficult work. If we wish to use such resources to destroy emerging queues, it is critical that we load them to less-than-full utilization. Unfortunately, most organizations love to load these highly ~~profuctive~~ productive resources to very high utilization rates. We need to change this mind-set. The big guns are not most valuable as an efficient substitute for small guns, they are most valuable for handling situations that the small guns cannot handle. p. 155

The ideal resource is a jack of all trades and a master of one. p. 156

Telecommunication networks are based on fundamentally different assumptions than manufacuring processes. They assume variability is inherent to the problem and adopt flow control approaches that are robust in the presence of variability. These network-based approaches are well-suited to the natural variability of product development processes. p. 169-170

By operating with small queues, we minimize the payoff of [prioritizing], and thus, the need to do it. p. 192

Flexible resources enable flexible routing. p. 202

Companies inevitably feel they can computerize the whiteboard, however, they almost always create a more elegant but less useful system. As simple as the whiteboard is, it makes WIP [Work in Progress] continuously visible, it enforces WIP constraints, it creates synchronized daily interaction, and it promotes interactive problem solving. p. 205

Optimizing the economics of a process is very different than maximizing it’s throughput. p. 208

It is common that we must invest in creating a superior development environment in order to extract the smaller signals that come with fast feedback. p. 222

If you ever have an opportunity to colocate a team, do it. If you don’t, fight hard to get it, and you will be glad you did. p. 231

Human effects of fast feedback are regenerative. Fast feedback gives people a sense of control; they use it, see results, and this further reinforces their sense of control. p. 232

The marines believe that they need the capability to make quick transitions, and, that this capability comes from constant practice. In product development, we can change direction more quickly when we have a small team of highly skilled people instead of a large team. … We can change direction more quickly when we have reserve capacity in our resources. It is very difficult to apply an extra burst of effort when people are already working 100 hours per week. p. 256

What builds trust? We trust someone when we feel we can predict their behavior under difficult conditions. … We actually do not need others to have similar attitudes and values to ours; we just need to predict how they will act. … Small batch sizes build trust, and trust enables the decentralized control that enables us to work with small batch sizes. p. 264-265

Expose Yourself

Tue, 15 Jun 2010 17:55:57 -0500

Derek Sivers just posted yet another excellent story to his blog. It’s a good, quick read. I wish he had written it a few years ago so I could have referred to it in my book. Specifically, in this chapter.

After reading it, I feel compelled to point out something that I think a lot of people will miss as they read Derek’s story. He’s writing about the importance of practicing. But I’ve noticed something in a couple of Derek’s stories: his willingness to approach knowledgeable, accomplished people and ask them questions.

Then I heard a man giving a demonstration of Indian vocal music, and his pitch was so perfect, I went rushing up to him afterwards to ask how he did it.

Do you know why it’s hard to do this? Because by asking questions like this, you’re Exposing Your Ignorance. Derek is letting this awesome singer know that he doesn’t know how to sing very well. That can feel really scary at first. I remember doing something similar with Wyatt Sutherland back in 2002, when he led the Chicago Agile Developers group. I wasn’t as brave as Derek, I did it via email, but it still paid off handsomely.

It’s so easy to overlook this simple but difficult habit. Develop it. Practice it. :)

In May, 2000

Tue, 11 May 2010 11:28:00 -0500

I quickly learned that commuting by car from Warrenville to Skokie every day during rush hour wasn’t going to work. Thankfully my new boss, Carolyn, was flexible about it, and let me do an early-in, early-out commute. I would wake up at 4am, do a quick workout, and hustle to Skokie before traffic set in. Then I’d be out the office’s back door at 4pm every day, and home to Staci and Rose before the roads got crazy. Naturally, there were plenty of times when things would get complicated and I’d end up sitting in traffic for what felt like an eternity. This was frustrating, but most definitely worth the hassle.

My workspace was in this cool, old bedroom-like office, upstairs from the main Edventions crew. Wood floors, creaky doors, and an occasional mouse made my silent mornings feel surreal. Once people started to trickle in after 8am, some of the magic disappeared, though the camaraderie was welcome. My time was spent trying to figure out how to use this egrail content management system. I received some occasional guidance from Irv, who seemingly understood everything about everything, though not in an obnoxious way. He was always very curious and eager. I liked Irv. I wanted to figure out how to help him build a successful business.

Egrail felt overly complicated. It was weird, it was actually a web site that managed your web site. I needed to fill in some web forms in the right way, with the right stuff to make starship.com look the right way and have the right content. The craziest parts were these places where I had to copy and paste these strange incantations wrapped in . Not sure what that’s about.

[This year, I’m blogging the year 2000, the year I started programming.]

Going Local

Tue, 11 May 2010 00:19:00 -0500

Back around 2006-2007, as Obtiva was growing beyond our initial client, we started asking ourselves what sort of company we wanted to be. We had a couple of successful examples nearby that we could have chosen to emulate. We could have tried to be like my former employer, ThoughtWorks, which had scaled a successful transnational consultancy with a world-class culture around software development. Or we could try to be like Object Mentor, and keep it small and focus exclusively on high margin training and coaching gigs, built around a few uniquely gifted personalities. We liked both of these companies, but for us, the fundamental problem with their business models was that we didn’t want to travel. Kevin and I are both married, with kids in elementary school, and we didn’t like the idea of leaving them on a weekly basis for most of their childhood.

As we pondered our future, I thought back to my tenure at ThoughtWorks (2004-2006). Wow, what an awesome experience that was! Seriously life-changing for me. But I was always perplexed at how few Chicago clients they had, despite their global headquarters’ location in the Windy City. I remember getting on my 20th consecutive Monday morning jet to Detroit and imagining other ThoughtWorkers east of me crossing me in the air, flying west to some other gig, maybe even in Chicago. I remembered feeling lucky to get a Chicago gig, and working on a great team of people who were flying in from all over the country, but then scratching my head when I considered how many Chicagoans would have been just as effective. Finally, I pulled up Chicago in Google Maps and marveled at its size. Surely there was enough business in this huge metropolis to keep us busy for years to come? Why not just do what we already wanted to do and focus on local work?

Well, that’s what we did. We don’t travel for client work. We’ll travel occasionally to do a training. And we actually enjoy traveling to go to conferences. But we’re lucky enough to live near a huge city, so there’s more than enough work to scale several companies like us. What’s a company like us? Well, we’re all unique snowflakes of course, but Obtiva settled into the dual niches of doing end-to-end project work from our studio while also augmenting teams in the some of best development shops in Chicago. I wish I could tell you our full client list, because I’m very proud of it, but I signed some paperwork that forbids me from telling you some of our clients. :| One client I can mention publicly is Groupon, who we’ve been working closely with for a year. (Just FYI, they’ve had quite a year, to say the least.) Lots of software folks will turn up their noses at “staff aug”, but I’ve learned that not all “staff aug” is created equal. Just ask two of our subcontractors, Corey Haines and Dave Astels, currently doing “staff aug” for us right now at two of our awesome clients.

There is an environmental benefit to focusing locally. Harkening back to 2006 again, I remember sitting in the Hard Rock Hotel in Chicago at ThoughtWorks’ internal conference. It was an awesome January day that assembled most of the US-based ThoughtWorkers to learn about all sorts of cool stuff (and a controversial new web framework called “Ruby on Rails”). Anyway, one of the more memorable parts of the day was a lunchtime keynote given by one of the head guys at Greenpeace. This was four months before An Inconvenient Truth was released, so this guy definitely grabbed our attention with tales of shrinking glaciers and projections of shrinking continents. Then he called our attention to the amount of pollution that air travel creates, mentioning that he had flown in to talk to us, but also pointing out the problematic environmental impact of ThoughtWorks’ travel tendencies. Now, I think back to my four years at Obtiva, and how tiny our footprint (per capita) is compared to a company that sends its people across the country (or globe) every week. Consider the energy/emissions it requires to fly hundreds of miles. Consider the energy/emissions required to drive a car dozens of miles. Now consider that almost no one at Obtiva even drives to work! We’re blessed to live in a city with public transportation, so we all take trains, buses, and bikes every day. And what do a lot of us do on the train? We read, we code, we learn!

While the environmental benefits are cool, I prefer to consider the effect that our local focus has on our families, since that was our original motivation. Last summer, I wrote a blog post, citing some of Obtiva’s remarkable statistics over its first 4 years, such as 6 births, 2 weddings, and 0 divorces. I’m happy to say that almost a year later, these numbers are still looking great: 10 births, 2 weddings, 0 divorces. I continue to believe that these numbers are strong positive indicators that we work at a sustainable pace. And for me and many other Obtivians, going local is fundamental to our sustainability.

Thanks to Fred Polgardy for retweeting this article, which inspired me to connect some of those ideas to Obtiva.

Obtiva's Secret Sauce

Mon, 03 May 2010 10:42:00 -0500

Obtiva came from simple beginnings and we’ve grown slowly, conservatively, and frugally over the years. We’ve worked hard, and with small budgets, to reach where we are today. Where are we? We are one of the premier custom software consultancies in the world, and the most prestigious Rails shop in Chicago. How did we accomplish this without a cent of investment capital? Culture. We have a culture built upon the two fundamental activities of what it takes to become someone who delivers great software: the ability to learn, and the ability to communicate well. It’s simple in theory, but must be built intentionally.

Our founder, Kevin Taylor, has a passion for reading. When I showed up for my first week on the job at our first client, Kevin had already established a tradition there of weekly book clubs. A majority of the development team would spend one lunch hour a week discussing the assigned reading. I was impressed. As a consultant, I know how difficult it is to create lasting change in a development organization, yet Kevin had infected this place with a habit of learning. I joined in and read “Ruby for Rails” with the group, which, at the time, was the best introduction to Ruby for Rails developers. This book started Obtiva down the path of Ruby from our roots in Java. (We’ve come a long way, too! One of our senior consultants has just released the beta version of the Rails Test Prescriptions for the Pragmatic Press.)

A year later, I started our Studio practice with my first full-time Rails gig. At first it was just me in a little office in Wheaton, Illinois, where Kevin and I both live. Soon after starting the Studio, we hired a couple of apprentices to support me. What is an apprentice? An apprentice is someone who is willing to put themselves at the bottom of the totem pole for an opportunity to learn from experienced craftsmen. Our apprentices wanted to reach the next level as developers, and we believed that was a key strategy for growing our company: find high-potential, low-credential people, give them a learning-friendly atmosphere with challenging projects, and get out of their way. Naturally, one of the first things we did with our apprentices was start a weekly book club. We studied the manuscript of Refactoring: Ruby Edition. Our weekly discussions in this group slowly evolved beyond the book and took on a life of its own. Three years later, this weekly gathering of Obtiva geeks is still happening every week. We call it geekfest.

Geekfest has become the heartbeat of Obtiva. It is the only regular event that allows us to connect with all of the other developers in the company. (We also just had our first ObtivaCon, an internal conference we hope to repeat periodically.) Within a year of starting geekfest, Obtiva began recognizing its value and started providing free lunch for all attendees. Today, as many as 30 geeks attend Geekfest on a weekly basis. Sometimes we hear trial-run presentations from experienced mentors like Noel Rappin and Andy Maleh. Other times Geekfest provides a safe place for less experienced presenters, like Adam Walters and Ethan Gunderson, to practice. There are times when Geekfest is unstructured and we have an open discussion about current projects, new technologies, and hot topics in the developer community. Finally, we sometimes use Geekfest as a hackfest, spending the hour pairing with each other on our various pet projects, like Spittle or the Mad Mimi Mailer.

Geekfest is a tradition that embodies our commitment to accelerating learning and improving our communication skills. So does our apprenticeship program. Since 2007, Obtiva has been giving apprentices the opportunity to grow to the next level as developers. Over the years we have improved and adapted our apprenticeship program in order to maximize the experience for the apprentice, as well as increase the likelihood that our apprentices will be able to transition into the roles we need them to fill for our clients. Today, our apprenticeships last 6 months. For now, we only have a single apprentice at a time, giving the apprentice the opportunity to have our full attention. The apprentice has a contract-to-hire relationship with Obtiva and must successfully pass 3 milestones to continue through the 6 month program. These milestones give us the opportunity to judge the apprentice on the progression of their technical and communication skills. The milestone wraps up with a retrospective in order to incorporate feedback (from both sides) and adapt the next two months leading up to the next milestone.

Of the 7 apprentices we’ve had over the last 3 years, 5 of them are still with us. Our first apprentice, Brian Tatnall, is now employed at DRW Trading. Our second apprentice eventually moved onto other opportunities. Our third apprentice, Nate Jackson, is doing a stellar job pairing with Corey Haines (Obtiva subcontractor) at one of our newest clients. Our fourth apprentice, Colin Harris, has been consulting for us at Groupon for almost a year now. Our fifth apprentice, Leah Welty-Reiger, PhD., a particle-physicist-turned-web-developer is doing front-end and Rails development at our biggest client. Our sixth apprentice, Turner King, who, like Nate, is an absolute natural back-end developer, is doing JRuby on Rails work. Finally, our most recent apprentice, Ethan Gunderson is in our Studio, contributing to several projects, including Mad Mimi. He is also active in the Ruby community, contributes to RSpec, is being published in the Rails Magazine about HAML/SASS, just completed his apprenticeship, and is now an Obtiva employee. We have recently chosen our next apprentice: Michael Hines will start with us in a few weeks.

Our investments in our successful apprentices have paid off handsomely for everyone involved. Thankfully, the vast majority of our apprentices are successful. We have found that an aptitude for programming is obviously necessary, but that attitude has an amplifying effect on their aptitude. After interviewing countless candidates, and walking with these seven apprentices through their apprenticeships, we have developed a knack for spotting the ideal candidate. Thankfully, our job has become easier over the years: as we’ve risen in notoriety, we’re getting stronger and stronger apprentice candidates. For instance, our next apprentice, Michael Hines, is graduating from the University of Illinois’ computer science program a few days before starting with us.

Apprenticeship is not unique to Obtiva, but it’s something that we’ve embraced for over 3 years. It is a successful business strategy and a vital cultural contributor. We’ve found that apprentices bring enthusiasm and new ideas into a team that more experienced developers sometimes lack. For more on apprenticeship, from the apprentice’s perspective, have a look at Apprenticeship Patterns.

It sounds cliche, but the value of Obtiva is most definitely greater than the sum of its parts. Individually, our people are great. Each of them would be strong contributors in any software development endeavor. What is the secret sauce that multiplies our abilities? We’re all headed in the same direction: we aspire to become great at what we do and enjoy helping each other along the way. Over time, this common goal creates some amazing results, and our satisfied clients are the main beneficiaries.

In April, 2000

Wed, 14 Apr 2010 02:19:00 -0500

On the day before my 26th birthday, I took the day off to interview at Edventions. I drove the long (painful) drive to Skokie (from Warrenville) and found my way to someone named Irv. Craptastic! Irv’s the flippin’ founder and CEO! He had me sit with one of his content editors who sorta quizzed me on HTML, online content editing, and general (non-techie) web knowledge. Then I spent some time in conversation with Irv. Wow, this felt right. The building was this cool 2 story, marble-y old building on the corner of Bronx and Dempster, and for some reason, it just felt like home to me, especially with Irv’s vision for the company. It all felt very alive and vibrant, especially compared to any previous job I’d ever had.

At the end of our conversation, Irv matched the combined income of my day job and side gig, plus a little more, and offered me the job. I accepted it. We shook hands. I got in my car and drove to a gas station. Then I got out of the car and called Staci. Then I called my family, friends, and other people. My life was changing, and although I grew tired of all the times my life changed when I was growing up (we moved around a lot), I had grown to relish change as an adult. I was thrilled to be involved in Edventions, a real, live dot-com startup!

Later that week, I met with my team at work and let them know I was leaving. They were surprised that I would walk away from the field of mental health. Interestingly, some of my clients were less surprised, and encouraged me in my decision. I’ve never regretted or second guessed my decision to change careers, and later that month, that’s exactly what I did. I was building starship.com (don’t bother going there now) using an open source content management system called egrail. This was the first of a series of projects where I found myself in over my head. The work was great. The commute sucked. But it was totally worth it.

[This year, I’m going to be blogging the year 2000, the year I started programming.]

In March, 2000

Thu, 18 Mar 2010 22:25:00 -0500

The Chicago area was starting to thaw. I started spending an increasing amount of time between my client appointments walking around nearby Hidden Lake. As I walked in circles, I pondered the possibilities of this unexpected idea of becoming a computer programmer. The more I thought about it, the more sense it made to me. I prayed about it, and felt peace about what I was considering. So I kept looking for opportunities.

Over a weekend, I was cleaning out my car and found a scrap of paper with a web address on it. I remembered the commercial I heard on the radio about a startup. I stuffed it in my pocket. When I had some time later, I pulled up the web site on my trusty Internet Explorer 5 lickety split with my super-fast new “broadband” connection. Well, the startup wasn’t in Chicago, it was in Skokie, a hellish 40 mile commute only possible by car from where I lived. Yet, what I saw on the site seemed to fit my background. The company, Edventions, was developing a product called StarshipSchool to help parents, teachers, and students use the web to collaborate on homework, progress reports, email, etc. I had a good feeling about the opportunity, so I emailed them, attaching my resume.

Within an hour of emailing Edventions, I received a reply asking me to call. I called and was talking with someone named Irv about what they were looking for. (I later found out he was the CEO. These sorts of encounters are one reason small companies can be so remarkable.) We set up a time for me to come to the office for an interview. This was all moving very fast, and I loved it. I felt like I was living in “Internet speed”, the instinctual decision making I had heard stories about over the previous couple years as dot-coms started dominating the news.

The interview was set for the day before my 26th birthday, April 3, and I was excited.

[This year, I’m going to be blogging the year 2000, the year I started programming.]

In February, 2000

Fri, 05 Feb 2010 23:12:00 -0600

I was a child and therapist, questioning whether I could become a software developer. My attempt at learning Java was stalling. The exercises in Java for Dummies didn’t seem to have any purpose. Even if I could get them to work (which I couldn’t), they didn’t seem to do anything useful. I was filled with doubt. Did I really want to switch careers? I had a good job and had just finished a master’s degree. Was I selling out?

After work, when I wasn’t writing for my About.com side job, I searched the web (sans Google) for local tech jobs. I marvelled at the long and impressive sounding lists of techno-acronyms that I needed to know in order to apply. I quickly realized that I was going to have to apply despite not knowing most of what they were looking for. Remarkably, I got an interview with a placement company who was looking for Java developers. I showed up and was unsurprised (but disappointed) when they cut the interview short when they looked more closely at my “resume”.

I kept looking for tech jobs. I even heard an ad for a Chicago “dot-com startup” on the radio. I wrote down the web address on a piece of paper, but soonafter lost it somewhere in my Chevy Lumina. I gave up on Java for Dummies, but dug deeper into HTML, and started learning some JavaScript. I wasn’t quite sure where this was heading.

[This year, I’m going to be blogging the year 2000, the year I started programming.]

In January, 2000

Sun, 10 Jan 2010 08:40:00 -0600

I was a child and family therapist. I worked in the Intensive Outreach Unit of the DuPage County Health Department. I had just finished my master’s degree in 1999 and was excited about my first gig as a “real” therapist. We worked in pairs and did in-home family therapy to prevent children and adolescents from being hospitalized for suicidal, homicidal, or psychotic behavior. We had a small case load and I was working with some great therapists. Compared to my cohorts from my master’s program, I felt like I’d found a great gig.

But I had another job too. I was the “Teen Advice” guide at About.com. I got the job to help pay the bills, but also because I’ve always been into computers, and was especially interested in the Internet since my uncle introduced it to me back in 1994. This job involved HTML, which felt magical to me, and I found that the time I spent coding HTML was giving me energy. I wanted to dig deeper into this seemingly magical art.

So, 10 years ago, between client appointments, I would hide out in my car in random parking lots reading Java for Dummies. Then I would go home and (when Staci and Rose were sleeping) try out what I learned. I worked hard at it for a while, and would get excited when I could make a button or JSomethingErOther appear on my PC, but it wasn’t sinking in. Applets seemed cool, I guess, but what’s with this javac thing? And all of these rules about public and static?

[This year, I’m going to be blogging the year 2000, the year I started programming.]

Second Nature

Mon, 16 Nov 2009 07:11:00 -0600

A Japanese translator contacted me last week. Apparently, Apprenticeship Patterns is being translated into Japanese. (In other news, Enrique might be working on Spanish and/or German translations.) Well, the translator wasted no time, and started asking Ade and me questions about the meanings of some trickier sentences in our dedication and Ward Cunningham’s foreword.

His question about the foreword forced me to rewrite Ward’s sentence, and I suppose like anyone who has had to rewrite anything of Ward’s, I found the experience enlightening. The translator was confused by a sentence in the last paragraph:

The craftsmanship movement in software recognizes that making this stuff second nature isn’t, well, second nature.

Being the web geek that I am, the first thing I did was look up the definition of “second nature”: “An acquired behavior or trait that is so long practiced as to seem innate.” And after struggling with it for a bit, I rewrote the sentence into this:

The craftsmanship movement recognizes that practicing and acquiring the skills of software craftsmanship are not innate to humans. Not only do we need to acquire software development skills, but we need to acquire the skills of skill acquisition.

This satisfied the translator. I was pretty happy with it too, since it helps explain what the book is about. It won’t teach you how to be a great programmer, it will teach you how to learn to be a great programmer.

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.