There is a pervasive myth amongst software development management types: the existence of the fungible resource.

A fungible resource is a human cog that managers and executives believe they can drop into a business machine to replace an existing cog. In other words, when developers part ways with a company, many managers believe that their replacements can quickly get up to speed and take over where their predecessors left off.

This is rarely true in any substantial development effort.

In his paper, Programming as Theory Building (PDF) Peter Naur - the “Naur” in “Backus-Naur Form” (BNF) - explains that as a program or system is built, the person or team that develops it builds a “theory” of the system. The theory embraces a dimension of software architecture beyond the well-known structural and behavioral views. This dimension cannot adequately be documented, a little like the “Quality Without A Name” cannot be described. No, it’s not woo. Every great developer understands this intuitively. (The paper is highly recommended reading for the patient and detail-oriented).

Naur describes how engineers who took over the development or maintenance of a system would modify it in ways that “make no use of the facilities that were not only inherent in the structure of the existing [software] but were discussed at length in its documentation, and to be based instead on additions to that structure in the form of patches that effectively destroyed its power and simplicity.”

He goes on to write that

“The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaption, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them.”

Basically, you can’t throw away the old cog without steadily increasing grinding noises and smoke emanating from the gearbox as the system dies from the thousand cuts of unguided maintenance.

“The death of a program happens when the programmer team possessing its theory is dissolved…. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered”.

Sounds familiar.

Does this mean projects are doomed when they lose their “theoreticians”?

Not necessarily. One way to soften the blow is to retain their services in a mentoring and advisory capacity. A caveat here is that if the advisors do not keep closely connected with the project as it changes, they will lose their special knowledge. Even more importantly, teams need to swallow their pride and actually take the advice of the old guard. This needs no small measure of maturity and humility, qualities which are conspicuously lacking in some developers.

So don’t be so quick to let core developers go. They are not fungible resources.