Deity, do I agree with this. While I've recently retired, I cannot count the number of time (I was a consultant in IT Service Management), I had written in run books, contracts, and training materials that you *MUST* test that your restores do bring the system back to a known state. Then you set the backup intervals to what you think you can afford to lose (e.g. I only add about one user to the X system a day, I can afford to re-add them after a restore).
The number of times I received calls that the restore failed and the system would not come back up are almost countless. It's a well recognized issue; "if you can't restore, backups are worthless".

While I concur for small applications (where I've seen three different sources for a 12 field reply), there is the issue of huge and complex applications that need a large number of data sources. I.e. (simple example), airline reservation that has to reach out to flights, seat availability, honors programs, passenger rating, credit card info, do they have any medical conditions (need oxygen, have a service animal rating on file), TSA clearance, Etc.

All of these data sources have their own security needs, upgrade/schema changes, report views, Etc. It's almost (never impossible, but not recommended), to consolidate all that data in one place (i.e. constant replication), in a single data source a "small app" can draw from.

Application design should take into account where data resides (12 different databases where 3 hold HIPPA data, Etc.), and design how to access and present the data in a manner that meets the consumers needs and allows the business to manage the operational needs behind it (i.e. I want to upgrade the database version and change the schema, so I'm going to create a new source, designate a new API and my front end team can continue to use the old API until they want to use the new and point to the new source with additional fields or views.

Also, I want to allow for graceful failure; so the seat map is not available (source down), the user can still see the flights, see the prices, book the ticket and either have a seat assigned when it comes back online, and then go end and move it to something better if they wish.

So, not arguing that a lot of applications are over decentralized, but it's not always better to make all apps monolithic.

If I misunderstood your point, I apologize

My first was a Heath H89 built as part of their electronics training program. I beat the heck of of her with upgrades and writing software and playing games until I could afford a pre-built Micron X86 computer

I've seen many comments here, many of which I concur with. However, working in the development consulting world for 40+ years, here's my two cents: (highly simplified)

1) In a small shop (less than 40 developers), they tend to choose and remain with a standard set of tools, languages, libraries and operations/management tools just by inertia and a set of "principle" architects that provide the guidance. These "principles" can let things get out of control as they find and propose new technology and adopt it as the flavor of the week/month and in almost all cases operations, management and the rest are an afterthought and it causes issues

2) In larger (let's say a business with multiple business units (BUs) (with zero overlap in compute/data integration needs). It runs to a set of languages and financial decisions (can the programmers move between BUs when new features slow down, upward mobility, opportunity to grow, can we get an "Enterprise license" for the tools, language, DB, Etc.) that drive standards.

3) At the "Enterprise" (large, complex, BUs share/update centralized data (think banking with accounts, retirement plans, stock purchases, Etc.) level). You will almost *never* be successful without some sort of "standards body to set guardrails for what standards should be adhered to. Code bases, technical teams/guilds, communication on API contracts, management (let's just say the standard design->build->test->run model), Etc.

Now, for my two cents:

a) While a standards body is a must, it cannot be "ivory tower". This will cause the BU to just ignore and do whatever they think they need to reduce cost/improve performance/Etc. The needs of a BU (say one must release changes every "N" weeks because they're pushing mobile apps and new features are needed quickly to remain competitive), vs a centralized data team (BU), who only makes changes to the corporate data store on a longer time span since regression testing *MUST* be done to ensure no issues and regulatory approvals are in place. Yes, API/changes can be made (say a new DB view or table value), without much risk so two different APIs can be in place. However, it may be a prototype and not in the major release

b) As someone stated earlier, a standards body *cannot* be static, out-of-touch or so risk adverse that it impedes a business units ability to move at the speed needed. E.g. By moving to X, I can cut processing time by 100%, reducing my customer lag, user experience or cut the number of servers/CPU load if I can still meet my SLA by doing so. Now, that being said, if they are going to bend or go over the guard rails that far, they also have to factor in the central (or hopefully the have SREs in their model and already do most of their own support), support needs. Will they pay for new tools, SW, management tools, people to operation and perform break fix, Etc.?

So, your cost for going outside the guard rails may not have an ROI break even for doing it even though it looks new, exciting and sexy/bleeding edge. (hmm, I need to buy "X" dollars of new management tools and 15 new FTEs to run/manage it)

The best solutions I've ever seen are a set of non-biased technical and financial 'boards' that work through all of this with the BU/Dev/Ops (or DevSecOps if you want to use the current term), to help the BU and the Enterprise come to an agreeable decision and not allow the wild-wild-west

I had a very similar issue that was fixed by running the Lenovo update tool and it performed an update of the BIOS. Before that update the install failed ~5 times in a row and after the update it succeeded with no issues on the first try. It's worth a try

Don't know, but to me it's simple and easy. While the caller ID may be spoofed, they actually have the charge back info somewhere in the call setup data.

If you get one of these calls, just have a system where you dial a * code (e.g. *66) and it gets flagged. More than 100 (or larger number), per day flagged from your billing info and the callers line is blocked at the source and you have to explain why it should ever be re-enabled. This would include the business and bank/payment method so these callers would have to keep creating and opening billing accounts which is not trivial.

Simple, easy and most people can easily understand a simple add or flyer with "if you receive an unwanted call, just hit *66 after you hang up"

Concur, I play about twice a year just for the sheer fun when it gets above the $300 million mark. It's pure entertainment thinking about what to do if the 276M:1 odds ever fell in my favor :)

My only concern would be if the communication is bi-directional. E.g. one primary application thinking it's communication to a single instance/pump and pump 3 throws a "cannot perform command, error at line X" etc. Would the application then start throwing recovery commands that would screw up the others? I think I would go with his approach (assuming it's cost effective). If the vendor provided app assumes it's talking to a single instance/pump, do not mess with its error handling unless you know what impact if would have (e.g. 1 pump recovered, 6 never understood why they were receiving correction commands). Sorry if I misunderstood your approach

Do you mean "your remaining eye"?

I feel that you have your supplier/purchaser interaction backwards here. If supplier produces something that they consider worthwhile and then offer it for purchase. It's your right to agree or disagree on the price/terms and walk-away if you feel my product does not merit the price. Just because 'you' deem the product bad/overpriced does not give you the right to steal or violate the contract. Now, I freely admit that the current copyright extensions, patents, etc. have almost no basis in reality and should be returned to their original intent. They frustrate me to no end and are part and parcel of a large number of all our frustrations. However, the point is still the same. Your assessment of a product does not entitle you to freely take what someone else has produced (let's not go down the argument of digital theft is only copyright violation. Correct in legal terms, but someone is still losing something).

The problem I have with this example is item 1 "Read all of the instructions". By reading each line and performing the actions sequentially, I will have read all of the instructions by the time I've finished the actions.

If it was changed to "Read all instructions prior to executing them", then I could understand this experiment in reading comprehension