Currently:

Chad Fowler

Author, Speaker, Programming Lifestyle Engineer

Required Reading

Speaking/Lecturing Appearances

Mar 7-10
Pragmatic Rails Studio II
Santa Clara, CA
Mar 29-31
Pragmatic Rails Studio
Reston, VA
Apr 1-2
Ruby Nation
Reston, VA
Apr 6-8
Scottish Ruby Conference
Edinburgh, Scotland
Apr 22-23
Red Dot RubyConf
Singapore
May 16-19
RailsConf
Baltimore MD
May 28-29
RubyConf India
Bangalore, Karnataka, India
Jun 16-18
Nordic Ruby
Gothenburg, Sweden
Sep 11-14
SpeakerConf
Rome

Want me to speak at your event? Email me.

Blog Topics

career

life

software

rails

ruby

education

management

web

success

books

writing

job

metrics

quality

art

weightloss

development

programming

Search

Recent Thoughts

Re-thinking Software Development Education

Where have I been lately? Good question. When asked over these past months, I jokingly say something like, “These last 8 months at LivingSocial have been the best 4 years of my career.”

But I don’t just mean I’ve been busy. I’ve been focused on building the best software development team I can to do what I think is some important and industry-changing work in the world of local commerce.

And when I joke about these 8 months being the best 4 years of my career, what I really mean is that I feel like I’ve learned 4 years worth of lessons and gained 4 years worth of experience. What we’re doing isn’t easy. It’s the kind of work I’ve always sought out.

I am a self-taught software developer. To date, my formal education consists of two 3-day training classes on specific programming languages (Java many years ago and Erlang in 2008). During my first work experiences in IT, I remember the shock of discovering that a Masters degree in software development doesn’t necessarily translate to knowing how to effectively use a computer. I was a saxophonist and system administrator and would regularly teach the computer scientists I worked with about things I would have assumed they learned in college.

As I headed further into the workforce I noticed another odd thing: people with tens of years of experience as software developers weren’t necessarily very good at it. My assumptions were based on what I had previously learned as a jazz musician. Jazz musicians polish and hone their skills throughout their careers. The longer a jazz musician has been playing, the more likely he or she is to be an excellent jazz musician.

Programmers, though. As far as I could tell the average programmer spent his day complaining about his co-workers and waiting for 5pm.

So what’s the disconnect? Some of it, of course, is just the people. Some programmers are passionate and some aren’t. Those that aren’t, aren’t going to be radically successful. Assuming this is the case in all fields, what’s really frustrating to me is that I continue to run into passionate developers who just don’t know the right stuff.

When I started out in this field, I was lucky enough to stumble onto a mentor. That too was probably informed by my experience as an aspiring jazz musician. Jazz musicians take the idea of musical lineage seriously and look for someone from whom to receive direction on how to parse the potentially overwhelming task of going from novice to master jazz improviser. My mentor in the software field did the same. He told me: first learn these three things. He picked topics that were diverse but complementary. He picked skills that set a foundation on which it was easy to build the next set. Most new developers don’t get so lucky.

And It’s not just technology skills. The developers I work with are entrepreneurs at heart. We aren’t sitting around polishing our tools and conducting thought experiments. We’re delivering stuff that matters and we hate working on projects that drag on or don’t deliver value. Becoming a great developer involves not just learning the ins and outs of software development but understanding how businesses work and exactly how software systems fit into that picture. It’s about delivering value quickly and iteratively. Great developers understand what Kent Beck and the rest of the authors of the agile manifesto were getting at a decade ago. And what people like Eric Ries are teaching today.

I’ve often thought “just give me 3 months with a smart person and I can have them running circles around the average developer.” Have you thought that too? I know a lot of my colleagues have.

It’s time to rethink how we educate software developers. Computers used to be huge scary machines in big white rooms that very few people touched. Today you probably have at least one computer ON YOUR BODY most of the time. They’re ubiquitous and friendly and just NOT that hard to work with. The technology landscape has changed. The system of educating developers should change along with it.

My colleagues are clearly thinking along the same lines. I’ve seen speakers such as Joe O’Brien talking about it this year. And we see programs popping up all over. Software Craftsman Ken Auer is launching the Craftsmanship Academy to teach apprentices the art and craft of software development in an intense hands-on residency-oriented program. Code Academy is a part-time 12 week course to accelerate the path to web development or design.

Today we’re launching a new program at LivingSocial called Hungry Academy. Hungry Academy is a five month intense entrepreneurial immersion that will take raw, hungry talented programmers (and aspiring programmers!) and develop them into ultra-productive software engineers. Those that make it through to the end will be offered a position on our development team and paired with a mentor from LivingSocial’s growing list of some of the industry’s most talented software engineers. Best of all, we will pay you to attend. Your job for five months is to take your craft and career to the next level.

This isn’t going to be easy. Some people will get in but won’t make it to the end. Those that do will spend five months gaining the best 4 years of experience of their careers.

Leaving a Legacy...System

Ever since reading David Heinemeir Hansson’s post Enterprise Is the New Legacy over five years ago, I’ve been chewing on something. The gist of the post was that “enterprise” is and should be a bad word, just like “legacy”.

But why is “legacy” a bad word to begin with? The word makes most software developers and IT people ill.

In other fields and in life in general, the word “legacy” isn’t thusly encumbered. It refers to an inheritance left to those behind you. Your life’s work. Your essential story.

In software, that story is assumed to be a tragedy.

But even in the case of software, “legacy” is an indication of success. Sure, old software was written with old technology. And most software (or indeed most things created by humans) has its share of warts and dark corners. But the fact that we refer to a piece of software as “legacy” indicates that it was successful enough to have been deployed and to have been used for enough good that it is now something we’re “left with” and that we must either maintain or replace.

That isn’t so bad, is it? In an industry where more software projects fail or are ‘challenged’ than succeed, getting to legacy status is cause for celebration!

Here’s a sad idea: as developers, even when we do succeed, we tend to create things that are abandoned at great cost only a few years after we pour our hearts and souls into them. As rough as your last project might have been and as hard as the deadlines were, chances are your project will be disparaged and terminated within 10 years of its birth.

So, what do we developers leave as a legacy? In most cases, we don’t leave much of anything.

At a previous job, a mission-critical core system ran on an ancient, customized mainframe with a custom TCP/IP stack and a custom relational database system. At the time, the system was over 25 years old. It performed well. It survived Y2K. It was well understood. It reliably ran our (big) business.

That was ten years ago. I’d be willing to bet it’s still running. If not the whole system, at least a subset.

That would make it 35.

Sure, it had its ugly parts. And most of us were terrified of it. But, hey! Still running and doing its business after 35 years. I hope I ever create something that successful.

How would I create something that had that kind of longevity? How different would my designs be if I believed I was creating software to last 40 years?

It’s daunting, isn’t it? My knee-jerk reaction might be to do a Big Design Up Front. But how could I possibly design an entire system with 40 years of future knowledge in mind? I couldn’t. Even predicting next year is hard.

So maybe I’d need to design something that was ultimately flexible. A framework of frameworks where everything is pluggable.

Any software developer who lived through parts of the 90s knows these systems buckle under their own weight.

I don’t know how to design a system that could live a long and healthy life. I don’t know because I haven’t done it yet. Have you?

Note: This wasn’t a rhetorical question.

McDonalds, Six Sigma, and Offshore Outsourcing (notes)

These are notes from a talk I’ve given in various forms at SCNA, CodeMash, and Magic Ruby. I’ve mirrored them here from the InfoEther weblog.


Me at SCNA
Photo credit: Monty Ksycki

The presentation is called “McDonalds, Six Sigma, and Offshore Outsourcing – Unexpected Sources of Insight”. Here’s the abstract:

We software developers like to think of what we do as an art form (or a craft, if you’re at this conference). I was once asked to come up with a set of guidelines for creating great software so our (huge) company could more effectively use an offshore development team that had been delivering amorphous piles of crummy, nonworking code. I was frustrated and responded with something like this: “Give me a list of guidelines for how to make a beautiful song!” The nerve! Repeatable processes? Who did she think she was talking to?! This is a creative process! This is ART!!!!

I’ve since grown up a bit and I’d like to talk about how I was wrong and how we can all hopefully learn from my mistakes.


The Art-Craft-Commodity Continuum (from my presentation)

In it, I tell the story of my experiences with the Six Sigma quality methodology and with offshore outsourcing, urging developers not to blindly write off potentially useful software development strategies based on hearsay and misunderstanding. I also propose a customer-driven, data-driven approach to software engineering, dovetailing off of InfoEther’s Chief Scientist, Glenn Vanderburg’s recent ruminations on “Real Software Engineering”.

The original, scary Ronald McDonald
The original Ronald McDonald (Willard Scott)


Videos from SCNA will be posted on InfoQ eventually, and I’ll link mine here when that happens. In the mean time, many people asked me for pointers to some of the books and resources I mentioned during my presentation. Here’s a link dump that you might find useful: