Software already went through the industrial revolution. To take your analogy, the car designers (the ones who work to build the prototype) are all craftsmen. Once the car is designed and we make copies of it, that is the industrial process. In software, the industrial process is trivial.<p>The car designers who build the first prototype, tweak it, make it actually work would call themselves craftsmen. They might use parts of other car models (same as we use libraries), they might duct tape something (same as we hack things), but the fact remains they are craftsmen.<p>I would also like to point out to one of the better arguments for this from Dijkstra - <a href="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html" rel="nofollow">https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...</a> - you actually have to think across many abstractions and as a result, writing software remains a craftsmanship.
To add to NhanH's earlier point [1]: I think it's an overall interesting thought, but the whole argument hinges on an unfortunate association fallacy [2] itself premised on a leaky and questionable analogy.<p>Besides, as you well know, there might well be very good complexity-theoretical reasons [3] for drawing a distinction between the easily scriptable, repeatable, limited-state steps required to implement/carry on a solution for a given problem; and the non-trivial steps it took to <i>come up</i> with that solution in the first place. It seems to me the great successes in automation during the industrial revolutions were mostly about parallelizing the former, not the latter; while most day-to-day computer programming predominantly involves the latter, not the former. One way or the other, it's far from evident the analogy is even applicable in this case.<p>[1] <a href="https://news.ycombinator.com/item?id=7724501" rel="nofollow">https://news.ycombinator.com/item?id=7724501</a><p>[2] <a href="http://en.wikipedia.org/wiki/Association_fallacy" rel="nofollow">http://en.wikipedia.org/wiki/Association_fallacy</a><p>[3] <a href="http://www.claymath.org/millenium-problems/p-vs-np-problem" rel="nofollow">http://www.claymath.org/millenium-problems/p-vs-np-problem</a>
The "car manufacturing process" doesn't even happen anymore in the software industry. A few years ago the manufacturing step was to press the installation CDs. The closest analogy today is to deploy the software for distribution.<p>Instead software development is the design process of a new car, coming up with new ideas that make the new car model better/more efficient/cheaper then the past model, testing and tweaking all these improvements, making sure all the components and little pieces work well together.<p>The industrial revolution didn't really improve this step, it only made the manufacturing step at the end of the whole process more efficient.<p>I consider industrial designers and software developers still as craftsmen in the best sense of the word.
It's a big industry out there. There are those who make bespoke products, and those that take a number of pre-built more general purpose libraries and just stitch them together, and everything in between.<p>Stitching together libraries is easy and generally quick to produce an initial product, but can become difficult to maintain/extend and is wasteful on both run-time and development resources. This method is pretty forgiving to those that don't know exactly what they are doing, and you don't have to have any experts on your team to produce a "working" product. You will accrue lots of technical debt this way (but in a lot of projects is doesn't matter much).<p>Bespoke products are difficult to architect and build (properly), take a long time to develop, but are performant, malleable and predictable when done right. If you do it wrong (or your architect is hit by a bus), you have a huge mess on your hands.<p>Most of my experience has been about two thirds bespoke, one third stitching. In my experience, finding the right ratio depends on the amount of scaling the product needs to do, how much you're willing to spend on talent, how unusual your requirements are, and how screwed you're comfortable being if things go wrong.<p>I have never seen an instance where a well built bespoke product did not have a competitive advantage over a stitched one. Generally a large competitive advantage. I have also seen a number of poorly built bespoke products crash and burn; so take that as you will.
I find myself quite convinced of this today. I believe that, like the industrial revolution, there needs to be a reduction of time-consuming effort to make it happen.<p>My thoughts lead to thinking that machine-aided development will be a major step forward. Part of this I believe is discoverability in what we make. Perhaps another major step would be to reduce the time to express the intent in code.
> Like craftsmen in the past, every line is bespoke, every function something toiled over. [...] None of them worried about how to build the screws that hold it together.<p>Many years ago I wrote a video game in x86 assembly. (It was a shitty Snake game, but still) That code was burping out pixels direct to the VGA framebuffer. That code was pretty manual, and every assembly instruction that ran was designed and typed in by me.<p>Contrast that with modern web development. You're getting TONS of functionality for free. Did you toil over every line of the node.js code? Did you worry about how the interpreter stored your data in a pretty optimal data structure, gave you the illusion of nearly-infinite memory by garbage collection, or automatically cached a bunch of stuff that you never had to think about? And let's not talk about the encryption library, or the networking code, or the OS, or etc, etc.<p>In other words, I <i>don't</i> think modern web developers worry about the screws that hold it together, but man, they are still still there.
Proposals to industrialize software development have a long history, for example at the NATO conferences in the 1960s
which coined the term "software engineering":<p><a href="http://homepages.cs.ncl.ac.uk/brian.randell/NATO/" rel="nofollow">http://homepages.cs.ncl.ac.uk/brian.randell/NATO/</a><p>and in the "software factories" of the 1970s and 80s:<p><a href="http://en.wikipedia.org/wiki/Software_factory" rel="nofollow">http://en.wikipedia.org/wiki/Software_factory</a>
Part 2 is now live! You can read it at <a href="http://www.scaletheplanet.com/post/the-industrial-revolution-part-2" rel="nofollow">http://www.scaletheplanet.com/post/the-industrial-revolution...</a> and comment on HN at <a href="https://news.ycombinator.com/item?id=7758174" rel="nofollow">https://news.ycombinator.com/item?id=7758174</a>
Hi all,<p>For what it's worth: this is my very first blog post, and it's a bit of an unusual one. I'd love to hear any feedback, good or bad.