Another cost of staff turnover

At an undisclosed business, there has been a history of complete staff replacements over the years. In fact when I started working there, the entire development team (two people) had recently quit and left, with a night watchman soaking up as much as he could during their notice period and then helping me to wrap my head around things.

I coped quite well overall; somehow I was able to assimilate most of the important areas of the project quite quickly. It helps that I actively enjoy reading code - if only I knew how to get paid for rendering a code review service.

But every now and then, and invariably in the code that deals with Berkeley DB files, there'd be some lurking anti-aesthetic singularity, an infinite source of code entropy. Just reading that code makes me want to cry - it is beyond the point of equilibrium between fixing and introducing bugs. And because I rarely need to fight a fire there (which seems a miracle), I have had only sporadic and patchy understanding of it - I never truly grokked it all. Perhaps if I had spent twenty years working there instead of only four, I would have accumulated enough brain circuitry to achieve that level of oneness with the code.

That is the problem: nobody ever did - nobody from any of the previous development teams held tenure for even as short a period as I did. (Actually the night watchman is still there, in the morning, the following week, but he deals nearly exclusively with the codebase he and I accidentally rewrote - a codebase I like to believe is not yet at entropic equilibrium.)

This is a problem that costs you, whether in profit as an owner, or in boardroom clout as a manager, or in customer perceptions as a salesperson. It costs you because when there is a problem in such hairy code we aren't familiar with [1], we can't make any reliable estimates, let alone promises, about how long it will take to fix, or even if it is possible at all to fix. In statistical terms: this unfamiliarity represents a high variance in the cost of doing our business of software development.

So quit thinking of people as perfectly interchangeable units of production, as commodified development resources [2]. We might all be capable of learning new technologies, of gaining an effective familiarity with most of the work we do, and of replacing colleagues. It isn't a cheap replacement though - not like you can schedule one night of downtime in a factory and replace a few bearings. And as far as corporate lackeys, worker drones, and cogs in a machine go, we're a pretty expensive means of production. So keep your machine oiled, and try to keep the sand out. Do the fuzzy math - figure out what level of oiling and maintenance is cost-effective.

[1] You may argue that it is our (developers') job to become familiar with the code. But at whose expense do we study this rarely-visited code? Do we stop developing the new features you clamour for in order to study code we might not need to change for another few months? Shall we ignore other, directly visible bugs? There is a significant opportunity cost to having developers do anything, if we aren't sitting around waiting for work. (Yes, sometimes we goof off, and there lies a valid criticism - but not the same one. And normally we try to make up the debt somehow. We might not write it down on paper, but we - I anyway - do mentally "keep score".)

[2] The company where I worked before the undisclosed business that is the setting of this post, had a penchant for referring to developers as "resources" - both in speech and in writing. I understand that "resource" is a fairly standard part of the project management jargon, and is quite appropriate in that abstract world where one is pushing long candlesticks around on a Gantt chart. I find it quite offensive, though, to use such a dehumanizing term in reference to particular people and teams.