This reminds me of a quote from John Carmack that gnaws on the back of my brain during day to day development - "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in." Seems it would also be relevant to most of modern inventions.
Echoing another replying comment: and it's not possible for them to understand it all either.
Fun (/s) example:
- Outlook email client in the browser (Firefox in my case)... typing a new email up. Hold down backspace to delete a bunch of characters... and occasionally my browser will navigate backwards. ("smart" text suggestion lagging, causing keypresses not to be always captured by the email text input box, perhaps?) At least Outlook auto-saves drafts reliably!
- I (probably) can't be mad at the individual programmer though. I'm the oddball that has reverted the browser setting for "treat backspace as browser-back, outside of text fields". I bet that never made it into a test-case anywhere.
- I could be mad at the browsers that changed that default behavior several years ago (I feel like Chrome did it first, but could be wrong), though they did it for the valid reason of protecting the (less aware, imo) users!
- I guess I could be mad at all the websites that poorly implemented form-filling, letting users get burned by accidentally going back a page and losing their input. But I can sympathize with too many "features" and not having time to implement that edge case!
Sigh, my ideals of software quality are all doomed, aren't they?
For a long while now, I've always had a mouse button mapped to backspace. Good for browsing and for deleting. ... Upon testing, it seems I no longer do this, and forgot. Guess that button's set to "browser-back" now.
The whole point of layers and abstractions is to reduce the number of states you have to worry about. The way that people talk about abstractions like they're a bad thing makes me think they've never really stopped and thought about all the many, many good abstraction layers they use. It makes sense: a great abstraction is basically invisible, so you don't even notice it unless you pay attention. But everyone who says "too many abstractions" has clearly not stopped and paid attention. You don't need fewer abstractions, you need better abstractions.
An abstraction layer makes itself most visible when it fails. Avoiding failure requires better or less abstraction layers. In many cases I don't trust others to build correct abstraction layers, good UI libraries, reliable GPU drivers that don't corrupt memory when sleeping the system, etc. (Filesystems and virtual memory are largely reliable in the common case, though it's still common to avoid filesystems and allocations and swapping in real-time code, and schedulers cause grief when they cause media payback to stutter when I'm running compiler jobs.) Often I trust myself to work with less abstraction layers, more than I trust others to build better ones.
