The Art of Software Development Management

A fallacy in software development and management thereof is the idea that software developers are fungible.

This is not intuitive for folks to reason about because programming does entail at a fundamental level accounting and bookkeeping. Put this into a container, grab this lock in this order, call this function with these parameters, free this file handle when done with it. We are describing contracts for execution and flow for data.

Why then is software development not a simple matter of accounting? Because that is the easy part. It has defined boundaries and someone will either succeed or fail in finding them. A program either compiles or does not. The software encounters runtime errors or runs through. It has incorrect logic or does what is expected by the user.

If one person is working on the software and is the sole user, as long as they understand it and can use it, all is well.

Efficiency and time to delivery begin to part from these true and false answers. Everything breaks down when more people are added or the software outlasts the original developer's grasp.

What now dominates the difficulty is not the objective truths of algorithms, but the subjective qualities of their implementation and surrounding infrastructure like maintainability, composition, documentation and deployment. This is governed by people. People understand, in vector space rather than Boolean, the intent of a function, module, library, piece of software, and entire system. People, in vector space, have the ability to explain the implementations, the trade offs, the false starts and the success. People, in vector space, have the ability to effect changes, and at vastly different rates. Developers can negate progress and value.

These vector space attributes are why software developers are not fungible.

When someone works on a piece of software long enough, they have a vision for what it should be and a history of what the problems have been along the way.

Someone who is well read and has written similar sized systems will have a faster rate of learning and confidence on a new code base.

Someone with a sense of ownership and quality will imbue quality in their work. Another, with little interest in the task at hand will not, because quality is not accidental.

Are the folks maintaining the software able to work by, with, and through any obstacle they encounter? Have they proven the ability to predict and meet deadlines? Can they bring new people in? Might someone leave and the overall direction be maintained? Is the organization willing to remove code and features? These compose shared values.

In order: a developer, team, organization, company, product and community carry subjective vector space qualities. Comparisons between developers, teams, organizations, companies, products and communities are increasingly more difficult in like order.

It is foolish to think any one of these are a simple interchange with so many continua. The dynamics are more akin to organ transplant.

Yet a grandmaster of software development has intuition for evaluating the performance of these different scale actors, selecting and nurturing high performance. This is the Art of Software Development Management.

Few people live it. Everywhere I've been has retained negative performance on teams because someone just might do something useful eventually, they are here and headcount is hard to get, or the employee is just a nice person without consideration for the consequence. I've seen enough entire teams that would do better to be on a permanent paid vacation than working on product for a company. Every company I know of pays developers at opposite ends of the overall vector a low multiple difference at most, while a management chain that undermines The Art of Software Development Management to the point of institutional devalue may easily earn two and three orders of magnitude more.

When we look at human performance in sport, it is somehow obvious even to the layman. It would be cruel to swap children in on an NFL offensive line. Yet in software development organizations, this kind of wholesale swapout happens all the time with largely the same result - the entire product gets battered, frustrated, and losses result. A more empathetic strategy for the gradient of performance is to have separate leagues and deliberate transition points. Mixed performance can happen by exception only on a very mature team, with a product that is stable enough so mentorship can occur without stressing the mentor or mentee.

This is largely why commercial software development quality is abysmal. I don't know how to effect change en masse from where I stand now, but I am doing my best to live to it.