Residuality Theory: A Rebellious Take on Building Systems That Actually Survive
Posted by HealthyInstance9182@reddit | programming | View on Reddit | 3 comments
Ok_Issue_6675@reddit
It is a great post. Makes lots of sense on how to build a real business, at least two payment system are a must - I need to change this on my end:). And we forget that business and tech should be aligned to really achieve the same goal.
aidan_morgan@reddit
This seems like a fairly well understood concept from other fields of engineering - Failure Modes and Effects Analysis (FMEA).
edgmnt_net@reddit
I like the idea of a deep connection between IT and business. However, I'm not sure the other stuff you're proposing is viable for run-of-the-mill stuff, although it does seem viable for high impact stuff (which isn't what people usually work on).
Run-of-the-mill projects tend to run on a bunch of features which have very low impact on their own and, with some exceptional cases, are probably useless on their own. Unless you're building sonething like a common platform + apps where you can still play Solitaire even if Minesweeper goes down, things are still highly interconnected. So I think it's usually far more valuable to push for outlandish external resilience instead of trying to make the individual components resilient to outages on their own.
For example, it would be far more valuable to choose PostgreSQL for a database in spite of Oracle or Microsoft or whatever promising lower TCOs somehow because that couples you less to a single vendor. And at that point you can go full in on PostgreSQL and not even consider database portability (which tends to be tricky on its own). This may also result in a decrease in code complexity, which makes your code more internally-resilient.
Yes, if reasonable and accessible, go ahead design for graceful failure. But don't go out of your way to make things independent when they cannot be so morally, because even if there is some benefit costs will skyrocket. There is little point (although it might be nice to see general pricing) in taking orders if they can't be paid, to follow one of your examples. At least not if you have to jump through hoops to make it do anything sensible. I'd rather write tight code and cover all "normal" corner cases (might seem like an oxymoron but it isn't once you consider that some things like memory management or availability of direct function calls is usually taken for granted), without introducing extra possible failure modes.