Except that in software 1000's of groups have already dug 1000's of canals and yet the next group that will build a canal will insist on doing it their way.
If our profession would only be able to simply collect lessons learned and to pass those on to the next generation then we'd be moving faster on average and we'd produce better software. we don't need 500 crappy, slightly different ways of doing the same thing, we need maybe 5, battle tested and hardened bullet proof solutions that are well engineered. Fragmentation is going to be open source's death at some point if this continues, that's one area where closed source actually has an edge: focus.
In part the problem is that software producers have managed to convince the buyers of their goods and services that they are never ever liable for their product (something no other industry has managed to do), in part it is because it seems superficially easy to re-invent until you reach the same level of complexity (which inevitably happens) as what those 'archaic' solutions were already addressing.
I don't have any answers on how to solve this, unfortunately, but there are software eco-systems that really get this right and others that seem to be totally lost in ever expanding cycles of endless rewrites.
Surely it has nothing to do with the buyers of our goods and services insisting that the problem they need solving is unique, so trivial it should be done yesterday, and so clear that they dont really need detailed written specifications? To say nothing of IP concerns making it difficult to actually reuse solutions.
If customers/bosses actually figured out what they want before coming to us, it would be simple to write a perfect solution and/or reuse some existing general product to fulfill their needs. As my experience says, however, the requirements keep changing in parallel to the code.
In other domains this tends not to happen. When you're in the middle of constructing a beam bridge, you don't get an architect suddenly deciding it should be a suspension bridge instead.
Now I'm not saying iterative development and discovery is bad - it's not. But, with iterative development, you treat steps as throwaway, and you don't commit to deadlines. Something the bosses / customers don't understand. You can't have it both ways.
No, unlike e.g. civil engineering you're never doing the same thing twice and you're always doing something you've never done before because if you have, you could just use that code.
You can't copy-paste a bridge but you can re-use software.
You possibly don't now much about civil engineering, let me start out by writing that every project in civil engineering stands on it's own, it is the knowledge and the practices that get re-cycled from one project to the next and on a higher level from one generation of civil engineers to the next.
So it is extremely unlikely that civil engineering will be done twice for an exactly identical project. But no civil engineer is going to make his own table for bolt tensile or sheer strength just to scratch an itch.
Then we come to software, in software the same problems appear over and over again and we have in the 100's of possible solutions for some problems that are all almost (but not quite, of course due to sloppy design and lack of standardization) interchangeable.
Think web frameworks. They are themselves an attempt to abstract away some elements that are common, but in the meantime there are almost as many webframeworks as there are things that they were trying to abstract away to begin with (and all of them fail on one or more of the details). Or programming languages, another area in which we have re-invented the wheel so many times that the number of programming languages (1000+) will at some point probably exceed the number of human languages (about 6500 in active use, but about 2000 of those have < 1000 speakers).
> You possibly don't now much about civil engineering
I don't, so maybe it's not the best example.
But take houses for example, it's not common to see a dozen or more identical houses being built. After you've done 11, number 12 is not going to be much different.
But the foundations might be slightly different to account for terrain differences. And that will not cause the civil engineers involved to re-define what a bulldozer or backhoe can or should do and how it should work, nor will it change the process they will use to make that foundation.
In fact, the house sitting on top of the foundation will likely be the same project if they really are identical, just like copies of a piece of software, in other words, from an engineering perspective the job as far as the house is concerned was done with #1 if you want more than one house.
It's all about the tools, processes, materials, soil knowledge and so on that are being employed in order to solve the problem, not about what is actually built.
In the software equivalent there would be a new build process with associated terminology and tool obsoletion for almost every engineering project. Imagine workers coming to the job one morning to find that the tools they used the day before have now en-masse been declared obsolete and all their technology is slightly different, incompatible and un-tested. Then, a few weeks later at another job site it would be the same story all over. In the meantime, the engineers would be re-inventing engineering from first principles for every 5th job or so.
In other professions that would be called madness.
"Imagine workers coming to the job one morning to find that the tools they used the day before have now en-masse been declared obsolete and all their technology is slightly different, incompatible and un-tested."
This is one reason software is eating the world. It's actually possible to build new tools to increase productivity and start using them in a very short period of time. Sure, most of the tools are crap or marginal improvements at best. But with so many new ones being developed constantly, occasionally one offering real benefits shows up and every developer can benefit almost immediately.
I also think you vastly overstate the amount of "NIH" and vastly understate the massive amount of actual reuse.
How many developers use Apple's UIKit to build apps? Yes, a small number reject some out of the box components, but I'm sure many more developers just use what Apple provides as the building blocks of their application. Very few people write their own networking stack or HTTP library. And as much as newer programming languages get massive hype, the same languages tend to dominate the Tiobe rankings year after year (or whatever popularity metric you prefer).
In other words, focusing on what gets posted to Hacker News probably doesn't reflect the experience of the median developer.
Software is a tool. What you do with it is an outcome.
A bulldozer is a tool. The house is the outcome.
So, we already invented a bulldozer (some piece of software) and it's trivial to duplicate it and reuse it all over the world. But when we need a new type of machine it's harder because, well, it's new.
In the software engineering world the goals is generally not to facsimile something like e.g. a house. It's to create a legitimately new tool. And since there are no real capital investments required (unlike building new tools in the physical world), and folks often value their free time at a weirdly low marginal rate, you end up with tool proliferation in a way not seen in the physical world, which makes it easy to think that we're building houses when in fact we're inventing the bulldozer.
More likely: to create a minor variation on an existing tool. There have been relatively few instances of legitimate new tool creation but many 100's (and probably 1000's) of instances of re-creating slight variations on the same tools.
For instance: build tools, programming languages, libraries (95% duplicate functionality with some other library, and of course an inconsistent interface) and so on.
> And since there are no real capital investments required (unlike building new tools in the physical world)
Software requires enormous amounts of capital, in part due to all this re-invention. We even have a name for it: NIH, and we have a term for what happens to a software project that is a few years old (technical debt).
Our tools and our processes are ill equipped to deal with the challenge and what is supposed to be building houses more often than not ends up with people re-inventing the bulldozer.
Now there are times when that is the right thing to do, but most of the times it isn't.
Slashdot, Reddit, and HN are different tools. On the surface they seem similar, but so does a Philips head screwdriver and a Frearson, yet they really are different tools.
They're different end products, but they are not different tools.
Conceivably they could have been built with the same toolchain, but instead they were all built with totally different tools (Perl, Lisp/Python, Arc) respectively.
Because in engineering there really are such requirements. In software we rarely have a good reason to start yet another 'from scratch' new hip thing that is so much better than that old thing (where 'old' is likely less than 5 years old). Technology cycles are now so short that libraries and frameworks don't even bother pretending to have a life-span longer than the stuff that will be built upon them.
And those engineers with their 'hundreds or even thousands kinds of screws', they very much favor standardization, lots of work goes into attempting to create families of compatible tools and consumables and typically a change like that will result in decades of stability in the fastener industry, it is quite rare for something revolutionary to happen, most of the changes are incremental and logical.
If you attempted to come up with a completely new thread or screw head there would have to be a reason better than 'I don't like the other screws' if you expect to gain any acceptance of you shiny new tech.
I'm trying to imagine a world where every other week the whole of engineering would be up-ended, everybody would have to totally re-train and we'd discard everything we learned process wise over the life-time of the industry.
That would be the rough equivalent of what we do in software. Ok, maybe not two weeks, but we might actually get there, life-cycles are getting ever shorter.
So if you stepped back 5000-10000 years in engineering, you'd notice that civil engineers... Basically did exactly that.
You're just being extremely unfair in comparing a field with ~10,000 years of development with one that has like... 100.
Everything you've called out as unreasonable is pretty much what every field, ever, has done when it first became a discipline, and your specific criticisms border on absurd.
Programming languages, for instance, are like materials: of course there's thousands, most of them are meant for research purposes, and the hundred or so used ones each represent different tradeoffs in base construction strategy. No different than the dozens of kinda of wood and concrete used by civil engineers.
Similarly, engineering of civil projects has some notable massive overruns on budget and complete design failures in even recent history. Their projects are bespoke and often use novel ideas that don't work out in practice.
The main "difference" is you're comparing a high assurance subset of one side to the general of the other, which is naturally quite unfair.
Want to compare the fields in full? I bet I can find a dozen bad handyman repair jobs for every bad JS framework or library.
But we already have engineering as an example of how to do something like this right, there is no reason to go through another 5000 or 10000 years to figure all this out once more.
And the handyman and the engineer have very little in common.
Civil engineering had thousands of years of development when Galloping Gertie happened. Why would their methodology work in other, different engineering fields when it fairly routinely doesn't work in its own? I mean, if you look at things like project failure percentage (and cost!) over time spent developing the field, you probably have software winning.
Software is developing in to an engineering profession at an astonishingly fast pace. It's just currently at the point where it's differentiating between tradesmen and engineers, and without that clear distinction, it's hard to compare apples-to-apples between fields.
> And the handyman and the engineer have very little in common.
Why not? You're lampooning software development for the fact that a lot of not-quite-professionals develop mixed results because they churn a lot of product onto the market. The damage done to house integrity all over the world by questionable repairmen estimating the engineering impact of a change they make is comparable.
My experience with high-assurance software is that it's similarly well constructed and engineered to high-assurance civil engineering, eg, major bridges. Failures happen, but are sporadic rather than regular.
"My experience with high-assurance software is that it's similarly well constructed and engineered to high-assurance civil engineering, eg, major bridges. Failures happen, but are sporadic rather than regular."
Where did you experience high-assurance software and is there a report on how it was made? There's very few here that even know what that means although I've been working to change that over the past year or so. Always collecting more from that tiny field for any lessons learned that could be shared.
I worked in control firmware and systems middleware/OSes for chemical processing equipment (and related control systems). None of the super fancy, huge plants; more single room sized processing pipelines for R&D uses. That said, the bigger chambers were like 0.2m^3 and operated at 2500PSI @ 100C, so you'd definitely know if one catastrophically failed.
We didn't necessarily develop a lot of process in-house, because our senior engineers had backgrounds with Boeing and/or NASA, which both had extensive ideas about how to design reliable systems.
If I were summarizing, there's only really two points that cover about 90% of what you need to do for high assurance software:
1. Realize almost all bugs are because of politics and economics, not technological or engineering faults per se. That is, we make choices about how we set up our culture and corporate system which incentivizes people to create and hide bugs, while also failing to incentivize others to help fix that bug. The first step in combating bugs must be to change the fundamental incentives which create them. In particular, a focus on the success or failure of a team as a whole. Development is a communal activity, and the entire team either succeeds or fails as a unit. Someone else committed a bug (and it got merged all the way to deployment!) that brought down the system? It's because you didn't provide the necessary support, teamwork, and help with engineering your peer needed to succeed. What can you do to help them succeed next time? After all, everyone is human and makes mistakes. What's important is that the people are interlocked in layers, where one person can catch another's mistake (without punishing the person who made a mistake, because that just incentivizes them to hide them!) and help fix it before the code reaches client machines. Successes may be individual, but failure is always the system's fault, never an individuals.
2. Almost all technical bugs, in any field, are because of leaky abstractions and implicit assumptions. From abstract ones like mathematics to physical ones like carpentry. Be explicit. About every possible detail. And if you think you're being too explicit, you probably forgot 80% of the cases. Ever see the average house blueprint? Puts software engineering design to shame, easily. If you want to build something that runs as reliably as a highly tuned, expertly designed engine, you can't start with anything less than as detailed of a specification as they use. Be explicit.
Once you get to the point where you're working in genuine engineering teams rather than as individual engineers on a team and you have explicit, detailed specifications, the technologies to actually convert that reliably in to software that runs stably are pretty straight-forward.
The reason we don't see this all the time is simply that it's expensive: the politics require a lot of redundancy of time spent (eg, code has to be read several times by several people); the explicitness requires a lot more upfront planning and effort in documentation, which requires more time invested per unit of actual coding; etc.
Of course, much like we have building codes for houses and larger structures, I think it's perfectly fair to expect minimal standards from software engineers. (Especially now that, eg, IoT botnets are DoSing things.)
Appreciate your write-up. It all sounds great. I'd say the tech to go from detailed specs to reliable or secure systems isn't necessarily straight-forward except in the easy cases. It can take some serious work by smart people, esp if it's formal verification or spotting unknowns. We can easily get 90% of the way there, though, without the hard stuff just by people giving a shit and doing stuff like you said.
Of course, Cleanroom Software Engineering that does a lot of what you said without as much formal stuff as Praxis's method. Thing you should remember in these conversations is to point out to other party that what you recommend and what these methods did knocks out tons of debugging and maintenance costs. Since both phases cost labor, with maintenance fixes multiples of development cost, there were many cases where Cleanroom projects actually cost less since they knocked out huge issues early on. Can't bank on that being normal with it often being 20-30% or so more. It was around the same or less cost in many case studies, though, due to knocking out problems earlier in development.
Btw, I found a nice write-up on Cleanroom without tons of math or formality with case studies on college students if you're interested in references like that:
I like dropping them on people in regular development in these discussions when they say you can't engineer software, it takes ridiculous skill, or it would cost what NASA's team spends (rolls eyes). Eye opening experience for some.
> I'd say the tech to go from detailed specs to reliable or secure systems isn't necessarily straight-forward except in the easy cases. It can take some serious work by smart people, esp if it's formal verification or spotting unknowns.
I was being a little facetious. Of course the technical work is highly complex -- some of the brightest minds of our time work on DARPA related projects on foundational mathematics related to automated theorem proving. (Looking at you HoTT crew and related projects!) Why is DARPA funding automated theorem proving? Because they want to create high assurance software for government infrastructure to counter the threat of AI-based cyberwarfare, and our current mathematical techniques aren't up to muster.
However, we've made tremendous progress on that problem in the span of around 100 years. By contrast, the problem of how to not incentivize your workers to do a shitty job, causing you problems later on... has been with us, I think it's safe to say, for thousands of years. (And it too, has attracted some of the brightest minds over the years.)
So in a relative way, the technical aspects are "straight-forward" to address, compared to the underlying political problem. And the more technical methods only add some assurance that you've correctly implemented the spec as defined, not that you're doing the right thing. It's certainly good to, eg, check that you're using total functions or not misassigning memory, but it's not magic. So while they catch a lot of dangerous problems, they can also lead to false confidence about the existence of other classes of problems.
> they say you can't engineer software, it takes ridiculous skill, or it would cost what NASA's team spends
It mostly just requires that we consistently act with discipline and professionalism, which are both tiring compared to not doing them, so by and large, people just don't bother. I know I don't when I can get away with not doing it (even if I know that's a bad habit).
The reasons why you can name those examples is because they are the exceptions. If you tried to do the same for software the list would likely exceed HN's capability to store it.
You could say the same about construction projects that are 30+% over budget. Kitchen renovation IMO actually has more in common with software development than home building. Homes are generally built for generic people, kitchens are renovated to meet specific needs.
How is the number of web frameworks any different from the number of possible building facades? Even if you decide you want a glass facade, there are dozens of companies that can build that for you, and they've all re-invented essentially the same thing.
The same can be said for nearly everything else. Insulation systems, HVAC, lighting, interlocking brick, drainage...
But, you would expect your house to stand upright, all the fixtures should work (and work in an expected way), the roof won't leak, your house should be solid and so on. And if it is not you'd expect the producer to put a warranty on their product.
Choices made are made for aesthetic or engineering reasons or cost or some other constraint, rarely because the tech is 'fancy', 'new' or has been invented by the crew building your house. Bricks will be laid on plumb walls, the roof will be strong enough to support the expected load and so on and if any of it fails you will be surprised.
Note that most of this is stuff that has already been engineered elsewhere that is is combined in some novel way, and for the most part all of the materials can be used together, are standardized as much as possible and your average build crew will be able to move on to the next job without having to re-learn their whole knowledge base because what they did last week is now so '2015' that they are essentially useless unless they get with the times.
Not all software developers consider something from 2015 'old' and immediately jump to the 'fancy new' stuff that came out this week. See the discussion on "Happiness is a Boring Stack"[0] from yesterday.
There are crappy new building materials that don't work (which you often don't figure out until years later when you have to replace your roof or windows or siding or doors), and there are bad crews that do crappy jobs.
This is really no different from software, though I'd argue it's easier for the crappy developers to continue working. This partly has to do with your website having ugly-but-working code has little impact to your typically business owner, while having bricks that are crooked and unevenly spaced -- even though they're perfectly functional -- is highly visible to everyone.
The bricklayer that does a functional-but-ugly job gets a bad reputation immediately. The website developer that does the same thing isn't found out until much later when you have to modify the code.
> This is really no different from software, though I'd argue it's easier for the crappy developers to continue working. This partly has to do with your website having ugly-but-working code has little impact to your typically business owner, while having bricks that are crooked and unevenly spaced -- even though they're perfectly functional -- is highly visible to everyone.
But in the wonderful world of e-commerce those unevenly spaced bricks are roughly the equivalent of the gap a skilled hackers needs to enter your store or to raid your db.
Also, it is probably important to make the distinction between engineers and contractors, engineers design stuff, contractors execute the designs.
In the software world we used to have these people called systems analysts, they would be roughly the equivalent of engineers, whereas the programmers were more comparable to bricklayers.
Then for a while we had 'analysts-programmers' and now the whole analyst bit has disappeared. This is a pity because I think it was a very valuable role and worthy of being an independent discipline because I believe that there were people that were good at these different aspects of the work but rarely really good at both.
In all fairness, if someone throws a brick through your window you'll have police at the scene in relatively short order and most buildings don't need to worry about their doors being proofed against C4. On the other hand, if your software project gets hacked or DDOS'd you have no recourse unless they're incredulously sloppy or you're a mixture of wealthy and influential.
I do think software engineering as a profession should take notes from other engineering disciplines - but to compare them apples to apples is a touch unfair when our discipline is much newer, routinely attacked by bad actors (fer teh lulz, no less), and we're regularly updating our toolset to accommodate for changes in a much more rapidly-evolving landscape.
My title is actually "Senior Programmer/Analyst". But, I think your observation is correct that it's not as common to have a title like mine anymore.
It's strictly due the historical development of our field. Computer systems were limited to large organizations in the early days. VMS, Unix, Windows, and less expensive hardware allowed smaller, less well-funded organizations to jump into the game.
In internal IT departments, software developers have become the "jack-of-all trades, master of none" people. We fulfill analyst, developer, operations person, and support with little to no training in any area. IMO, part of the reason software systems are so fragile nowadays is this "generalist" mentality. Mind you there are plenty of other factors that are, IMO, mostly social.
All that said, there is a tendency to think of software development like assembly line manufacturing. There was a Dyson vacuum ad that I loved. The supposed owner of the company showed the vacuum in operation and then talked
about the 239 (not sure of the exact number) versions that came before it. Once the company got it right on the 240th model, mass-assembling the vacuums was quick. Building a model, letting users work with it, integrating their feedback into a new model, this embodies software development. And it's expensive along at least one of two dimensions: money or time.
In software, programmers are the engineers, and the compiler is the contractor. The software equivalent of brick laying was automated away long, long time ago.
A compiler is merely a powertool, not the contractor, anything it does you could do by hand but slower. We've tried (several times) to create the software equivalent of brick laying aka 4th generation languages but to date they have all failed to attract mainstream attention, mostly because they simply don't work well:
> A compiler is merely a powertool, not the contractor, anything it does you could do by hand but slower.
Only in a sense in which you could do all the things a contractor does yourself, but slower. In both cases, you'd need to first learn what the compiler/contractor is doing. If anything, the compiler is a powertool that automates away the contractor completely.
I dislike comparisons of software to construction and civil engineering anyway. The two seem nothing like software. They have nowhere near enough (literally) moving parts to reflect the way software works. The closest thing to a comparable discipline that comes to my mind would be designing and building jet engines.
Having worked with PE civil engineers out of college I can confirm they don't do anything new. Civil engineering at this point is pouring concrete. Concrete is an understood material. They mainly deal with permitting, fixing a cad drawings and arguing with architects (who are also not doing anything new). Once and a great while they do something new like expand the bay bridge. Then you get to see civil engineers try to solve an actual problem. A decade(?) of work on a bridge that could have been completed quicker in 1929.
I think you slightly missed the point there. The video is of a bridge designed to span a highway that was to be expanded from 2x4 to 2x5 lanes + an emergency lane on both sides with minimal interruption to existing road and rail traffic.
The decision was made to construct the bridge off to the side of the road on a separate spot, then to create a special purpose roadway across the road to the location where the bridge would be placed. And finally, to move the bridge from the construction site to the final destination in one piece.
The whole thing was conceived and executed according to plan, including a < 24 hour closure of the road and one week of interruption on the rail line (it was not possible for many reasons to have the track installed prior to moving the bridge).
That is engineering. In the 'move fast and break stuff' world that would be 'move fast and kill people'.
If this were software we'd be looking at a multi-year software project with a few hundred programmers delivered on-time, within the budget and working flawlessly on the day of delivery.
I have yet to see such a project. But as you say, 'Amazing!', the fact that you make it seem like this is 'no big deal' is exactly what is so good about it, you fully expected it to work didn't you?
The trick apparently is to make the complex and impressive stuff look so boring, I really wished that we could make software look that boring.
NASA does that regularly. They're seemingly the only people who can afford it.
If bridges had scope creep the way software does, every bridge would start out 1 lane each way and be 6 lanes double decker in the middle before all lanes fly in different directions towards different cities, much less the other side of the river.
I hear what you're saying about using tried-and-true methods. But nothing else has scope creep like software does, because basically nothing else is design-only. That's why software is so crazy. It's ALL design. There's no manufacturing at any point. You can manufacture infinite copies for almost free, i.e. compile and copy and install.
If you could go from bridge design in CAD to actual working bridge in meatspace in ~30 seconds and for $0.01 then yeah, there'd be millions of horrible, horrible bridges EVERYWHERE.
The fact that the design of the bridge takes a year or two and a few million compared to the 2-5 (or 10) years and billions to actually manufacture it means that you can design, redesign, and redesign again until you get a design that'll actually work and it barely moves the needle on the total price tag.
But in software, if you redesign and it doubles the amount of time to complete the project, you just doubled the cost at least.
If it were possible to make software better, faster, cheaper by just imposing some discipline, why haven't dozens of companies done so and taken over the world?
> If you could go from bridge design in CAD to actual working bridge in meatspace in ~30 seconds and for $0.01 then yeah, there'd be millions of horrible, horrible bridges EVERYWHERE.
That's a fantastic and well made point. It's akin to the cost of communications dropping over time. When moving words around the world was expensive people tended to stick to the important stuff, but now that the cost has essentially dropped to 0 we are drowning in irrelevant information.
> If it were possible to make software better, faster, cheaper by just imposing some discipline, why haven't dozens of companies done so and taken over the world?
Because the it likely is more than just 'some discipline' and because the market forces are working against you, after all nobody even expects software to be reliable so your competitor going to market with unreliable junk will eat your lunch if you slow down long enough to get it right, assuming you know what to build in the first place.
> assuming you know what to build in the first place
This is the heart of the problem. Nobody knows exactly what to build. Most software development is half initial coding, half bug fixing, and 90% requirements discovery.
Compiler writers actually have it pretty easy once the language is defined, which is a real honest to god spec. Comparing how long it takes (and how much it costs) to write a compiler once the spec is done would be a pretty fair comparison to how long it takes to build a bridge once the design is finalized.
> Compiler writers actually have it pretty easy once the language is defined, which is a real honest to god spec.
Compilers are typically developed in-parallel with the spec, exactly because you don't know what you want to spec before you try it out.
Optimizers have it even worse - they do not have much of a spec beyond "make it fast, quickly", so all development is trying to find interesting places in existing code.
NASA is just the only people doing the full accounting of all costs. The rest are like a cook who drops a food item on the floor, says "five second rule" and hopes for the best.
"NASA does that regularly. They're seemingly the only people who can afford it."
Not by far. Actually, the woman who co-invented software engineering in their Apollo program made one for achieving similar reliability if your specs are right at around $10,000 a seat. That and Cleanroom were in production use in the 1980's making low-defect software. Many others showed up afterward with plenty of application to commercial products or significant OSS software. Here's a few.
An early one, Cleanroom, that was often as cheap as normal development due to reduced debugging:
Margaret Hamilton of Apollo started a company later to make the one below to embody the principles they used for correctness on Apollo. The papers section is also interesting.
Altran-Praxis does formal specs, refinement, and provably-correct (wrt specs) code with 50% premium over normal development for their high-assurance stuff.
> If this were software we'd be looking at a multi-year software project with a few hundred programmers delivered on-time, within the budget and working flawlessly on the day of delivery.
> I have yet to see such a project
Then you haven't worked on safety critical systems or old school embedded/firmware projects.
The alternative is 30 developers solving the same problem with software that has a bunch of critical bugs that get fixed in the first few months of release and a few hundred more minor flaws that get fixed gradually over time.
When it comes down to it the alternative is almost always preferred by the market and for good reason.
I've seen several of those kinds of projects. I have even seen it done with lightweight process. But ( and there's always a but ) you won't do it with fresh grads pulling all nighters. You might do it with a handful of the remaining silverbacks ( who are not just crispy-fried ) left to do everything that needs done.
It really does take your entire life to learn this craft. Now try selling that today.
"f this were software we'd be looking at a multi-year software project with a few hundred programmers delivered on-time, within the budget and working flawlessly on the day of delivery. I have yet to see such a project."
I agree with a lot of what you're saying in this thread except that you keep missing high-assurance engineering in statements like this. Altran-Praxis regularly does what you describe minus "several hundred developers" since they try to keep the systems simple enough to not need that. Galois can do this. Cleanroom Software Engineering teams did this often on the first try. There's companies doing business requirements in Prolog with standardized components for plumbing. The DO-178B/C and similar companies are delivering all kinds of software that's tested from specs to code to whether object code really matches. Hamilton and Kesterel generate some systems straight from logical specs with correct-by-construction techniques while others in CompSci and industry do that by hand. iMatix had their DSL's and generators to do a significant chunk of this without formal methods. One company even specialized in high-availability conversions and migrations like you describe in the bridge example albeit I can't remember the name. Quite a few Ada projects also happened in defense sector with a bunch of subcontracted components that integrated painlessly due to good specs and language's features.
There are companies and groups straight-up engineering software that has few to no defects in production or maintenance activities. They actually have a significant number of customers, too. It's just that 99% of software isn't done that way. It has the problems you mention elsewhere in this thread. Let's be fair and give credit to those actually pulling it off, though. Also lends credibility to our claim more of that 99% could be as well.
> I agree with a lot of what you're saying in this thread except that you keep missing high-assurance engineering in statements like this.
> It's just that 99% of software isn't done that way.
I'm aware of it. It's just that in my practice I do not run into companies that actually do this. The companies I look at typically exist between 6 months and 5 years, have a team with an average age of 25 to 30, maybe one or two older people with some in depth experience.
They will happily tell me that they write junk because they don't have time to do it right. Personally I think they don't have the time to do it wrong but what do I know.
Frustrating.
I've worked on re-working a fairly large project from a giant hairball to something a lot more solid over the course of two years and spent the larger amount of that time arguing about bad practices, the lessons learned were legion (for me at least) about why most software is crap.
If regular engineering were done this way everybody would be self-taught, would have about 30% of the picture, would not be willing to begin to take responsibility for their product and the majority of engineering projects would have fatal flaws in them.
We really can and really should do better than this if we are to take the responsibility that has been given to us collectively serious.
There is no iterating in civil engineering, it is built right the first time. They made a plan to build a replacement railway bridge over a highway and install it with a short interruption in rail and highway use and executed that plan. I think that is an impressive feat of engineering as well as management.
There's no iterating a bridge already built but the maintenance, inspection, and thinking around making difficult repair-or-replace decisions continues to evolve in feedback with analytical and management software.
That doesn't mean they build it twice, it reflects updated information based on materials availability or changing requirements or conditions being different from initial assumptions. Exactly the kind of problems that software people tend to claim as their own personal and unique kind of challenge. But all engineering efforts are subject to those kind of challenges.
Or simply incorrect design. Like putting electrical panels so close to the wall that the cables can't physically bend to reach the inlet.
Or incorrect construction, like driving a pile in the wrong place and just adding the extra to the design.
I definitely agree. Things don't always work out as planned in any discipline of engineering. My personal experience was mechanical and electrical manufacturing, and it held true there too.
I work for a CE-facing ERP company, and our clients are PEs mostly working for state DOTs. They are actually advancing the state of the art on cost control, roadway safety, etc. using analytical decision-steering systems. It would be a mistake to overlook the value of what's being done just to maintain the status-quo against a pretty dynamic business landscape, much less to make progress. As a software/data nerd, I am suitably impressed by what I see as a vendor-to-insiders.
Sorry for the late reply -- no, Watson is well ahead of what I'm working with. Like, a generation or two ahead.
I think it's helpful to mention that many organizations don't even have the best of what the 1990s could offer; they are still struggling with custom integration of 5+ "system" suites, and the technical baggage of just keeping that working so people get paid and inventory management can happen. They aspire to use fancier algorithms on data they don't yet have with good quality, to provide faster/better/cheaper service to their stakeholders.
The state of the art for the agencies I serve is what I would casually describe to a HN audience as a data pipeline that often ends in an Oracle database, then a handful of web/mobile apps that should be rebuilt with Google Maps. Not rocket surgery, but they're truly in a tight spot in terms of budget to swap out systems already in play with better ones that face the future rather than the past.
Phew, I didn't know I had that much to say on the topic.
It isn't like people don't wonder why it takes so long or costs so much to, say, build a road, either. It seems like everybody massively underestimates how long it should take to do something that they don't know how to do and won't be doing. I characterize this mindset as "I need _x_ to be true, therefore _x_ must be true." It's endemic in all of the people who don't actually produce anything.
It's unusual to actually be able to reuse a lot of software. But this is another argument for "the only difference between product A and product B is the configuration."
Then it's "What??? We're paying <x> dollars a seat for a configuration change????." You can't win...
Sure, and evolution would be much more efficient if every mutation were positive and the species adapted that specific one instead of going out on their own creating meaningless mutations.
Who creates the best/bulletproof solutions? You're arguing that we collectively should know which one is the best, among all our different opinions and habits.
I'll instead argue that we move forward through natural selection and that everyone learns from trying, failing, trying, succeeding and learning what the best solutions are by experience.
I'm not saying it's theoretically optimal, or even practically, but I would suggest it's only natural that we've landed here.
That said, I'm all for trying to improve, if you or someone else every comes up with a better route.
Evolution is nothing like engineering. Evolution by its very nature makes forward and backwards movements relative to what an outside observer would consider to be an optimum, and selection pressure is what eventually gives rise to a perceived movement in the 'right' direction.
Software is - in principle - an engineering domain, but we tend to be much more liberal in applying engineering norms to software production schedules and reliability. This need not be the case.
If on the other hand you wish to argue that software is produced in a random fashion and selection pressure is what decides what survives then I rest my case, that view definitely does explain a lot of what I'm seeing.
Sure, your points on their differences are correct, I agree with that. But I still think my comparison holds.
Basically the comparison was made to convery Sturgeon's Law; that 90% of everything made is crap.
In that sense it is like evolution: A numbers game. While not explicitly random, distributing risk among groups going in different direction could be an efficient way forward, when counting for what would be lost with some central governance. You then select the optimal direction by results.
90% of all bridges and buildings, powerstations, cranes and heavy machines are not crap. Engineering is a responsible job, it's nothing at all like making clay vases or plates where if you throw away 9 out of 10 of the things you make isn't going to cause anybody to suffer other than yourself.
What if they are crap, but just by a metric that isn't "falls apart immediately"?
I watched my state government build an overpass that wasn't needed and didn't even have an _exit_ for 3 years. It required multiple road closures and for several months made traffic awful and my drive unsafe. I call that "crap".
I'm sure that there are organizations that will mess up if you give them enough rope. But that says nothing about the overpass itself and 'doesn't fall apart immediately' is not a standard that any civil engineer will want to be associated with, at least, not in the developed world and likely not in the third world either (but there due to resource constraints and corruption there may be a difference between what should have been done and what was actually done).
Sure, but that's because of safety necessity, not because of optimal solution. If building bridges, powerstations, cranes, etc etc were essentially free outside of drawing/planning them, and could be deployed outside of "production" infrastructure, I'm sure that industry would be lightyears ahead of where it is.
Software is rapidly becoming just as critical, and at some point may be more critical.
The ability to copy a product is a thing that works to your advantage after you've created it, the fact that each bridge and each building is engineered with slowly changing techniques and standards is what makes engineering a solid profession. I think that we probably have had too much change in too short a time thrown at us in the software related professions, if our hardware and other engineered products would perform at the same reliability level and with the same degree of resource consumption that our software routinely gets away with - not even looking at the risks associated with deploying crappy software - we would have returned the product to the manufacturer.
But somehow we've collectively managed to convince our customers that this is the best we can do and that there is no honor in going slower but safer. This is all fine until software becomes critical to our survival, and we're definitely passing some threshold in that respect and as an industry I don't think we are ready to accept that responsibility without making some major changes in how we go about our daily work.
Closed source often has the edge of 'focus' because it's working on a very specific type of 'canal'. It doesn't need to handle all types of boat.
We used to have very well engineered software - bespoke for each customer.
Then businessmen came along and said "Hey - we could save time (money) if we re-used existing things".
Eventually businesses didn't have anyone who understood the things they were re-using, which were often designed for a slightly different purpose, and things started going wrong.
There is no correct answer, other than do you want speed or quality (I leave the cost aspect out, as some things cannot be done faster or better irrespective of the money thrown at them).
> Except that in software 1000's of groups have already dug 1000's of canals and yet the next group that will build a canal will insist on doing it their way.
Because the topography you're digging through is always different, and sometimes they want a Starbucks every two miles along the canal.
The buyer of software has active disincentives - some of those to the level of national security - to not participate in some collective action to create a library of software for everyone to use.
And at some point, you learn to make the software critically dependent not on lines of code doing their thing, but rather to push all the complexity out to the configuration. So now you have man-hours and company profits depending on maintaining a configuration. That's even more ephemeral than code, so it gets even worse.
Emotionally, I agree with this point. I want to make reliable things:
> we don't need 500 crappy, slightly different ways of doing the same thing, we need maybe 5, battle tested and hardened bullet proof solutions that are well engineered.
As much as I'd like to do that, I think we're some ways off from the sorts of stability that allow for that. Sure, we're all neophiles, so there's a fair bit of people using new tools for the fun of it. But I think a much bigger problem is the extent to which our raw materials keep changing under us.
For example, the smartphone isn't even 10 years old. We're all still replacing them every couple of years because the new ones keep getting better. Processing power, memory, power characteristics, sensors, network, ports: they all keep changing. The number of processors in my house is easily 5x what it was 10 years ago. The range of capabilities is larger, too: my phone is way smarter, but my lightbulbs are quite dumb.
Even if that were stable, our conceptions of computing are still changing. Most of the code we write is in languages that are 20 years old, but we've learned a lot since those languages were created. We talk about "virtual servers", which as a mental model is much like "horseless carriage" or "radio with pictures": it's a sign that our understanding hasn't caught up with reality.
We also have an enormous amount of business churn. A ten-year-old tech company seems old. Venture capitalists invested $58 billion last year, mostly in service of disrupting some existing order. Few will see a point in investing for the long term when they aren't sure if there will be one.
Even given all that, I think we underinvest in the long term, for reasons I'm sure we'd agree on. But I am often forced to admit that the level of craftsmanship I personally want is at odds with the current practical reality of software.
And I'm not alone. Back in 1992, Steve Wozniak was hoping for the end of Moore's Law. Bob Cringely writes: "But while the rest of the computing world waits worriedly for that moment when the lines etched on silicon wafers get so thin that they are equal to the wavelength of the light that traces them—the technical dead end for photolithography—Steve Wozniak looks forward to it. 'I can’t wait,' he said, 'because that’s when software tools can finally start to mature.'" [1]
The rise of mobile and cloud computing ruined that plan, of course. But perhaps just about the time you and I retire, the technological base will be stable enough for people to do some serious, long-term building.
This is a bit of a tangent, but in case anyone was wondering why Wozniak's prediction was incorrect, it turns out that lithography could be used for features well below the wavelength of light. In fact, we're still using 193nm light (introduced in the early 2000s) to print 14nm(!) features. Human ingenuity is a powerful thing :)
One can spend a lifetime trying to build the perfect canal that works for all boats and spans the longest distance over the most varied terrain.
But, if one only has one boat to get through, and the distance is short enough, many people will just place a couple sticks of dynamite and be done with it. The most important thing is that the boat gets to port, not the canal.
But, once in a while someone will notice all of the holes and try to build a more permanent canal. They'll save a lot of people a lot of time and may even make some money on it.
Sure, we could collect lessons and pass them on to the next generation. But as software developers, we can do better than that. We can write libraries that the next generation will reuse. That's why software development, which "takes so long" according to the OP, still goes much faster (in terms of economic growth) than your beloved civil engineering. The ease of making new stuff without studying too much existing stuff, which you complain about, is the whole reason why software is awesome and eats the world.
> We can write libraries that the next generation will reuse.
We could, but unfortunately we definitely do not do this as much as we could.
> hat's why software development, which "takes so long" according to the OP, still manages to go much faster (in terms of economic growth) than your beloved civil engineering :-)
If you took away the roads society would collapse, instantly. It is getting to the point where if you take away the internet (or even just a substantial fraction of it) for more than a few days that quite possibly the same will happen. That comes with a degree of responsibility that I do not see reflected in the quality of the product of our industry (including quite a few of those libraries).
There are exceptions to this but not many.
Economic growth is great, if we can keep that afloat in the long term. Given the stakes and the degree to which even the largest entities are failing to take responsibility for their products and services that growth might be the precursor to a very harsh lesson somewhere in our near future.
For every crash, data breach, security issue, hack you have to look back and wonder whether the speed of delivery turned out to be worth the risk (and then you have to discount that even further to take into account that what you read about is only a very small fraction of what actually goes wrong...).
> For every crash, data breach, security issue, hack you have to look back and wonder whether the speed of delivery turned out to be worth the risk (and then you have to discount that even further to take into account that what you read about is only a very small fraction of what actually goes wrong...).
Those risks are pure externalities, unfortunately. The answer to the question for the management of pretty much any company is a resounding "yes, it was worth the risk" - they earned truckloads of money over the years before the breach, and by the time shit hits the fan, the management team probably changed twice already.
Nobody cares, because nobody has to - business incentives are actually strongly aligned against caring.
It sounds like you want to hold software companies liable when their products get hacked. Is that really how other industries work? If a terrorist blows up a bridge, should the bridge builder be sued?
> It sounds like you want to hold software companies liable when their products get hacked.
If the hack is directly related to the quality of the product then yes, by all means. And they could (try to) take out some kind of professional insurance against this.
> If a terrorist blows up a bridge, should the bridge builder be sued?
No, but if a manufacturer of a vault leaves a backdoor in their vault then they should be liable (and they most likely are).
Now this is where the analogy breaks down somewhat, in the 'real' world the lock manufacturer is not liable for the damage due to a break-in, but the presence of a high quality lock will reduce your insurance premiums (at least, they do where I live).
So that's how shop owners deal with this, they take out insurance and the insurance company will try to make a stab at how big the risk is that you're going to be the subject of unwanted attention and price their premium accordingly. Any measures you take to make sure that you are not going to burglarized will be taken into account.
Contrast that with a terrorist blowing up your house, the chances are spectacularly small (vanishingly small even) so besides that not being an interesting risk to insure against you likely will not be worried about it either.
On the other hand if your bridge builder will attempt to sell you an explosion resistant bridge then it had better be that (in practice this will simply depend on the size of the explosion and no bridge manufacturer will say that that is acceptable use of their bridge and likely if you sued them the judge would side with them unless they made specific claims about such suitability).
>the next group that will build a canal will insist on doing it their way.
If only every business was identical! Then we wouldn't have to deal with the problem of creating custom software for each of them.
In this canal-across-the-country analogy: imagine that every boat is a different size, different shape, different propulsion method, and is made of different materials. And some of them are actually trucks, airplanes, and vacuum tunnels.
>Then just build the biggest canal that satisfies every requirement!
> Except that in software 1000's of groups have already dug 1000's of canals and yet the next group that will build a canal will insist on doing it their way.
This is why a prudent developer/team would attempt to leverage frameworks/plugins/existing API's and libraries vs reinventing the wheel. Leveraging well-vetted and popular resources should cut development time considerably.
> This is why a prudent developer/team would attempt to leverage frameworks/plugins/existing API's and libraries vs reinventing the wheel.
The problem here is that those frameworks/plugins/existing API's are all moving targets, their life-span is very likely substantially shorter than the life-span of your project.
Well vetted and popular unfortunately does not equal 'will have staying power'.
That hasnt been my experience. Most of the frameworks I use last much longer than my tenure at a particular position. Are you saying you would really write your own django? jquery? react? chef? git? I would argue the reason some startups can now move blazingly fast with relatively few developers is by leveraging open-source in a smart way.
> Are you saying you would really write your own django? jquery? react? chef? git?
No, I think it should be fairly obvious that that would not be my choice, rather the opposite.
But why django? Why not rails? Or symphony? Or Yii? Or Spring? and so on, why git? and not subversion, or tfs or mercurial? and so on. For every one of those choices there are 10's of possible choices and none of those will be something akin to an industry standard. And so we muddle on. Well, at least git seems to become slowly the standard in revision control, but because git was yet another fresh start project a lot of the lessons learned from other revision control systems that were not readily apparent to the git author(s) had to be re-learned the hard way, resulting in a lot of delay and frustration (and to this date the git command set strikes me as ill thought out).
Leveraging open source in a smart way is exactly the right thing to do, now if only there would be some kind of mental penalty to start a new project when an alternative is already available which could use some TLC.
This is true for the lifespan of that framework. No software anywhere has the devoted love of its adherents that Borland's Delphi holds. So where it it now?
And I have literally replaced piles of "well-vetted and popular resources" with better-vetted and less popular resources in matters of weeks - after all, the knife-fighting over features was done, and all that was wrong was that the framework had some massive hole.
Software craftsmanship isn't something you learn by ignoring the state of the art either.
And as for digging canals, the civil engineering profession is lightyears ahead of the software people because there are lives on the line and they do have a way to pass knowledge on in a way that lessons stay learned. (Most of the time, anyway, forget about the dark ages for a moment please.)
A problem: what actually is the state of the art in our industry? It's a serious question - the more I learn, the more difficult it is to indentify it.
UNIX? You mean that pile of crap that replaced much better and saner systems, so that many decades later we still have the same stupid problems they solved in the 70s?
x86, which is basically crap?
Enterprise Java, which all Big Players use, that is a pile of bloat wasting computing resources, fueled by countless armies of code monkeys typing it dumb code that starts to work if there's enough of it, much like uranium gets dangerous if you put enough of it in one place?
Modern web development, with bullshit hipster fads, even more bloat than Enterprise Java, where half-life time of any library or framework is counted in months, if not weeks? Where people who have no understanding of what they're doing invent dumb solutions than then become de-facto standards (see e.g. template languages)?
The Lisp folks who rant about good old times and develop some software of various quality, but nobody even notices so you won't get to apply any of that in your job?
I think, you somewhat answered your own question, albeit indirectly and ex negativo. Widely ignoring what we already know or could have learnt, and pushing the next vanity-boost feature seems more attractive than learning from our experiences and drawing the consequences. And the people doing it always find rosy language that makes it seem like a heroic feat of progress, and an audience that falls for the BS.
Except if there was a method that actually provably worked in producing lower cost, more reliable software on schedule without requiring your entire staff to be composed of demigods, then it would have already been adopted by EVERYONE.
There is no such thing as practical state of the art in our field for the problem being discussed (which is the software requirements capture/design/engineering side of things, not the software construction side of things), most of the so called "state of the art" focuses on a problem of very limited utility:
problem a) if I have a complete, consistent and fixed requirements, can you write code that provably implements it it? Sure. But very little software is developed under those conditions (avionics, safety critical stuff, some crypto stuff, etc)
problem b) code/methodologies to make writing easier/more concise/more predictably once as the specification is discovered. Nice, but it is optimizing the 10% of the task, whereas the 90%, the requirements discovery and requirements consistency management between requirements discovered amongst different branches of the problem is where the bulk of the time is spent.
Those are the "assume spherical cow" of our space. Interesting, but limited.
Or going with the bridge analogy that seems to be popular here, you're asked to build a bridge. Nobody tells you over what, what load it has to carry, under what weather conditions. So you don't know whether they want a rope bridge over a tiny stream or a multilane car/train combined suspension bridge. And as you ask for the requirements it is now a bridge over the Atlantic with a stop in Australia. And when you query the Australia part they confirm and casually mention that they might be planning on a stop in Pluto too and can you fit that in the schedule.
In my current project we have a manager on customer side querying about how we can fit various celestial bodies in the existing solution and discussing paint colours, while my usual contact keeps reminding them we really need to drive that truck to Australia ASAP...
Anyway, you're absolutely right about "state of the art" in requirements capture / design / engineering, and this is the larger context of discussion. But I admit, my original post was an assertion that there's no sensible, practical "state of the art" on the construction side either - it's mostly either fads or working with lowest-common-denominator tools (basic Java). The situation seems to look better in embedded in particular, but that's either because you're really, really limited in tools there, or because I have very little experience there and only think it makes sense...
It likely helps that physics puts a hard constraint on things. Over the last decade or two, the physics of computing (aka the hardware) have been changing just as much as the software.
Maybe there is a reason why we seem to see the most impressive code work on "constrained" devices like the C64.
Yes, I suspect this is the case, Moore's law gave us an extremely easy 'out' of many problems that we refused to look into the eye and hopefully now that that has more or less run its course we will finally be able to re-focus on learning our craft properly because there are no free lunches to be had any more.
> the civil engineering profession is lightyears ahead of the software people because there are lives on the line
This is an often repeated and completely false assertion.
Just think about the number of deaths every year due to bad road and highway design - level rail crossings, highway exits and entries from the left (in North America).
The idea that civil engineering is any better than software is just nonsense.
Oh, and don't forget about the civil engineers at Fukushima who put the backup power systems in the same area as the reactors, guaranteeing that they would also be destroyed in any serious disaster.
Civil engineering is a compromise between many factors and those 'bad' roads and highways are likely the best that was possible for a given situation and the budget allotted. The point is not that things are not perfectly safe, the point is that given the constraints and the known state of the art they likely could not have been (much) better.
And civil engineering is just one branch of engineering, there are many and all of them have to work with the same balance between available resources, time and other constraints and they do substantially better than your average software project.
A bridge collapsing is headline news, a computer program crashing is so normal that you would probably not even mention it to another person if it happened to you.
> And civil engineering is just one branch of engineering, there are many and all of them have to work with the same balance between available resources, time and other constraints and they do substantially better than your average software project.
That's the main point that I would like to refute.
Given the regulatory barriers, enormous costs, and long planning timelines for most civil engineering projects, isn't it astonishing that bad designs impacting human lives are still being implemented.
If the process of civil engineering was so well understood, so carefully documented and supervised, and so rigorously taught to new engineers, why are many hundreds of people killed every year?
The uncomfortable answer is that the civil engineering process is very far from well understood - just like software.
> Given the regulatory barriers, enormous costs, and long planning timelines for most civil engineering projects, isn't it astonishing that bad designs impacting human lives are still being implemented.
Well, depending on context, country and corruption: those are the exceptions, not the rule and the engineers typically did their work as well as was possible given the constraints. They know what they know, and more importantly, they know what they do not know and they will engineer in safety factors.
Buildings and bridges collapsing, machinery exploding: those are the exceptions, not the rules.
As a rule, highways function, as a rule, bridges withstand their design loads and excess of those loads and so on.
As a rule: software is buggy, frequently crashes, hogs memory, is slow and has inconsistent user interfaces, updates will randomly break stuff and it is insecure to boot.
If you feel that software is on par with the rest of the engineering disciplines then I probably won't be able to convince you that it isn't.
But whoever designed this bridge and the foundations did a pretty good job of it:
It looks like the bridge designers defeated the the bridge destroyers - in that case at least.
I DO feel that software engineering is on par with other engineering disciplines - if writing software can be described as "engineering".
The important difference with software is that "the code is the design". The code is not the product.
The manufacturing, building and deployment steps in software are actually quite well understood, and has been mastered by most organizations and individuals.
> The manufacturing, building and deployment steps in software are actually quite well understood, and has been mastered by most organizations and individuals.
If we substitute 'some' for 'most' then we're in agreement, unfortunately my experience to date does not give me the confidence required to subscribe to your version, but that could easily be local variation.
That seems like a really unfair comparison. I'd argue that the software industry has evolved magnitudes more in the last 20 years than what you call civil engineering has evolved in the last 100. Sure, the latter has existed much much longer, but it's by no means evolving very quickly. Software development has traded safety for rapid evolution in areas where possible. This could be argued for or against, but I'd rather have a multiple generations more mature software industry at a point I'd need to develop "safe" software, than a safely evolved industry several generations behind.
> I'd rather have a multiple generations more mature software industry at a point I'd need to develop "safe" software, than a safely evolved industry several generations behind.
Yes, that's exactly the problem. So now we have an unsafe industry that is producing a terrible that powers a very large chunk of the worlds commerce. It's a house built on quicksand and our hope seems to lie in hoping that we can move to another house before this one collapses.
The areas in which this is most visible: security, reliability, maintainability, documentation and testing, and finally a complete lack of warranty for suitability from the various manufacturers/service providers.
Software is 'eating the world', but is it strong enough to support the world in the longer term if we continue down the road that we are on? I'm not bullish on that.
Let me start off with saying I completely agree with your points of the downsides of this.
It is however extremely hard to imagine the world that would be, if we were to take a different route. What would be the effects of slower improvements. I assume (since I sometimes do) many people look at the software industry as narcissistic and self-agrandizing when "delivering expriences" and "solving global problems with scalable midware". But what third party industries would be held back if this one moved much slower? Could there be loss of medicinal advancements, monetary, safety, third world advancements?
But as you say, I'm also very hesitant on the stability if we can't find some middleground between the two.
To borrow a line from Larry Page's book: more wood behind fewer arrows. That would already work wonders, so instead of having an endless repeat and rehash of the same concepts in disposable form it would likely be better (and possibly even faster, so no effective slowdown!) to do things a bit better, to try to merge more often rather than to fork and re-start all over.
I think the feeling of fresh and new development (before complexity sets in) is so compelling that it tends to drive us away from actual progress. After all, it is so much easier to launch yet another half-baked language, frame work or product than it is to pick up something existing and to really improve it or to update it in a way that it will last much longer. That's relatively thankless and anonymous work compared to slapping your handle on a new framework.
This is part of what makes good software hard: good software isn't sexy (think: erlang verus node.js, as just an example, I've tried very hard to keep this discussion brand and tech free but I feel that an example may help to illustrate what I'm getting at).
For reliability, I think the Jepsen approach of an expert stress tests a system and reports on where it fails is a good approach. I see some "big data" vendors actually pay him now to analyze their software, then fix the bugs he exposes.
Security bug bounties are also an important advance in software engineering process.
I also think there is a growing interest in these issues outside the industry. For example, we are likely to have as our next President someone all too familiar of the risks of poorly secured email systems. Maybe this will be the impetus for a more serious focus on security, at least.
Bug bounties are not such a hot idea in general. There is the issue of entitlement on the white hat, disputes about severity levels, potential for blackmail, and the two engineers that are clearing the false positives. Better to put them in the pen test team.
software industry has evolved magnitudes more in the last 20 years than what you call civil engineering has evolved in the last 100
Civil engineering has existed for more than 3,000 years; the romans were building cross-continental roads 2,000 years ago. The Chinese were building cross-continental defense structures 2,500 years ago.
People have tried to build software like Civil Engineers build bridges. It becomes frighteningly complex and involved to make a stop light controller, and you end up wanting to throw out functionality from your hardware because it makes things complicated or impossible.
I mean a lot of the problem is we generally spend most of our time thirty abstractions away from what is actually happening, and often times those abstractions leak. For goodness sakes few of us are even protected from cosmic rays changing bits in our ram, which happens fairly frequently.
What about software in medical devices, or that touch medical data? How about software in control systems of vehicles, industrial machinery, robots, etc... Perhaps your definition of software is too limited.
If our profession would only be able to simply collect lessons learned and to pass those on to the next generation then we'd be moving faster on average and we'd produce better software. we don't need 500 crappy, slightly different ways of doing the same thing, we need maybe 5, battle tested and hardened bullet proof solutions that are well engineered. Fragmentation is going to be open source's death at some point if this continues, that's one area where closed source actually has an edge: focus.
In part the problem is that software producers have managed to convince the buyers of their goods and services that they are never ever liable for their product (something no other industry has managed to do), in part it is because it seems superficially easy to re-invent until you reach the same level of complexity (which inevitably happens) as what those 'archaic' solutions were already addressing.
I don't have any answers on how to solve this, unfortunately, but there are software eco-systems that really get this right and others that seem to be totally lost in ever expanding cycles of endless rewrites.