Is there academic research on software fragility?

As others point out, more detail about what you're looking for.

I found Out of the Tar Pit[1] somewhat useful. I thought the back half of the paper was disappointing (sorry, functional is not the cure to all problems, and state is something inherent and we must deal with it), but the definition of "essential complexity" and "inessential complexity" from that paper are invaluable, and too often I see people/devs/PMs going "simpler is better" where "simpler" would not address essential complexity: i.e., their simpler == broken, for the use case at hand.

But once you have that, then when you see a fragile system, you can start looking it through a more productive lens of "okay, what of this must I keep, and what complexity can I dispense with?"

[1]: https://curtclifton.net/papers/MoseleyMarks06a.pdf

I think there is a fair bit of discussion on software fragility under the rubric of "robust" software in the SE literature -- sort of the negative space of what you are looking for, but within that topic, causes of fragility are examined.

Sussman wrote an essay in 2007 called "Building Robust Systems" https://groups.csail.mit.edu/mac/users/gjs/essays/robust-sys... it's not study, admittedly, but an example of the term under which you might find what you're seeking.

Could you qualify what you mean by "fragility"?

I think the relevant academic research areas would be software resiliency, software reliability and error recovery, static and dynamic analysis, fuzzing, as well as conceptual frameworks like LANGSEC[1].

[1]: https://langsec.org/

When I look for research, I use Google Scholar (among the last places I can find it).

https://scholar.google.com/scholar?q=software+fragility

A lot of the results are about seismic simulations, but some are about software defects:

Fragility of evolving software - https://dial.uclouvain.be/downloader/downloader.php?pid=bore...

Software is not fragile - https://hal.archives-ouvertes.fr/hal-01291120/document

Overcoming Software Fragility with Interacting Feedback Loops and Reversible Phase Transitions - https://www.scienceopen.com/hosted-document?doi=10.14236/ewi...

Agile or Fragile? - The Depleting Effects of Agile Methodologies for Software Developers - https://core.ac.uk/download/pdf/301378665.pdf

You might need to reframe your terminology on what "software fragility" is referring to. If you mean looking into critical failures in systems due to vulnerabilities in third-party libraries (I'm thinking Log4JS), then the terminology currently used in security is "software supply chain" [1].

My general process is once you've found an article, like the "Backstabber's knife collection: A review of open source software supply chain attacks" from my link, read through it with a text editor open. Make notes like a summary of what they did, what they found, strengths and weaknesses, and what I like to call "the rabbit hole". If you see a reference to something you're curious about, find what the citation for that piece of information is and follow up with a reading of that article next. Repeat until you've exhausted the findings and move on to the next interesting reference.

[1] https://scholar.google.com/scholar?as_ylo=2019&q=software+su...

How software changes over time?

API versioning, API deprecation

Code bloat: https://en.wikipedia.org/wiki/Code_bloat#

"Category:Software maintenance" costs: https://en.wikipedia.org/wiki/Category:Software_maintenance

Pleasing a different audience with fewer, simpler features

Lack of acceptance tests to detect regressions

Regression testing https://en.wikipedia.org/wiki/Regression_testing :

> Regression testing (rarely, non-regression testing [1]) is re-running functional and non-functional tests to ensure that previously developed and tested software still performs as expected after a change. [2] If not, that would be called a regression.

Fragile -> Software brittleness https://en.wikipedia.org/wiki/Software_brittleness

Perhaps because I am inexperienced, I don't understand how software is much more complicated than other stuff, like electronics engineering or industrial engineering. Those are expensive to debug and have complicated interactions, yet engineers somehow can find ways to make them robust without the cost skyrocketing.

Perhaps because software is now the interface between different systems, and we are desperately trying to abstract away the underlying system yet the details are eventually somehow leaked and cause other issues? Perhaps because complexity is similar to multiplication, physical systems are limited by 3D space and softwate systems can become entangled without bound? Just some naive thoughts.

Software fragility is actually very similar to physical fragility.

Think of Jenga tower: the more blocks you have, the more fragile it is. And that is despite Jenga being nicely layered (each block has limited number of direct dependencies).

There are two main ways to decrease fragility:

1) lay out your blocks more carefully.

2) decrease the total number of blocks.

What's interesting, is that most software development practices focus on 1. How to make complex system less fragile? Use a big framework, do unit tests, use static typing, have protected branches, write documentation.

While the biggest payoffs are always in the reduction of blocks. KISS.

David Parnas coined the phrase "Software Aging" to explain why software tends to get more fragile over time. The references in the wikipedia entry on it might be a good place to start.

Well designed architecture will always be the guard against fragility. I do think there is a lack of architecture design and technical design discussions that contribute to the current state of software fragility. There's too many tools contributing to the noise, and not enough tools reducing that noise.

Software is hard because it is the last 10% ... Hardware was the first 90%, but anyone with project experience knows how long the last 10% lasts.

One bad bit can stop the show; all else follows from that, pretty much.

Even if there is redundancy in hardware to catch a bad bit, software contains a lot of inter-connected logic in which there is no mitigation for an unexpected, incorrect value.

There are chains of dependencies such that the correct behavior is a giant conjunction of prpositions: if this works, and this is correct, and this configuration is right, and, and .... then we get stable behavior with good results. Conjunctions are fragile; one incorrect proposition and the conjunction is false.

This isn't a typical academic research paper but is from a University of Chicago researcher, and I think gives a great overview of failure modes of complex systems in general (software included): https://how.complexsystems.fail .

As someone who writes a lot of complex/evolving data analysis software that needs to work correctly, I find some of the considerations listed in the above to be immensely helpful.

It’s not academic research, but I recommend Marianne Bellotti's "Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)" about modernization of legacy software systems and managing the teams maintaining these systems. The author worked at the United States Digital Service.

https://nostarch.com/kill-it-fire

Here’s an empirical example. I followed a step by step tutorial on how to setup a server with Apache + Linux + SSL.

The backbone of the internet.

It’s still not working , and it’s been two days.

Software is cobbled together with ducktape and cowchips.

After 10 years in the field. My take is:

We’ve lied to ourselves so much that we believe our own lies

I'm doing research on this right now actually.