Over the past few months I have become more and more convinced about the fact that specialization in software development – which includes programming, design, architecture, and testing to me – is a terrible idea. I don’t know when this came up in the history of our craft, and I think we need to stop it – now. I also know that I am probably upsetting some folks with these statements, still I think you should critically read this blog entry, and make up your own mind about the matter.

Relays vs. self-organization

The agile community uses an analogy when comparing specialization and cross-functional teams. A cross-functional team consists of everyone that you need to get a particular job done. For software development that includes skills in business analysis, programming, software architecture, and design as well as software testing. For football (in the European sense of the game) this includes defenders, strikers, and probably a goal keeper. Even though a defender’s main job is to get the ball from the goal zone in a game, he is also able to score a goal. The same holds true for other team-based sports.

Compare this to sequential activities. (Hope I am not drawing a false dichotomy here.) In sports, when running a relay, you have a more sequential activity. One runner starts, passes on the baton to the next one, until all four runners have finished their job. Most of the same points hold true for sequential software development.

As you may know, I have been involved in swimming a bunch of years. We also had relay competitions back then. In comparison to running, in the swimming world there are a couple of reasons a swimmer might be disqualified. For example, if he’s swimming breast-stroke, and ends the lane by putting just one hand on the wall, the swimmer is disqualified. In relays, if a swimmer starts before the swimmer before him has finished, and put the hand on the wall, the whole team will be disqualified. There are about 100 rules why a swimmer or team might be disqualified.

Now, the thought that occurred to me just last week was, that in relay swimming a single point of failure exists. If you have a bad swimmer who’s making a mistake, he can disqualify the whole team. The same is true for other relay sports – even for other sequential activities. The specialist becomes the single point of failure. One guy screws up, bang, the whole team will be cursed. (Maybe that is why there is so much focus put on blaming each other in these cultures.)

Now, compare this team sports like football, rugby, or the cooperative game of software development. There are occasions where the whole team might get disqualified – but these are rare cases like someone from your team taking steroids. Yeah, I know these happen, too, and they are heavily discussed by the larger public. (Maybe that’s good.)

But if an ice hockey player is thrown out of the game for a penalty, then the team needs to find ways to adapt, and still either score another goal, or avoid getting goals scored against them. They need to collaborate to compensate for the situation. That’s probably when you need some specialist skill, but you will need more generalists – people that can score a goal, and defend the own goal.

You need to shift your thinking from blaming each other (which would paralyze you from doing anything good) towards constructively finding ways to win the game, still. You need to work together with your teammates in order to win as a team.

Also notice that a team in sports has more degrees of freedom – within the constraints set by the coach, and the referee (and the underlying rule system). Within these constraints the teams need to navigate through the complex problem of getting the ball to score a goal, and defending against players of the other team.

Also notice that it does not make sense to ask every player in a team sport to run as fast as they can all the time. For football, you would end up with a team that is tired out after 30 minutes, probably. Of course, they need to run fast, but they also need to take their time for tactics. In relay sports it makes more sense to ask everyone to run as fast (and as efficient) as possible. In a team sport more efficient on the individual level means being less effective on the whole team level.

The same holds true in software development. With team-based software development you have more degrees of freedom to navigate through the complex field of the cooperative game of software development. You also increase your flexibility with a more cross-skilled team that has fewer specialists on board. More and more this factor becomes crucial in order to have a competitive advantage in the modern world.

Not that I am not saying that you should have a team consisting of generalists alone. That would be a false dichotomy. Instead, you should have “just enough” specialization, and diverse skills on the team. The problem, though, is an over-reliance we currently face in most companies I have seen with specialists that are no longer able to work as part of a cross-functional team. I think we need to move away from that deep-specialization-thinking in our craft.

Specialization and ego

There is one problem with the transition from specialized experts to cross-functional teams. Most of these specialists have followed a career-path towards this specialization. For example, a tester started as tester, and became a test manager over time because that was the way to move forward in her career.

Now, if you confront these folks with the idea of generalization, and cross-functional teams, you might be telling these folks that the path they followed for the past ten years was pretty much worthless to get the job done. Ouch. I would hate that, too.

The problem is that the ego kicks in for these folks. People want to feel recognized, people want to know a clear path to their advancing in their career. I certainly can understand that. What I learned from egoless programming is that we shouldn’t adhere to our past career path too much. Just as we should detach from the code that we once wrote in order to constructively work with the feedback from reviewers, we should also be open to overthink our current career direction, and try to take a different perspective on how to actually build software that solves a problem for someone that matters again.

I know this is hard. I know this will be a long journey for all of us. I know this will also mean to re-think some of our underlying assumptions about software development, management, and whatever specialization we followed (thus far). I truly believe the re-evaluation of some of our assumption will lead to some serious innovations in our field – and eventually we might find out how to constructively work together with our customers again. I think this goal is worth giving up some of my ego. How about you?