This is a great point. Because software has near-zero replication costs, the "manufacturing" process has no good analog for software industry.
The manufacturing industry is supported by an army of engineers in a wide variety of specialties. In fact, manufacturing, in some ways, is starting to look a little more similar to software, because the non-material costs of production are falling (automation replaces direct labor) so replication costs are falling. Manufacturing will never look exactly like software due to the intrinsic role of raw material costs and the capital costs of production equipment, but there are increasing similarities.
As manufacturing has become more automated, a greater emphasis is placed on the role of engineer: in an automated factory, there is greater need for skilled engineers and lesser need for direct operating labor.
While better software has also helped these engineers become more productive, the net effect has been to improve quality of engineering output rather than to reduce engineering demand. (The exception is people working with engineers, but at a lower skill level. For example, there is little need for draftspeople.) Examples of this improved engineering output are flow simulation software that allows engineers to better push the envelope in part design to reduce part weight and improve production cycle times.
The net lesson from manufacturing engineering is that software engineers will continue to be in demand -- likely even higher demand -- so long as they continue to evolve their skills to use the more powerful software as it becomes available. The more powerful software will lessen the cost of software, which will increase demand for it, and increase demand for the skilled developer. For example, abstraction platforms such as Rails increased demand for those who evolved their skill set, because cost of web development fell due to higher productivity, thereby increasing demand for it.
However, like a draftsperson or an engineer who refuses to learn Solidworks, the more powerful software will be a negative for those who cannot, or choose not to, evolve their skill set above a more basic level.
However, like a draftsperson or an engineer who refuses to learn Solidworks, the more powerful software will be a negative for those who cannot, or choose not to, evolve their skill set above a more basic level.
That line jogged loose a memory that might cause some thought in other so I'll share:
I used be an aerospace engineer. Typically, what we called * designers* were technical people who were very good at working with fancy 3D parametric, version controlled CAD systems. They could come up with mechanical designs and drawings at a rapid pace and good results. They rarely had engineering degrees and leaned a bit on the technical knowledge of the engineers when they needed to.
But we had one guy who refused to learn the new systems and instead insisted on using old, some might say obsolete) 2D CAD that he was familiar with. He happend to have an engineering degree, but most wouldn't guess because 9 out of 10 people picked him out as a dead ringer for Charlie Manson. He was loud, sometimes dirty, dressed more like a biker than an engineer, and he was rude and stubborn. I liked the guy. I really did. But I think I held a rare view, as most people found him offensive and crude. Some refused to work with him. "I'm not changing that" was almost a calling card of his.
Yet in spite of all of that, he designed a frighteningly high percentage of the space hardware that actually flew. His time was in demand and he produced easily as much as the designers with more modern tools. I never counted, but I'd bet he produced more than they did. And it was good because he was brilliantly skilled at the real task at hand.
So in the end, the technology did not matter - the man did.
I don't bring that up to argue- just think there's something worth thinking about.
You bring up a good point, in that knowing the software is no substitute for intellectual comprehension of the problem. An extremely capable engineer using outdated technology will often outperform less capable engineers using more modern tools, especially when the problem or task is complex.
Even though the average engineer may be more productive with modern tools than the average engineer without them, there is danger in assuming that any engineer with modern tools will outperform any engineer with less modern tools. Just like software, tools can be an enabler, but they do not make the engineer a commodity.
But doesn't it stand to reason that if he'd been just a little more personable and just a little less resistant to change, he could have done even better?
I'll avoid the personability side of the question, but focusing on the "change" aspect: Let's not confuse "physical" tools - like a hammer, press, CAD program, or text editor - with "thought" tools - like a paradigm of programming, say, Functional or Object-oriented.
I'm still a rather young programmer (only about 6 years into my career). But I've found myself actually working in a reverse flow of technology, in terms of what tools I use on a daily basis to do my job. I'm primarily a Microsoft-stack web applications developer. I spend most of my day writing out c# and t-sql; often, using Visual Studio and MS Management Studio to interact with my code and the database. Those are the tools I used at the start of my career, when really getting the hang of basic programming.
As I've moved forward (career-wise), I now find myself using rather "older" tools for my day to day tasks. I hate to touch a Windows machine without Cygwin installed, as BASH is my primary interaction with the computer now. And I find myself generating code at a faster pace in VIM than I can in VS. As I've started using more Postgres databases, I've grown more comfortable with psql, and the terminal-based interaction with the db.
So the actual tools I'm using to generate my work are, in a sense, "old". I've found myself almost shunning new tools. Or at the very least, not embracing new tools _just_ for the sake of them being new. A new tool has to have some value aside from "newness."
Use of these "old" tools is not to say that my skills as a developer are lagging behind, however. The same even goes for the languages I've been using for personal projects. I find myself working out ideas more quickly in Common Lisp (how's that for old?) than I can in c#.
The point I'm trying to make is: don't focus on whether or not the person is using the newest tools to do the job. What's going to matter more is how well they understand the fundamentals of their discipline. Granted, I'm still young, but I feel like the craftspeople that really understand the core principles of their craft, and keep an eye on the horizons of their craft, are going to remain in demand (so long as the craft is needed). And if that craft is software development, it won't so much matter whether the coder is embracing Rails or not; what will matter is that s/he understands the new ideas that Rails might embody, and can incorporate those ideas into their daily flow.
Not necessarily. We don't know if what made him so incredibly productive sprung from those same qualities. In fact, refusing to learn new processes when the old ones still worked might have aided him in gaining expertise.
I know what you mean, but I would say no. This is getting a little philosophical, but bear with me. It's like saying, "what if Steve Jobs were a little more down to earth?" or "What if Nick Saban was just a little easier to get a long with?" It's tough to separate out what makes a man who he is. The same unreasonableness that made people not want to work with him is what saw his designs through to production unmolested by the compromises of what he would likely have deemed lesser minds (or "fucking idiots" as he'd have said).
Depends what he wanted out of life really. He may just have run into the point where having a little extra leverage would have been meaningless, or at least more bother than it was worth.
Because software has near-zero replication costs, the "manufacturing" process has no good analog for software industry.
I wonder how many "business people" have a hard time understanding this concept, resulting in the typical shortsightedness that results in Build It Cheap And Fix It Later, where "later" almost never finds its time.
The manufacturing industry is supported by an army of engineers in a wide variety of specialties. In fact, manufacturing, in some ways, is starting to look a little more similar to software, because the non-material costs of production are falling (automation replaces direct labor) so replication costs are falling. Manufacturing will never look exactly like software due to the intrinsic role of raw material costs and the capital costs of production equipment, but there are increasing similarities.
As manufacturing has become more automated, a greater emphasis is placed on the role of engineer: in an automated factory, there is greater need for skilled engineers and lesser need for direct operating labor.
While better software has also helped these engineers become more productive, the net effect has been to improve quality of engineering output rather than to reduce engineering demand. (The exception is people working with engineers, but at a lower skill level. For example, there is little need for draftspeople.) Examples of this improved engineering output are flow simulation software that allows engineers to better push the envelope in part design to reduce part weight and improve production cycle times.
The net lesson from manufacturing engineering is that software engineers will continue to be in demand -- likely even higher demand -- so long as they continue to evolve their skills to use the more powerful software as it becomes available. The more powerful software will lessen the cost of software, which will increase demand for it, and increase demand for the skilled developer. For example, abstraction platforms such as Rails increased demand for those who evolved their skill set, because cost of web development fell due to higher productivity, thereby increasing demand for it.
However, like a draftsperson or an engineer who refuses to learn Solidworks, the more powerful software will be a negative for those who cannot, or choose not to, evolve their skill set above a more basic level.