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.

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.

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.

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.

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.

I think you misunderstood. The product a software engineer makes is not a CD that lands in a person's hand. It's the arrangement of bits that eventually ends up on that CD. The OP is saying there is no way for a machine to arrange those bits.

First of all, let him speak for himself. Or do you claim to read his thoughts?

Secondly, no he doesn't seem to understand. The statement he disagreed with was: We cannot put software on the kind of assembly line/stamping process which is obviously a point about the fact that we have no assembly line process for writing new software.

He replied with: Stamping out software is what your Windows/OSX/linux installation CD/DVD is which is obviously missing the entire point. We are talking about writing the software, not putting the software on the disk. It's a distinction you've clearly also missed.

Is mind-reading the only way people can understand each other? Words don't seem that unreliable.

Another way to look at it is coach builders. 100 years ago, there were many more coach builders and custom car manufacturers than there are today. Car was also a luxury item. That started to be disrupted by mass produced and mass distributed cars, like Ford.

Today, most companies that hire "web developers", are either building things using packaged libraries or modifying things to fit. They are not taking off the shelf components and connecting them without modification. Even tools like Salesforce.com default to people writing code to solve complex configuration issues. The UI is catching up, but it's not there yet.

The whole quote shows he disagrees and thinks the analogue is wrong

You only excerpted part of the quote which was contradicting the other interpretation of what the product was, not the explanation of what he thought it was.

I mean, gvb's alternate analogy is also a good one. Yes, writing software is like configuring the assembly line, and yes both of those things are expensive work for highly-trained professionals. And yes the interesting difference is that 99.999% of the cost of making software is this design, whereas in car manufacture it's maybe 5% or 20% or something (and the actual stamping is the rest). This is a good analogy, sure! It's also hopefully old news for basically all of us. Isn't it?

But sologoub's analogy is a different one, and it's also a good analogy, and in my experience a less-overused one. And insofar as it's more-novel (to me), it's more instructive, and thus "correcting" it with an overused analogy suggests lack of understanding.

Sologoub's point, to attempt to restate and simplify, is this: the value and scarcity of modern engineering is comparable to the value and scarcity of pre-industrial artisans. Industrial artisans because less valuable when industrialization commoditized their work. And sologoub proposes that this could one day happen to software development (and other engineering), and if/when it does, (software) engineering will cease to be lucrative. I think it's an interesting model; I have no idea if it will be possible to industrialize software development, short of god-AI taking over all human labour.

Artisans always were tied into the production as well as the design. Mass writing ability however is more what you're seeing like the internet did to journalism. I anticipate something like THAT happening, not something related to artisans really.