Yes, but even then there are people who will ramp up faster.
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.
The programming language can have definite business impacts. It can impact hiring, salary costs (if the skill is rare), ramp-up costs (if it needs to be taught), etc.
Programmers will write more efficient algorithms if their employers tell them to trade time-to-market for hardware cost. Previously, it was trade hardware cost for time-to-market.
"Programmers" don't make this decision, the product owner does.
This matching up with sliced data, either sliced by recipient, or sliced by sender, so it makes sense to have primary state with cool backups. Particularly if the state is race-tolerant.
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].
It depends on where your clients are, and where your servers are. You may have a lot of customers in a country and not want to host servers in that country (tax, regulatory, maintenance cost, etc.)
RTT from Hyderabad to the East Coast USA is ~300ms.
Yesterday. I was reviewing for an exam and came across a bug in the profs text. I took a screen shot pasted it in the prompt and asked. It initially agreed with the Prof, then checked it's work, revised and agreed with me, all while showing the work it did.
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.
If your data is naturally sharded (users) with writes happening within a single shard, parallelism becomes easy. The request is routed to the shard hosting the user's data and reads/writes locally.
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.
Glancing through the study, I'm curious about both sample bias, and the lack of formal measurement. I'm not an expert in this type of thing, not even an amateur. I'm poking holes to see what's left.
"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.
It's not a single payment failure, it would be multiple days, possibly even a week to 10days.
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!
There would have been efforts to contact them, but it would have been via their contact method, aka the email they set it up with.
Common ways this happens? They are using a credit card to run their business with no backup payment method. Then the company's contact person is on vacation.
Do any refactorings in separate reviews, and say things like "REFACTOR_ONLY:", with a rule that none of the code changes behavior.
That makes reviews a lot easier. The review starts from "nothing should be changing" and then reviewers can pattern match on that.
Otherwise, the reviewer is re-evaluating every line of code to make sure nothing has changed. That's really hard to do properly.
The version control systems I've worked with have allowed queues of changes, each one reviewed independently. As I'm developing, if I need a refactor, I go up a commit, refactor, send out for review, rebase my in progress work and continue.
I send out a continual stream of "CLEANUP:" "REFACTOR_ONLY:", and similar changes with the final change being a lot smaller than a big monster of a change.
Your reviewers will appreciate the effort.
Plays the metric game (if you're working in that type of org) without being evil too.
Yes, that is what is required. Every dependency needs an internal owner and reviewer. Every change needs to be reviewed and brought into the internal repository.
If no one is willing to stand up and say "yes this is safe and of acceptable quality", why use it?
It's a software engineering version of the professional engineering stamp.
You are communicating with future readers of the code. The presence of ConcurrentHashMap will lead future engineers into believing the code is threadsafe. This isn't true, and believing it is dangerous.
Probably didn't work. Remembered though.