We also can't do this with writing. Is software more like writing prose, or more like manufacturing? That's the heart of the issue as I see it, and to me it looks more like "writing."

It is possible that AI software will eventually produce better writing than human writers, but that seems unlikely without human-like AI and also seems far enough into the future to be highly speculative.

The fact is we design and make the archetypes. These get mass-produced by computers.

That may be a silly example but that's just one avenue (wordplay) of lateral thinking, a subset of creative thought and processes.

Stamping out software is what your Windows/OSX/linux installation CD/DVD is. Microsoft is making a lot of money stamping out (figuratively nowadays) copies of Windows.

Software engineering is the equivalent of the mechanical engineer combined with mold maker for plastic or stamped parts. There are a lot of tool and die shops around me that are making a lot of money[1] making molds.

[1] Well, they were before the auto market tanked, but they are doing OK again.

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.

Such a naive view.) The whole Java ecosystem was especially marketed as a "industry standard" way of creating a "coding sweatshops". All you need is coding and testing teams, and a bureaucratic process (such as Scrum) on top of it.

With very rare exceptions of some OSS or in-house projects (Google, FB) most of software industry consists of such sweatshops which are almost an assembly lines which produce bloatware that mere passes most of tests.

Have you ever seen so-called Enterprise Software? ERPs? Web-portals?) Or take a look at the bloatware MS produces - these all products of such software-manufacturing processes.

Now about an artisan analogy. True (gifted) artists are extremely rare nowadays as thew were in the ancient times. Just take a look at the few examples:

- the requests module for Python. It is such a rare example of clean, idiomatic, human-readable Programming (not mere coding) that it could be considered as an art of programming. How many other modules programmed with such craftsmanship are around?

- nginx and redis are the example of the art of Software Engineering. They are works of art because of an approach and personal involvement of its authors.

- Plan9 team, FreeBSD's and OpenBSD's core teams, the author Gambit-C, authors of MIT Scheme, Symbolics Inc., the authors of Emacs are examples of a teams of gifted programmers.

If you want to see the examples of PG's "painters" - these people are. They are artisans of our craft. OK, there might be few hundreds more of such craftsman in the past (who created Lisps and other marvels) but it is mere 1% of all the field.

However, software is still an intellectual, out of thin air, endeavor. It requires thought to create new and make work with existing circumstances. You aren't melting metal into a mold to make a tangible object. You are literally fusing thoughts and intellectual processes together to do it with software. Until thinking becomes mass-produced and optimized to the point of max efficiency, I don't see this happening.

I'm working on an idea tied to literate programming where someone can tell a story of what they want a program to do, put it in a wiki, and then programmers can edit the wiki to add in the actual software to make the program work. How hard would it be to use NLP parsing, feed it into something using the priciples from BDD, take something that turns that into UML the run it through a code generator and you have an MVP. Software engineers may then end up like manufacturing engineers in that their job is to tweak and fine tune the output. But even then that part of the job may fall to ML which recognizes similar patterns between software implementation and optimum utilization (there are only so many ways to write a user login page on a web app for example)

I think thinking will never become mass-produced, but Mass-producing turning thoughts into software may happen within my lifetime.

Edit: missed out the main point from my last sentence.

However, as powerful as the tools get, you still have to tell the machine exactly what you want it to do. Depending on the tool, sometimes that is easy, sometimes that is hard. I feel like there should be a fundamental law of "ability to easily express" vs "flexibility of expression." I'm not sure how much machine learning can serve as our savior in this regard, even if we can eliminate "make an Amazon clone" posts on cheap-outsourced-developer.com by just using ML to classify it and spit out the boiler plate.

In order for something to be profitable it has to be customized, and when this happens the abstractions inevitably seem to break down. Based on this I think turning thoughts into software will happen around the same time thinking becomes mass-produced. How can you create, "eBay, but for car buying, with a twitter messaging component built for the Brazilian market" without first beating the Turing test as a sub-problem?

Change value of potatoes to 10. (potatoes = 10).

Make potatoes equal 10. (potatoes = 10).

Give every person at the dinner table a potato. (for x = 0; x < dinnerTable.count; x++ {dinnerTable[x].potatoes += 1})

Etcetera.

So, I want to check my diary and see what I need to do today. Anything really important should flash, so I know I need to take care of that. But, I know that my boss is waiting for me to finish that puff piece on our new acquisition, so double flash that. Also let me know I need to buy cat food. Stat.

Make a program that can parse that piece of text and you're onto a winner. (I'm trying)

Syntax should be the least of concerns, and even if it wasn't, involving the subtleties and ambiguities of english language wouldn't be the solution.

EDIT: I don't mean to say that a natural language programming language couldn't be useful, but I'm arguing that it won't be unless you can use natural language to move closer to the problem domain, rather than abstracting the solution description further.

But leveraging already existing SW (OS, stacks, web tools etc) is what makes us much more productive today compared to 20, 30 or 40 years ago.

When I started programming in 1973, my boss (who had a PhD in computer science) said that there was a factor of 100 difference in the productivity of different programmers he had worked with.

Even if this differential productivity remains, as tooling gets better I have to wonder how many software engineers will be needed in 20 years if all programmers become much more efficient?

The invention of compilers was a huge watershed moment for programming. All the manual labor you had to do, keeping track of memory layouts and registers and stack frames, was handled automatically for you. Yet the result is not that programming became easier - it's that programs became more complex. A journeyman programmer today can write Tetris in a few hours, while it took how many months for the original? But modern games are things like Starcraft 2 and Halo, not Tetris and Space Invaders.

Same with databases. It used to be that you had to think in terms of bytes in sectors on a disk. Now we have filesystems and databases and query languages to abstract that all away from us. But that doesn't mean programming the systems becomes easier, it means that the volume and variety of data stored increases.

It used to be that domains like speech recognition, natural language processing, text mining, computer vision, OCR, etc. were completely off-limits for computational approaches. Now we have standard libraries for them, and standardized tools for generating those standard libraries. But that just means the tools get applied to progressively more problems, not that solving those problems becomes easier.

I think this is what Marc Andreesen meant when he said that "Software is eating the world". There will eventually come a time when no more software engineers will be needed, when they have automated themselves out of a job. But that time will come when everything we do is computerized, when every aspect of modern life is ruled by algorithms and data. Until then, advances in technology just mean computation can be applied to more and more problem domains.

It seems to me, and I may be wrong on this, that the complexity of the problems that most programmers are approaching doesn't scale on a 1:1 basis with the power of their tools.

If all of our "CRUD apps" were truly just CRUD apps we would have built them all in 10 minutes with rails scaffold.

i like your name too!

Greater labor efficiency in the production of a good only decreases the quantity of labor directed to producing that good demanded in the market when there is either some non-labor (or different kind of labor) input to production of the good (e.g., in agricultural productivity, land would be the non-labor input) whose supply is limited, or quantity demanded of the output good goes past the point where cost declines are responded to 1:1 with increased quantity demanded.

Given the number of existing and potential markets for software and the relative transferrability of programmer skills and effort between those marktes, I would be surprised if the latter was true, and I don't see an obvious non-programming constraint on the production of software that would be limiting.

The trend so far has been that when you improve programmer productivity, you increase the value of what we do, which increases the number of things that we can be useful for. This increases demand.

I think that we already made that advancement in our industry its just that we are making lots of new products that require lots of engineers to make the machine that makes the products.

About the issue of the molding process, even intel with a fpu bug has problems and not just only software has issues whit errors early in the process