I like the paper idea - that paper and ink becomes an extension of our bodily selves (probably more priopeeception than some spiritual thing).
I mean I can remember and riff off a great paragraph in physical book, where the book is on the shelf, which page the writing is on, did I write next to it? But doing something like that on this iPhone - forget it, it is not "there" in any useful sense
After 20+ years in the field: main reason is unclear requirements. Software malleability is taken for granted so much that the under specification and fluidity of requirements became a norm and canonicalized in “agile”. That’s not necessarily a bad thing, it does allow for quick advancement of what is possible but high failure rate is the price we pay. Second: unlike traditional engineering, there are not too many university or college programs that take rigorous approach to building software at scale. Till today, software is a free-for-all industry. That allowed us to grow very fast, but - again - high failure rate is the price we pay. Third - lack of formal standards and by that I mean not just APIs or protocol specs but formal requirements on things like performance, fault-tolerance, lifespan etc.
Also, bugs in software are seen as a fact of life. You can't get warranty on software (at least this holds in practice for most consumers). If MacOS deletes all your files, good luck proving that it wasn't your fault, and good luck suing Apple.
So this gives programmers a carte blanche to create crap, effectively.
That's a very broad big question. Like, do they really fail more? What's the numerator and denominator? There are are tons of high-profile failures, but there are innumerable successes as well. Do you count pushing the 100 or so versions of Chrome that have been pushed out, across millions of devices as one success, or a billion? How do you count projects that don't work right at launch, but do end up working okay after a couple versions?
I once saw someone complaining because they moved into a freshly-built apartment building and things were constantly wrong. A/C not working, shower not working, every time it came down to the contractor doing something wrong.
but the apartment building was finished, the project for building it didn't fail.
In the same way, software projects don't typically fail either, they just have a million things wrong with them.
I don't think I've ever actually seen a software project outright fail, it's more that it never lived up to expectations.
> You have to keep a dozen of your favourite problems constantly present in your mind, although by and large they will lay in a dormant state. Every time you hear or read a new trick or result, test it against each of your twelve problems to see whether it helps.
Reminds me of similar patterns elsewhere. People keep "tabs" open on specific topics and add information over time.
- Mathematician Serge Lang kept correspondence and related documentation in extensive "files"
- Tony Fadell says you should keep coming back to ideas that you can't stop thinking about and add more insights over time