Dear Blogspot,
In the great span of events, it seems only yesterday that those who understood the mystical language of computers were called "Computer Programmers". Along with their fellow "Systems Administrators" and "Computer Operators", they formed the labor force behind the vital computing capital in large American corporations and governments.
My, but how times have changed.
Despite the fact that computers are in far more locations, Computer Operators have largely disappeared, due to the increasing ability of computer hardware to operate for indefinite periods without much attention. Systems Administrators have been broken into numerous specialized roles, dealing with upgrades, client software systems, security software, networking arrangements and components, monitoring, etc.
And likewise has gone the "Computer Programmer". Today, the market asks for specializations undreamed of in the past: skills with a specific programming language is minimal these days. Noone bothers to hire a C++ programmer for a PHP position. Knowledge of specific libraries, components, environments, and platforms also regularly appear on job descriptions. Even familiarity with specific development processes has entered demand.
So long ago, Adam Smith told us that "specialization is limited by the extent of the market".
The market for those who work on computers is large indeed.
Wednesday, July 28, 2010
Tuesday, July 20, 2010
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.
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.
Thursday, July 1, 2010
What's This For?
Dear Blogspot,
Some great things just seem to always go together: bright flowers and lawnmowers, bugs and magnifying glasses, anything and a bored cat. Why then is it so uncommon (but not unheard of) to find software engineering and economics paired up?
I aim to be fixing this.
As you know, Blogspot, my name is Bo Zimmerman, and I'm a software engineer in Austin, Texas. I realize my enthusiasm for economics is no substitute for a carefully studied degree, so be sure to weigh that carefully with anything posted on your hallowed hard drives.
Sincerely,
Bo Zimmerman
Some great things just seem to always go together: bright flowers and lawnmowers, bugs and magnifying glasses, anything and a bored cat. Why then is it so uncommon (but not unheard of) to find software engineering and economics paired up?
I aim to be fixing this.
As you know, Blogspot, my name is Bo Zimmerman, and I'm a software engineer in Austin, Texas. I realize my enthusiasm for economics is no substitute for a carefully studied degree, so be sure to weigh that carefully with anything posted on your hallowed hard drives.
Sincerely,
Bo Zimmerman
Subscribe to:
Posts (Atom)