Re-thinking Software Development Education

December 21, 2011

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

March 17, 2011

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.

Be Careful Of Who You Work With

February 24, 2011

You instinctively know that who you associate with matters a lot. Our parents bring us up steering away and toward others who influence us.

But most of us don’t realize just how much those around us influence us.

As I recall in the introduction to The Passionate Programmer, there was one specific event that turned the tide for me. I had been chugging along in my slightly-above-average corporate job and experiencing what I considered to be the height of success. Then I had an intense period during which, for a few months, I had the opportunity to collaborate with a whole new level of software developers. It all came to a head when I went to the eXtreme Programming Immersion that Object Mentor taught. After a week surrounded by brilliant developers and leaders in the field, I knew I had to do something different.

I had to be as much like them as I could.

In The Passionate Programmer, I quote Pat Metheny’s advice to young musicians: always be the worst musician in every band you’re in. As a musician and as a programmer, I’ve tried Pat’s advice. You play with a group of people better than you, and you’ll almost always play better.

http://www.flickr.com/photos/jazzuality/3613370192/

That’s good anecdotal advice. If you don’t trust Pat, how about Nicholas Christakis? Nicholas is a social scientist at Harvard University. Together with James Fowler of UC San Diego, his research focuses on how behavior and then even EMOTION spread through social networks. Can behavior be epidemic?

Here are some things their research has shown to spread through social networks ilke disease: Obesity), Smoking, Alcohol Consumption, and….HAPPINESS! Yes, emotional state is contagious.

http://www.flickr.com/photos/saintbob/165829023/

These aren’t insignificant numbers, either. For example, obesity chances increase 57% if you have a friend who is or becomes obese. And, more disturbing than that, this is an effect that is conducted through more than one node in the social graph. If your friends’ friends’ friends are obese, you are 10% more likely to be obese

If behavior spreads through social networks, then working in a toxic or slow-moving corporate environment is really really bad for you. If you’re a consultant, you MUST fire the clients that bring you down a notch and seek out clients that pull you up. If you’re a teacher, go where the students care about what they’re learning.

Automation and Outsourcing

February 18, 2011

What’s the difference between automation and outsourcing?

I don’t know if it’s the same everywhere, but here in the USA we’re deluged with fear-driven “news” reporting, decrying the theft or export of our jobs to low cost, less skilled, offshore labor. Or even onshore “illegal” labor. It might be Mexico. Or China. Or India. In the 80s it was the Japanese. And it was robots and computers.

I’m not going to argue whether any of this is true or worth being upset about here. I’ve done it elsewhere. What I’m interested in here is the question: what if, as individuals, instead of fearing outsourcing, offshoring, and automation, we decided to use it to our advantage?

The standard argument against offshore outsourcing goes like this: Offshore people don’t understand the work, or the culture, or don’t care about quality or just aren’t as good. They might be cheaper by the hour, but they’re more expensive in the long run.

OK. That’s a hard one to disprove. It’s also kind of hard to prove. Regardless, hold that thought

http://www.flickr.com/photos/dancoulter/21042744/

In this day and age, we’ve collectively gotten over the fear that computers will replace us all. We’re used to the idea that certain tasks can and should be automated. For the younger readers, did you know that there was such thing as a spreadsheet before computer existed? That’s right. It was roughly the same except a person had to calculate each value! And if any numbers changed, guess what happened? Someone had to recalculate them!

Anybody want that job? I didn’t think so.

So that’s automation. If you think really hard about what you do every day, I bet you can come up with a few things that could be automated so you wouldn’t have to do them anymore. You wouldn’t feel bad about those things. You’d be saving yourself time and saving your employers money if you could automate them. Software developers spend their careers doing this for others.

Anything that could be done by a computer or a robot (roughly) just as well as it could be done by a human should be automated. That frees the people up to think. That’s what we want, ya? Hurray!

Some tasks are almost automate-able. But they just need that little extra push. For example, human language is hard to parse. It’s not exact enough to write reliable programs (usually) to read and act on. So what do you do with those tasks that seem mundane enough to automate but can’t actually be done without a human?

Outsource!

Outsourcing might mean giving the task to a more junior person you already work with. It might mean hiring someone on another continent who costs a fraction per hour than you do and can be trained to do the mundane work you do. It might mean taking on an apprentice and teaching them as they handle the “easy” stuff.

But, the fact of the matter is, in the work that most of us do every day there are things we could have someone less experienced do for us. And if that person is happy to do it, benefits from it in some way, costs less than we do, or is just willing when we are not, it’s not a bad thing to try.

If you continually do things that are “below your pay grade”, you’re wasting precious time or money.

At the end of the day today, think about what you did today. Given a little time, how much of it could have been automated?

Given a little time to document what needed to be done, how much of it could have been done just as well by someone else who is maybe less skilled or less expensive than you?

McDonalds, Six Sigma, and Offshore Outsourcing (notes)

February 10, 2011

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 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:

• Wilson Pickett’s Mustang Sally

• Zen and the Art of Motorcycle Maintenance: An Inquiry into Values

• The E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It

• VMG BPO – Offshore business outsourcing

• Ask Sunday – Virtual Personal Assistants

• GlowTouch – Low cost offshore IT outsourcing

• Quality Function Deployment

• iSixSigma – Lots of six sigma info

• DMADV – the six sigma design process in a nutshell

• Design Patterns: Elements of Reusable Object-Oriented Software

• Forbes article on Ray Kroc and the founding of the McDonalds chains

• John Zorn – Avant Garde saxophonist

• Paul Smith – Fashion designer

• Mark Rothko – Abstract Expressionist painter

• Rage comic generator

• Ugly Kitty Server code by me and Anthony Burns

• Ugly Kitty Server in action

• The “I know it when I see it” Supreme Court case

• Ibn Al-Haytham – inventor of the scientific method

• TDD T-Shirts

• Extreme Programming flow chart

• Rich Dad – Poor Dad

• Keavy McMinn’s webblog on Ironman etc.

• The Passionate Programmer – My book

• The 4-Hour Work Week

• The Mechanical Turk

I Don't Know

January 15, 2011

I had the pleasure of watching Scott Chacon keynote at CodeMash this week. He spoke about how Github “manages” its development team and product development. I enjoyed the talk, and encourage you to download his slides if you weren’t at the conference.

Scott is a very energetic speaker and talks really fast, so he ended his keynote with a lot of time to spare (something I wish I would do more often). So he took questions from the audience.

A lot of the questions were about trying to fit Github’s process into companies of very different profiles. So, for example, “Would this work in blah blah blah environment that is totally different from Github?” Scott’s answer was excellent in these several cases:

“I don’t know.”

He didn’t blow the questions off. He then discussed possibilities. But it was incredibly refreshing to hear “I don’t know” from a speaker being questioned in front of an audience of almost 1000 people.

I wrote in The Passionate Programmer about the difficulty and importance of learning to say “no”. I think “I don’t know” is scarier and harder and maybe more important.

When someone regularly says “I don’t know”, you trust them more when they say they DO know.

Dead-End Jobs: Are You Suffering From Stockholm Syndrome?

December 30, 2010

Have you heard of Stockholm Syndrome? It’s a name given to the condition wherein hostages develop positive feelings toward their captors despite being held in negative, unfavorable and even life-threatening conditions. Victims of Stockholm Syndrome will even inexplicably stay with their captors even when given the chance at freedom.

Hopefully nobody reading this is literally being held hostage right now. If you are, good luck!

For the rest of you, why might I suggest that you are suffering from Stockholm Syndrome? Because employment relationships can manifest themselves in this very way.

In the article, Love and Stockholm Syndrome: The Mystery of Loving an Abuser, Dr. Joseph Carver says that the following four situations serve as a foundation for the development of Stockholm Syndrome:

<quote>

• The presence of a perceived threat to one’s physical or psychological survival and the belief that the abuser would carry out the threat.
• The presence of a perceived small kindness from the abuser to the victim
• Isolation from perspectives other than those of the abuser
• The perceived inability to escape the situation

</quote>

Looking back at my own career (specifically some of the extremely intelligent people I’ve met who are stagnating in oppressive companies or positions) I have recognized that many of these people (and sometimes myself) have felt “stuck” for no obvious reason. Some people seem just plain crazy when you look at their skill sets, ability, and the low quality of work or environment they’re willing to put up with.

So I contacted Joseph Carver to ask his opinion. Could this be Stockholm Syndrome? He agreed. In email, he said “SS is most likely to develop when the employee feels trapped, perhaps by a high salary, fear of losing a career, or fear of humiliation.” So let’s look at his four conditions:

Perceived threat:

Getting fired, being humiliated, not being a “top 20%” employee, not getting a raise. Employers wield a lot of perceived power over employees, especially for those in very traditional corporate jobs. The employer must be willing to carry out the threat. Every business is under the right conditions. It’s how businesses work.

Small kindness

Got a Christmas bonus once when you really needed it? Make a competitive salary? Great benefits? Get to work on a technology you don’t think you’d be able to work on elsewhere? There ya go.

Isolation from other perspectives

Again, a big corporate environment is ripe for this kind of isolation. If you work for BigCo, you learn to do things The BigCo way. The company’s organizational structure becomes a blueprint for your career progression. You start to lose sight of what industry pay and incentives look like since you have a homogeneous population to compare with. Unfortunately, from what I’ve seen even the best run companies create this kind of isolation of perspective and group-think. Charismatic leaders are particularly capable of creating a culture vacuum around a cult of personality.

Perceived inability to escape

According to the Bureau of Labor statistics, American adults spend by far more time working than any other activity. That’s a lot of your waking time being trapped in a routine. In a Stockholm Syndrome situation, the captor chips away at the self-esteem of the captive. So for most of our waking hours, those of us trapped in dead end jobs like these are exposed to environments which systematically destroy our self-confidence. Not only that, a persistent fear and feeling of failure makes it harder to actually explore the options for leaving the bad situation. The instinctive self-preservation reaction in this kind of situation is to work harder to try to avoid the perceived threat coming to fruition.

So, what if this describes your job? You owe it to yourself to find a way out. Hopefully recognizing the signs will show you that the real situation is far less grim than you might believe and that you have control over how you choose to spend the majority of your adult life.

I’m writing this for the many people I’ve met (and the countless I haven’t) that are senselessly stuck in bad job situations. Please stop wasting your precious time.