Jun 16, 2013

No ninjas or rock stars, just join the right band

Finding similarities between musicians and software engineers to begin to understand how to build better teams.

It's still common to see the term "ninja" or "rock star" in the titles of many job postings for software engineers and developers. Companies are trying to appeal to a set of self-labeling individuals of a particular type. I don't believe that companies literally want ninjas or rock stars. Ninjas kill people and throw pointy objects; rock stars play loud music, occasionally have substance abuse issues and trash hotel rooms. They don't build software.

The aim is to find developers that fit culturally into their organization. Perhaps the wish is that a "ninja" will have fantastical and mythical coding powers.

I would like to explore a different way of categorizing developers. Rock star is actually not far off the mark but instead of describing one individual let's talk about teams. Let's look for someone who plays Rock-n-roll and find them a band where the other members also play Rock-n-roll.

Wanted: band members for an upcoming tour

A job posting for a software engineer is similar to an advertisement for a band member. It can be reduced into two basic questions.

In musical terms:

In software engineering terms:

The software industry focuses on the instrument a lot more than the way in which people use them. To have more successful companies and happier engineers we need to focus on both.

The instrument

If you join a band you will primarily play one instrument. If you're holding that instrument in your hands or sitting behind it, odds are I can identify it without you saying a word.

The software engineering equivalent to this is more subtle. I can't visually tell what language or tooling a developer uses by looking at them but if you ask they will be glad to volunteer the information.

The programming language is a developer's instrument. It's the easiest thing to figure out; it's always listed prominently on their resume.

Knowing a musician or a software engineer's instrument is valuable but not the whole story. If you need a drummer it doesn't help to audition fiddle players. To understand the musician you must hear them play.


Playing guitar doesn't necessarily mean that you play Rock-n-Roll. Knowing Java doesn't necessarily mean that you write "Enterprise" software.

Each musical artist has their own taste and every software engineer has a certain way they like to work to solve problems.

Musicians group together around the type of music they love or at least appreciate. This happens naturally and automatically. When you see an orchestra of people there's a good chance that every seat is filled with a musician who likes the sound of orchestral music.

As we grow up hearing music we learn about musical genres. We are exposed to the works of great artists, organized into categories like "Country" or "Blues".

Software engineers can be placed into genres as well but this categorization is not automatic or natural. An average software company will likely have a team where developers are from differing genres.

Software developers as a group seem to be mostly unaware that they fit into a genre. If you are an engineer have you considered this? If I ask you what type of music you listen to while you code you would have an answer. If I ask you what genre of software development you are practicing while you listen to music I'd be surprised if you had a ready answer.

I don't think developers have thought about themselves on these terms before. If we haven't identified or named it how can we begin to understand or make different choices in order to form better, more cohesive software teams.

Different is good, right?

Why does it matter if you have different types of developers within your team? A varied group of people bring varied points of view. Isn't diversity of background and approach a desirable thing? If you have a developer who loves to move fast and experiment don't they balance the engineer who is methodical and slow?

If one developer is from a different genre than the other you are going to experience disharmony.

Playing heavy metal rhythm in a folk song

Imagine the scenario of mixing vastly different musical genres together.

A Folk band finds themselves in need of a new guitar player. They find an amazing Heavy Metal axe-wielding rocker and hire him for their upcoming tour. They now have a guitar player and the band is once again complete.

On the first night of the tour they are playing to a sold-out crowd of Folk music aficionados. The band enters the stage, takes their positions, and begins playing the first song. The crowd is enjoying the banjo, the drums, the upright bass, and the mellow vocals as the heartfelt folk tune reaches out and begins to tell a story. Just then a heavily distorted electric guitar rips across the chorus. The rocker launches into a blistering power-chord infused lick that almost literally sets the front row concert-goers' hair on fire.

The tonal contrast is too great for human ears to endure. The song's balance so vehemently thrown off by the sound of the electric guitar that the crowd instantly rejects it. A mutiny begins. Disgusted and appalled folk music fans begin to leave the auditorium. Ticket booths are swarmed with unsatisfied customers demanding their money back and empty seats stare back at the bewildered band members.

As the last echoes of their halted performance die away in the distance, they understand the error that they all made. You can't expect a Heavy Metal guitar player to play folk music.

Developers who can play the instrument but don't fit in the genre

Mixing musical genres doesn't work. If you take software developers of different genres and mix them into one team it's not going to work either.

Problems will manifest in sneaky ways. The affects are not as apparent as having a heavy metal riff tear through a folk song but there are measurable effects.

Symptoms of deferring genres:

I'm not saying the "developer genre" concept is the only reason you see these symptoms. I'd bet that a team that exhibits most of these characteristics suffers from multiple genre issues.

Making music

A musician, while crafting a new song with other band members, makes choices about what notes or chords they will play next, the key they will play in, how loud they play, type of playing style, tempo, harmonies, etcetera. Sometimes these decisions are instinctual, sometimes very deliberate and thoughtful.

If you are not musically inclined, it can seem like magic that a group of people can all get on the same wave length and create such beautiful and pleasing sounds. In reality it's hundreds, if not thousands, of tiny conscious or unconscious decisions made together as a group that births a song.

The process of writing software is very much the same. Developers make hundreds of small decisions and dozens of larger ones during the day as they work. They make intuitive decisions. If you've ever heard an engineer say "this doesn't feel right" they are making an intuitive judgement. They also make decisions based on the knowledge that they've gathered through experience or education. If you've heard an engineer start a sentence with "at my previous job" they are using experience to guide them.

Doesn't it make sense that a group of people who are, together, trying to create "something" from "nothing" need to be mostly on the same page to succeed?

Why playing within the same genre is important

Developers on small teams always have some degree of friction. They produce different code from each other, they communicate differently, and often come to different conclusions on how to solve a problem. It can be a big challenge just to get everyone on the same page.

In healthy doses these differences are a good thing. A team of people supporting and elevating each other create a better solution. They grow together and through productive discussion make something that is better than the sum of its parts.

With a team where some developers are from different genres you get very different code, wildly different communication methods, and opposite approaches to solving problems. In these teams it's rare for anybody to be on the same page.

The divergence in working style is much larger in these cases. It stops being healthy and turns acerbic. You find code that looks like Dr. Frankenstein took up programming as a hobby, arguments instead of discussions, and more often than not a flimsy system that does a questionable job at solving, even understanding, the original problem.

Before you call me dramatic let me attempt to illustrate this with another example.

Ballad of Jim and Brittany

Jim and Brittany are a small two-person team in a larger software-focused organization. They are asked to produce an authorization service in a service-oriented architecture (SOA). For those unfamiliar with SOA, think of it as software in the form of Lego blocks. The two engineers are responsible professional who do not need a lot of oversight and consequently are given a lot of freedom.

They both have a proven track record of delivering. Jim is a faster programmer than Brittany and likes to take risks. Brittany thinks more of the edge cases and focuses on writing good test coverage with everything she works on. These two developers are in different genres from one another.

As they begin, Brittany talks about the different smaller components of the service. She wants to get agreement on what will compose the service. Jim wants to begin coding and let the process of writing software drive the design.

They disagree on how to start the project. They forego any further discussion since they probably will not see eye-to-eye and each take approaches they are comfortable with. They decide to huddle up at the end of the day to see what progress each has made.

Jim implements a start-to-finish "positive path" of the service. That is to say, it can lookup the user, tell you what role that user has, and give you back a list of the things the user is allowed to do. This is precisely what he thinks their service should do. It doesn't include error handling and he hasn't written any tests, but this approach allows him to demonstrate the concept and get feedback quickly.

Brittany decomposes the service and decides that she would like to start with one small piece of functionality: the assignment and storage of roles for a single user. Since she sees value in test-driven development her small piece of functionality is well-tested on all edges and also well-designed. She doesn't have a complete path to demonstrate but is comfortable moving on because she is confident the foundation is good.

At the end of the day, Brittany is impressed with the progress that Jim has made but has doubts about the quality. It doesn't cover the negative code paths and is lacking tests. Jim appreciates the well-designed interface and good test coverage Brittany focused on but is worried that they are not making enough progress.

To be cooperative and reach a compromise Jim begins writing tests after he has written the code. Brittany also attempts to speed up by not worrying about perfect test coverage just yet. Managers will surely applaud their effort to work together.

At the end of their two-release work cycle Jim and Brittany are preparing to release a candidate that can be tested for integration with the other systems in the organization.

Neither Jim or Brittany are happy with where they've ended up.

Brittany is bothered that the code base could have a lot of bugs because it was not consistently coded using TDD and a lot of the design was not intentional. She also worries it's going to be hard to maintain since some code came together rather clumsily. To top it off, she simply worked faster than she is comfortable with and knows it's not her best work.

Jim is concerned that they did not provide enough business value and functionality. There were a lot of additional things that he like to work on but their focus on testing and continual conversations on internal design took up time. He simply isn't satisfied with the slow pace and knows this isn't his best work.

Jim and Brittany get along just swell. But their differences in how they develop software do not make them the best teammates. The software they have created seems to have an identity crisis. The different styles go together like oil and water and it's visible if you look deeply inside the code.

However, on the surface it appears that Jim and Brittany met with success. Their service integrates into the infrastructure and does the job. While it met the goals of the initial release, the project marches on; another release is planned with a new set of features to accomplish.

How efficient and pleasant will it be to continue the work in this code base? Does Brittany's approach or Jim's method prescribe how future work will proceed? Should a new developer write tests and focus on discreet components? Should he favor functionality and moving quickly to deliver features at the expense of testing?

Like a folk song interlaced with Heavy Metal riffs, the code base is a mess that just doesn't fit together well.

Would you classify Jim and Brittany in different genres?

In the example of Jim and Brittany I am not advocating that either style is more correct. Both approaches that these developers take have merits. There are benefits and drawbacks to both.

Jim's approach is fast and feature-bountiful. He wants to deliver functionality as quickly as possible and make it better as it matures.

Brittany's approach is methodical and feature-precious. She wants to deliver functionality that is well tested and designed and add more features as the system matures.

You might think the manager failed to identify what style of development they required for the project. I postulate developers themselves seldom think about their genres and how it impacts the code they write. If that is true, how many project managers do?

In this example, with Jim and Brittany being so different, how will they ever work together to create something cohesive that makes them both satisfied and proud? They are just too different.

We wouldn't expect a country music singer to be the third member of Daft Punk so why are we surprised when software development teams exhibit displeasure, frustration, and sometimes outright failure when they create software?

Cultural fit

If you've seen a team of people who seem to gel as they work together I think there is a good chance that you are witnessing developers who are very close to the same genre.

The team may have been formed by accident or it may have been deliberate. The end result is a group of people who have a lot of overlapping philosophy and probably similar past experience. Their way of thinking and coding style compliment one another.

Companies that try to deliberately hire people that fit well together usually call it "cultural fit". During the interview other members of the organization are supposed to make a determination if someone fits but I've never seen any type of process used to make the determination.

Most of the time the conversation after the interview goes like this: "So, what did you think of them? Do you think they'd fit in with us?".

The answer is ethereal. For some people a "yes" answer may mean they have a similar sense of humor. For others, "no" may mean they don't share similar career backgrounds. How do we qualify this answer?

I think it's time that we recognize that developers are different in the same way that musicians can be separated into genres. We'll start making better decisions if we do and everyone will benefit.

Is it time for band auditions in our industry to become standard?

To join a band you have to audition. You bring your instrument and you play for the other members of the band. If they are really considering you for the position you may even play with the band. They are not going to invite you into the group unless they have some assurance that you can perform and make music with them.

Why doesn't the software industry routinely audition developers and engineers for positions on a team? Some companies have figured this out but so many haven't. A company in Boston, MA pays potential employees to work with them for a week to see if they're a good fit.

The gut reaction for a lot of companies would be to reject the financial expense and time loss of "try-before-you-hire" but, man, it's a great idea. What is the financial impact and loss of quality if you don't get it right? Can we begin to measure the effects of a subtle but incorrect hire?

Start with identification

Developers: let's start to recognize that we are not all built the same. Let's acknowledge that as we grow in our career we develop tastes and we settle into a pattern for how we solve problems. Let's not pretend that every team is more or less the same; they are made up of people who could be vastly different than us. We may get along with them but the difference in the way we work may quietly build to a disaster.

Project and hiring managers: stop focusing so much on what programming language, what certifications, and what algorithms a job candidate knows. Instead, figure out what genre of development your team is and make sure the potential hire plays the same kind of music.

Our industry is young. We can learn a lot from other industries who have been around long before ours. The assemblage of orchestras can be traced back to Ancient Egypt. Perhaps finding the similarity between musical genre and types of engineers can help us mature a little further and make smarter decisions about our teams, our careers, and our happiness.