Opinion: Specializations Still Matter

[In this reprinted #altdevblogaday opinion piece, Blitz Game Studios' technical manager Lee Winder argues that we have specialist developers for a reason, and that one technical expert shouldn't be swapped out with another.] I recently came across an interesting post over on Agile Game Development titled 'Scrum Prohibits all Specializations'. The part that stuck me was the following:

Now I'm concerning myself with only the technical side of an agile team, but I've seen this raised in a number of different agile circles. In those cases, there seems to be the impression that swapping a database, physics, or audio developer with any other specialization like UI, animation, or graphics is valid, and an agile team members should be able to roll up their sleeves and perform the different roles to the same level with the same level of outcome. To me, this is emphasized in how the product backlog is often used, which is a priority- and risk-ordered document that doesn't take into account the skillset of the team that'll be working on the final product. Processes such as pair programming, constant re-factoring, and code reviews (to name but a few) seem to be seen as ways to not only communicate intent and project information but also skillset and ability across an entire discipline. So What Do Specialists Bring? But we have specialist developers for a reason. They are great at what they do, they understand the area in which they work and they know how to get the best results in the shortest amount of time. They have a passion for the area they are focusing in, which usually means they'll go a step further to research their area and keep up with developments which other developers may not have the time or the understanding to do. Spreading your talent thin and assuming that people can fill each others shoes leads to the following issues:

What About Pair Programming? Now I'm a massive fan of the various agile techniques out there. Pair programming is an excellent mentoring, development, and training tool, but it won't allow one developer to fit into the shoes of another. True, they will have a better understanding of the tools, pipeline, and systems being developed, which will allow them to fill in, but it won't transfer the amount of background experience the specialist has. The same goes for code reviews, constant refactoring, and feature discussions. It spreads the knowledge, which reduces the risk to the project should the specialist not be around when needed, but the core experience and drive that made the specialist who they are simply cannot be replaced by dropping in a new developer. But Everyone Does A Bit Of Something Every Once In A While? Of course, sometimes people do need to jump into another developer's shoes (illness, staff turn-over, hit by a bus etc.), but this is not the same as expecting a people to be able to fulfill each others roles equally. We can take steps to decrease the impact this will have on the team using the processes mentioned above but it will not allow those specialists to be inter-changed as the project continues development. We need specialists in any development field because it's these people that can push their respective fields in directions we might not even be able to imagine. By treating them as interchangeable, we might be gaining flexibility to schedule our staff, but we're losing something far more important and vital to a development team and the products they are creating. As I said to someone (in 140 character or less of course) when pointed out that people have done this, and even the author of the original post has done it (see the comments):

[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]