Otherwise, you're going to get bit by the Law of Leaky Abstractions.

The number of times I've been bit by systems not adhering to interfaces? Yeah, that's pretty frequent.

For example (from personal experience), the interface allows for race conditions, it's obvious they can happen (distributed systems), but the implementation didn't allow them, resulting in fun times.

High trust is high trust until someone exploits it, and the likelihood of encountering an exploit (embezzlement, fraud, political speech, etc.) approaches 100 as the total number of staff hours increase.

Otherwise, you're the only one who can fix your code, and becomes a whole bus factor thing.

https://github.com/dwmkerr/hacker-laws#kernighans-law

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

SOX requires code review by a second party. If the reviews are automated, the development process isn't in compliance and that can get expensive in a hurry.

It's about the cognitive load and having to follow branches.

The second version minimizes the cyclomatic complexity, taking it to 1. The reader doesn't have to keep the if statement in mind when reading through the code, and doesn't have to worry about all the ways the code can get there if they want to modify it (e.g. to add logging, metrics, other logic).

Whether or not consume should be a separate function depends on how often it's called. Here, I'm guessing it's once. :)

Probably didn't work. Remembered though.

If the company is using Common Lisp, do you have the 6-12 months to wait for them to ramp up, or do you hire someone who has done Lisp before? That is downstream from the technical decision to use Common Lisp, but it is a huge business impact.

Even bus-factor comes into it.

"Programmers" don't make this decision, the product owner does.

As long as event orderings are unimportant, or self resolvable this works really well.

e.g. if Events A,B arrive, but A+B => C and B+A => C, then as long as you durably record A, B, the end state is the same.

I'm not sure why "reroute" is a message instead of a response, I would expect it to be a failure response pruning the control flow. With the GTR being "default retry".

There's a lot of learned experience in that doc. Reading between the lines, both the logging and configuration systems have caused global outages (or near misses). Nifty to read.

This style of architecture fits with a "no global changes" and "never lose it all" approach to fault tolerance, accepting that there will be visits from "Mr. Cock-up" [1].

Very nice writeup.

[1] https://www.youtube.com/watch?v=D5r8xwu0l8w

RTT from Hyderabad to the East Coast USA is ~300ms.

Then you have execution and database retrieval.

https://wondernetwork.com/pings

I was able to see why it got confused at the start, attempt to confirm, fail, and then calculate from the data and come to the opposite conclusion.

This makes scalability _much_ easier to reason about. It's cut-paste, cut-paste. Every N users needs another shard.

It does buy you a _different_ set of problems, like cross-shard querying (analytics) and how to do load leveling as users age out.

But it avoids the whole shared index scaling problems from inserts/updates with large user counts.

It becomes a hierarchical instead of a relational database.

"Participants were identified via media reports featuring Australian firms trialling the 100:80:100 model, in addition to companies listed on recruitment sites that specialise in 4DWW jobs. In other instances, eligible organisations were recommended by the participants themselves."

I'd expect organisations with positive results will be the ones recommended by other participants - "talk to these people, it worked for them too!"

I'm also interested in whether or not organisations converted all staff to 100:80:100, or if it was optional. Is the performance driven by peer pressure?

Finally, the participants' measures of productivity will have significant lag time in them, so it depends on trial's length, e.g. "revenue", "profit", "csat", "projects delivered on time", "net promoter score".

Table 1 has "Duration", but the units are unlabelled, if it's weeks, it's less than a year, months is probably better for seeing performance changes.

It's an interesting qualitative study, I'd certainly like a four day work week with no change in comp.

This is why businesses should put in the effort and sign up for credit terms. Then it's an invoice, and you reduce this risk substantially.

Credit cards are _not_ reliable at this scale. Banks are offline all the time, cards are marked stolen, protocols change, all sorts of things that will cause flags indicating "the money can't move down that path".

Businesses that pay for AWS/Cloud/etc via credit cards are trying to buy reliability but put it behind a single point of failure.

Credit cards are not how you should be paying for business services with uptime requirements!