Who will count the cost?

Dear Blogspot,

In case you didn't know, the average salary of a software engineer in the U.S. ranges from $50-$80k, not including benefits, per year. This works out to an average cost of roughly $32/hour + benefits.

The comparative advantage of the software engineer is in the creation of algorithms written in particular languages, for particular platforms, using particular tools, which will cause a computer to behave in a manner desired. These actions, in turn, generate further institutional knowledge possessed only by those engineers, which then gives those engineers comparative advantage in the production of all desired secondary goods which require that knowledge as an input, such as certain kinds of technical documentation, operating procedure documentation, manuals, reports, and inputs to other company processes.

In a software company, this is the source of serious problems. If a software engineer is the input to ALL outputs, this will drive the value of those engineers to the company upwards, which in turn drives the cost of generating those secondary outputs upwards as well. An example of this would not simply be a developer who finds his time consumed with software maintenance years after the software was written, but who also finds himself in meetings discussing reports about that software instead of working on new algorithms or fixing old ones.

A cost-conscious company will (or should) be motivated to reduce those costs. Under previous development methodologies (most notably Waterfall), this cost was managed by dividing the work of todays engineers into design and implementation, with design handled by software analysists, and implementation by programmers. However, cost and efficiency problems with this arrangement eventually led to the consolidation of those positions under new methodologies (most notably Agile). In the end, it was discovered that it was more efficient to consolidate software knowledge into an engineer than to bear the constant intercommunication costs created when the tasks were divided, especially when the primary input into both systems, namely business requirements, were constantly changing or being updated.

However, it still leaves the problem of the high cost of secondary goods. This is especially a problem in larger companies, where the demander and consumer of secondary goods from engineers are increasingly detached from those who are counting the costs of the process as a whole. For instance, if a manager in department A wants to include engineers from department B in a meeting to benefit department A, there are usually no systemic checks to prevent a waste of resources, when the benefits to B may be marginal, while the costs to A are considerable.

In markets, such wastes are checked by the price system. If a resource is more productive for use A than for use B, then this will be reflected in the high profit margin for A relative to B, resulting in more of the resource being utilized by the former.

Also, when the relative value of secondary goods is open to interpretation, and without guidance, there is insufficient motivation for discovering ways to "produce more" of different aspects of the engineers knowledge by spreading it around, which would otherwise lower the cost of some secondary goods versus others.

So, Blogspot, what is to be done? Perhaps a commenter has a suggestion for this systemic dilemma.