[jancsika]

> "The notion that software engineers are not responsible for things that go wrong will be put to rest for good, and we will have to work out how to develop and maintain code that will go on working dependably for decades in environments that change and evolve."

That sounds like a really hard problem to solve. Not only would you need to have an audit trail for the history of changes to the code, you'd also have to figure out a way for third parties to audit the code and make sure they're looking at the same data that is being released by the project.

Additionally, reacting to arbitrary changes in the environment probably requires more resources than even a multinational corporation can provide. So you'd need a way for third parties to be able to make their own changes to the software, somehow add them to the codebase without creating too much administrative overhead for the core team, and audit those changes in an automated fashion so that they don't create thousands of new exploits.

And how would you even manage the sum total of all these Frankenstein versions of the original software with the changed versions? How would all these geographically disparate groups of programmers even communicate?

We obviously need funding for a lot more CS professors to come up with solutions to these issues.

[transpute]

The Anderson article mentions research into extended maintenance practices:

"As we build more complex artifacts, which last longer and are more safety critical, the long-term maintenance cost may become the limiting factor. Two things follow. First, software sustainability will be a big research challenge for computer scientists. Second, it will also be a major business opportunity for firms who can cut the cost. On the technical side, at present it is hard to patch even five-year-old software. The toolchain usually will not compile on a modern platform, leaving options such as keeping the original development environment of computers and test rigs, but not connecting it to the Internet. Could we develop on virtual platforms that would support multiple versions?"

ELC 2016: Approaches to Ultra-Long Software Maintenance: https://elinux.org/images/f/fb/Approaches_to_Ultra-Long_Soft...

ELC 2017: Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years: https://www.linux.com/news/event/ELCE/2017/long-term-embedde...

[titzer]

Thanks for those links. Even with those recommendations, I think we honestly have no idea how to maintain software systems for 20+ years. Shame, because almost every other kind of industrial system we produced up until about 30 years ago _did_ in fact have the ability to be maintained for decades. Look at the B52 (https://en.wikipedia.org/wiki/Boeing_B-52_Stratofortress). Still going strong 60+ years after its first flight. Designed to last. Individual ones were built to last. Sure, it's seen upgrades over the years, but the core was just so well thought out and so _simple_.

We might never be able to build systems like that again. Simple is key, and we just can't help ourselves.

[detaro]

What mainframe systems do sounds pretty close the quote. They can still run decades-old software, even if the hardware platform underneath now looks completely different, since they can emulate everything from the old system, or have newer interpreters for the same old languages.

[ben_w]

> That sounds like a really hard problem to solve.

Yes, but we still have to solve it… or, at the very least, make a good effort to improve the situation.

Biology and chemistry already have systems around them to help limit any damage from, for example, smallpox research or mishandling chlorine triflouride, and they manage this without needing everyone to wear safety goggles when mixing yeast and water.