in reply to The future of software design
I think that the fundamental differences between software vs. iron and concrete make your analogy weak, but not irrelevant. Making and maintaining physical things requires a lot of capitalization and a steady predictable market. There are standards of engineering practice in the construction of durable objects.
The more etherial nature of software, seen in its mutability and cheapness to duplicate, makes the skill of the programmer more important to the cost structure. The speed of change prevents the formation of rigid professional standards. Programmers are valued for their ability to get a job done which has never been done before. Once an application has been implemented a few times, de-facto standards arise for that application. Those standards are broken up and applied to new problems, not as standards but as guidelines.
The software industry is already broken into divisions like you describe: design, production, consulting, maintainance, support, with similarly differentiated pay scales. The difference is that software at any level needs an aptitude for abstraction, a grasp of mathematical logic, and a kind of linguistic sensibility. Mechanics and engineers have fundamental differences between them, and they each tend to regard the other as the enemy. That situation can arise in software, when warm bodies are expected to maintain what they don't understand, but the fundamental differences are not there.
After Compline,
Zaxo