The “fungibility” of developers is a bit of hot topic at the moment. Fungibility means the ability to substitute one thing for another for the same effect; so money is fungible for goods in modern economies.
In software development that means taking a developer in one part of the organisation and substituting them elsewhere and not impacting the productivity of either developer involved in the exchange.
This is linked to the mythical “full-stack” developer by the emergence of different “disciplines” within web software development, usually these are: devops, client-side (browser-based development) and backend development (services).
It is entirely possible for developers to enter one of these niches and spend all their time in it. In fact sub-specialisations in things like responsive CSS and single-page apps (SPA) are opening up.
Now my view has always been that a developer should always aspire to have as broad a knowledge base as possible and to be able to turn their hand to anything. I believe when you don’t really understand what is going on around your foxhole then problems occur. Ultimately we are all pushing electric pulse-waves over wires and chips and it is worth remembering that.
However my working history was pretty badly scarred by the massive wave of Indian outsourcing that happened post the year 2000 and as a consequence the move up the value-chain that all the remaining onshore developers made. Chad Fowler’s book is a pretty good summary of what happened and how people reacted to it.
For people getting specialist pay for niche work, full-stack development doesn’t contain much attraction. Management sees fungibility as a convenient way of pushing paper resources around projects and then blaming developers for not delivering. There are also some well-written defences of specialisation.
In defence of broad skills
But I still believe that we need full-stack developers and if you don’t like that title then let’s call them holistic developers.
Organisations do need fungibility. Organisations without predictable demand or who are experiencing disruption in their business methodology need to be flexible and they need to respond to situations that are unexpected.
You also need to fire drill those situations where people leave, fall ill or have a family crisis. Does the group fall apart or can it readjust and continue to deliver value? In any organisation you never know when you need to change people round at short notice.
Developers with a limited skill set are likely to make mistakes that someone with a broader set of experiences wouldn’t. It is also easier for a generalist developer to acquire specialist knowledge when needed than to broaden a specialist.
Encouraging specialism is the same as creating knowledge silos in your organisation. There are times when this might be acceptable but if you aren’t doing it in a conscious way and accompanying it with a risk assessment then it is dangerous.
Creating holistic developers
Most organisations have an absurd reward structure that massively benefits specialists rather than generalists. You can see that in iOS developer and mobile responsive web CSS salaries. The fact that someone is less capable than their colleagues means they are rewarded more. This is absurd and it needs to end.
Specialists should be treated like contractors and consultants. They have special skills but you should be codifying their knowledge and having them train their generalist colleagues. A specialist should be seen as a short-term investment in an area where you lack institutional memory and knowledge.
All software delivery organisations should practice rotation. Consider it a Chaos Monkey for your human processes.
Rotation puts things like onboarding processes to the test. It also brings new eyes to the solution and software design of the team. If something is simple it should make sense and be simply to newcomer, not someone who has been on the team for months.
Rotation applies within teams too. Don’t give functionality to the person who can deliver it the fastest, give it to the person who would struggle to deliver it. Then force the rest of the team to support that person. Make them see the weaknesses in what they’ve created.
Value generalists and go out of your way to create them.
Echo One 
Great write up but I have some strong feelings against building a culture of holistic developers. I’ve compiled my thoughts here http://viii.in/t-shaped-developers/
That is quite a long response and well-written too! I feel T-shaped developers are the thin-end of the wedge towards getting broader developers.
However I don’t think you really make a case for specialisms beyond a belief that specialists will always do a better job in their area than generalists. I’m not sure that has been historically true, I’m thinking about DBAs who insisted on using what they knew instead of the right technology for the problem.
Even your military example is slightly off because you don’t want a platoon to collapse if any member of it is killed. Soldiers are cross-trained.
I’d like to see a strong case for the value of specialism because I see it bringing as many problems as solutions.
“The fact that someone is less capable than their colleagues means they are rewarded more.”
This is a whopper of a claim. The idea that a highly-specialised developer is less valuable than a fungible developer is odd to mr, as someone who believes “Jack of all trades” still holds true today.
I used to work at Amazon where fungibility was highly coveted. The job title reflected this – there were no front or backend developers, everyone was an SDE. I worked there for roughly a year, some of that was spent at LoveFilm, who highly valued specialisation, and the rest in the core company.
I, and others, atrophied under a fungible regime. If plotted, you’d be able to see my skillset plateau in the dark ages between LoveFilm and my current place.
Ignoring the cognitive overhead that comes with context-switching, the pace of change in each specialisation is such that it takes an exceptionally rare individual to keep up with each. “Fungible” inevitably means a little bit crap at a little bit of everything.
Blending the natural individual strengths of your developers into a corporate grey goo lends itself to an organisational preference to one or the other. You only have to spend a few seconds on Amazon to see which way their web team leans. Google spent over a decade without strong frontend leadership, the remarkable turnaround over the last couple years will not have been the work of a “fungible” team.
Flexibility is worth something, I agree. But it’s only one metric in which to measure capability. If you want an excellent product, you need people who excel. And those people aren’t Jack.
I don’t believe that a specialist inherently implies excellence (or sadly even expertise). If you believe that too, then I’m sure you can follow my line of reasoning that an excellent developer with broad expertise is more valuable than one with narrow expertise.
If you believe that excellence is founded on specialisation then that isn’t my experience so we’d have to agree to differ there.
Pingback: Recommended Reading: Nov ’14 | Anne E Franco