Developer Fungibility?

Question

Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution, where one unit of a commodity can be exchanged for another unit of the same commodity in the same quantity and grade.

I've worked at more than one company that stated openly that their goal was developer fungibility. This misconception that developers are a commodity and that efficiency can be gained by establishing the single correct way of creating all software to enable develop fungibility is ludicrous.

There are different levels of system, which in turn require different levels of solution.

There are different levels of skill, which places developers in different categories.

To deny these things is ludicrous... yet they do so.

Have you ever seen this work?

Answer 1

I've seen something similar referred to as a "Bus Factor". The Bus Factor is a measure of how screwed your company would be if you were hit by a bus tomorrow. The idea is that you want to spread the knowledge around such that any given developer could, ideally, step up and help out with any aspect of the project, even those coded by other developers. So even if Cory the Coder is god's gift to development, Mark the Mediocre would try to at least understand what's going on, such that if Cory was hit by a bus, Mark could at least maintain/debug Cory's code.

I suspect that is the 'goal' of this fungibility of which you speak.

Answer 2

The idea of the developer commodity was debunked pretty thoroughly back in the 1970's in the book, "The Mythical Man Month." There is no way to swap developers in the middle of a project without increasing development time. The idea that adding more developers to a project will reduce development time is also a fallacy. It's sad that these misconceptions are held by many people even to this day.

Answer 3

Most software developers work for companies that are not in the software business. The people in the main line of the business don't understand what developers do, and so they think developers are fungible.

Hospitals understand that doctors are specialized. Colleges understand that professors are specialized. But programmers working for hospitals or colleges are seen as interchangeable components.

Answer 4

My opinion is this, and I challenge you to change my mind:

I don't see how this term "developer fungibility" can possibly work. Just like every human on the planet is unique, we all have unique experiences and all have to solve unique problems from time to time. I guarantee you that I will have come across at least one thing that you won't ever have come across and vice versa.

There is no possible way that developers even of the same grade/ability are completely interchangeable, we all have different interests, different personal goals, different objects, different perspectives, different morals, different work ethics and different standards to which we hold ourselves.

Even if our technical abilities are comparable, my personal goals might drive me to write the most succinct and elegant code that has ever been written even if it costs a little extra in terms of performance, but someone else's view is write the fastest code at whatever the cost to the legibility of the code.

When you throw these soft skills and qualities into the mix, there's no way that this "developer fungibility" could ever be anything more than a pipe dream.

The strength of your team relies on the fact that you're different. You take the perfect mix of specialists that do what they do better than anyone else and work together effectively to be more than the sum of their parts.

Answer 5

to the extent that the developers' skill sets and domain knowledge overlap, they're all interchangable. If you need a for-loop coded to print the contents of a CSV file, chances are any random developer on your team can do it.

how fast they can do it is another matter!

outside of the common and/or trivial stuff, developers are obviously not interchangable cogs in the corporate wheel. This mindset is left over from industrial manufacturing - and building software is nothing like the low-tech assembly-line work that spawned this kind of thinking.

each developer is a craftsman, an artist, a software sculptor, and a scientist, to varying degrees. Their specialities combined in a well-communicating team is what makes the team's ability greater than the sum of its parts.

[what is the opposite of a team? a committee - the only organism capable of consistently making decisions dumber than any of its members ;-)]