They are all pretty much the same: you buy into the franchise agreement for some amount of money and you supply some percentage of the assets and the company supplies the rest. Whatever that is or however it's broken up is determined by the franchise agreement. They all look pretty cookie-cutter, except for Chick-fil-A's.
As far as I can tell Chick-fil-A is doing that the best and no one is doing it like them. Their franchisee agreement is vastly different than anything I've seen - they treat it more like a partnership rather than someone/some group buying the rights from a company. I'm very surprised other companies haven't taken on this model.
It's possible to use them far more efficiently, thus getting better performance.
Reminds me a bit of those weird Forth computers that have 144 independent cores.
This sounds like common sense but I almost never see this practiced and it’s not forgiving of human behavior. Iterating faster means doing these things that I almost never see software developers do:
* measure things
* abandoning reliance upon popular conventions as determined by measurements
* reduce build/compile times
* abandon reliance of dependencies for slimmer home grown solutions
* use test automation to identify regression, and keep test automation fast (less than 30 seconds total run time)
* prefer WebSockets over http
* exchanging code vanity checks for more functional assessments
—-
The benefits of iterating faster include:
* dramatically faster defect resolution
* increased learning and more time for investigating alternatives
* lower risk of regression, as determined by sanity checks and automation like lint rules and test automation
* a given software team becomes more productive with fewer developers
* developers become more focused on their work due to loss of interruptions/distractions from frequent periodic delays
The only thing left is just a matter of time before you disrupt.
P.S. The majority of markets are price-sensitive ;)
Bitcoin's PoW provided reliable Byzantine Fault Tolerant consensus in un-permissioned distributed systems. It was a breakthrough, but provided only statistical finality. Hashgraph improved on that to provide asynchronous BFT (aBFT) and deterministic finality and blocking on detection of lack of quorum, but: global consensus still necessarily fails either Availability or Consistency on Partitioning.
By imitating physical distributed, decentralized systems where each agent only demands consensus with those agent(s) directly interacting with it, each "Agent" only maintains (and cryptographically proves authority for through PKI signing) its own state, and publishes that state to a shared best-effort DHT (where each party hosting an entry validates the entry by running the purported shared application "entry validation" code, rejecting the entry and "warranting" the offending node on detection of validation failure). Just like an immune system response.
Any traditional (a)BFT consensus algorithm can be implemented at whatever scale is appropriate for consensus, but usually only tiny portions of the global state (between a few parties) needs consensus, dramatically reducing the total complexity. Usually, simplistic algorithms ("everybody sign this entry and append it to their state. OK, everyone done?") are sufficient, and trivial to implement. But Hashgraph aBFT may be implemented, if you need it.
But, overall, the global system proceeds unimpeded by even large-scale Partition failure. You can glue the system together with "SD cards taped to pigeons", if necessary -- it just slightly increases your transaction times (from milliseconds to hours), but the shared system maintains internal consistency at all times.