If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem.
In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem.
With agentic coding, we're about to enter a new phase of plenty. If everyone is now a 10x developer then there's going to be more software written in the next few years than in the last few decades.
That massive flurry of creativity will move the industry even further from the calm, rational, constrained world of engineering disciplines.
> Bridges are partly a design problem but mainly a build problem.
I think this vastly underestimates how much of the build problem is actually a design problem.
If you want to build a bridge, the fact one already exists nearby covering a similar span is almost meaningless. Engineering is about designing things while using the minimal amount of raw resources possible (because cost of design is lower than the cost of materials). Which means that bridge in the other town is designed only within its local context. What are the properties of the ground it's built on? What local building materials exist? Where local can be as small as only a few miles, because moving vast quantities of material of long distances is really expensive. What specific traffic patterns and loadings it is built for? What time and access constraints existed when it was built?
If you just copied the design of a bridge from a different town, even one only a few miles up the road, you would more than likely end up with a design that either won't stand up in your local context, or simply can't be built. Maybe the other town had plenty of space next to the location of the bridge, making it trivial to bring in heavy equipment and use cranes to move huge pre-fabbed blocks of concrete, but your town doesn't. Or maybe the local ground conditions aren't as stable, and the other towns design has the wrong type of foundation resulting in your new bridge collapsing after a few years.
Engineering in other disciplines don't have the luxury of building for a very uniform, tightly controlled target environment where it's safe to make assumptions that common building blocks will "just work" without issue. As a result engineering is entirely a design problem, i.e. how do you design something that can actually be built? The building part is easy, there's a reason construction contractors get paid comparatively little compared to the engineers and architects that design what they're building.
Software packages are more complicated than you make them out to be. Off the top of my head:
- license restrictions, relicensing
- patches, especially to fix CVEs, that break assumptions you made in your consumption of the package
- supply chain attacks
- sunsetting
There’s no real “set it and forget it” with software reuse. For that matter, there’s no “set it and forget it” in civil engineering either, it also requires monitoring and maintenance.
I have talked to colleagues who wrote software running on microcontrollers a decade ago, that software still runs fine. So yes there is set and forget software. And it is all around us, mostly in microcontrollers. But microcontrollers far outnumber classical computers (trivially: each classical computer or phone contain many microcontrollers such as SSD controllers, power management, wifi, ethernet, cellular,... And then you can add appliances, cars etc to that).
If something in software works and isn't internet connected it really is set and forget. And far too many things are being connected needlessly these days. I don't need or want an online washing machine or car.
True, using a library in a cheap coffee maker you can maybe set it and forget it. I have an old TI-85 calculator that’s never needed to update its OS, while Apple has obsoleted multiple generations of applications in its never ending upgrade cycle.
But for mission critical applications the bar is a little higher. Isn’t this why we have the ongoing dialogue about OTA updates for Teslas etc and the pros and cons of that approach? Because if you can’t OTA patch a bug, you have to issue a recall [0]. But if you have internet connectivity, as you rightly point out, then you have a whole new attack surface to consider.
Indeed it isn't easy, but for car software, why couldn't you do the software upgrade offline, while at the mechanic, or via a USB drive with a signed installer, or via a phone app plugged into a USB port in the car? For a basic car there really isn't a need to be always online.
My car just has a bluetooth stereo, and it isn't very old. Yeah it is a basic model, but I really don't need or want connectivity in it. The one argument I could see would be showing maps, but I need offline maps anyways since I often lack any sort of mobile phone connection where I'm going. And you can update maps on a monthly basis (mobile phone app over USB while parked at home would work perfectly for this). Currently I just run OsmAnd on my phone with openstreetmap data downloaded in advance. Realtime traffic information perhaps could be an argument, but again, better to distribute that via FM radio that has better coverage (or even AM radio in some parts of US as I understand it).
And cars might be the odd one out. There really is no excuse for exposing washing machines and other applicances online. Especially since they are likely to last for a lot longer than the software will be supported. The fridge and freezer at my parents is around 20 years at this point for example. My washing machine is over 10 and going strong. I doubt they would get software security support for that long.
If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem.
In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem.
With agentic coding, we're about to enter a new phase of plenty. If everyone is now a 10x developer then there's going to be more software written in the next few years than in the last few decades.
That massive flurry of creativity will move the industry even further from the calm, rational, constrained world of engineering disciplines.