DEV Community: Bryce Miller

TL;DR VISA is 400x slower than Bitcoin (and 1000x slower than PayPal)

Bryce Miller — Wed, 08 Feb 2023 19:41:49 +0000

A criticism of Bitcoin that unites both the pro- and anti-crypto crowd is that Bitcoin is slow. The comparison is usually made against Visa and sometimes PayPal, with Visa's transaction speed of 24,000 transactions per second (tps) and PayPal's 193 tps compared favourably against Bitcoin's paltry 7 (yes, seven) tps. The crypto-bros then argue that Bitcoin really has to beat Visa's tps if it wants to be taken seriously, while the crypto-nos use this as evidence that Bitcoin can never be taken seriously.

Payment System	Speed
Visa	24,000
PayPal	193
Bitcoin	7

There has been some technological advancement since the original comparisons were made, significantly increasing Bitcoin's tps (so I guess the crypto-bros are winning?), but what strikes me most about this argument is that it's an argument about the wrong things.

Let me explain...

The numbers are wrong(ish)

I'm not accusing anyone of fabricating facts or acting in bad faith, but I do want to question which number we are using, and if they are the correct numbers to use.

For example, the claim of 7 (yes, seven) tps for Bitcoin is not borne out in reality. The "normal" rate is actually 3-4 (yes, three to four) tps, or about half of what the usual claim is. For Bitcoin, things start looking twice as bad immediately.

When it comes to Visa, the claimed speed of 24,000 tps is a measure of the maximum capacity of the Visa network. In fact, Visa claims a max capacity of over 65,000 tps, so the figure everyone is working from is less than double the actual max capacity. However, the average, measured transaction throughput is 1,667 tps. This number, though still impressive, is never-the-less around 7% of the 24,000 number, and a little over 2.5% of the 65,000 number. Basically, we are over-estimating Visa by ~14x-40x when we use these larger numbers as comparisons.

For PayPal, the 193 number seems correct, although in the first quarter of 2022, PayPal processed 664 tps, so there may be some flexibility in the actual capacity of the PayPal network.

For my money, I'm more interested in the "normal", "average" use-case, not the maximum theoretical capacity.

TPS is not a measurement of speed

You'll notice in the last section, I smoothly transitioned from using the word "speed" to using the word "capacity", because transactions per second isn't actually a measure of speed, but a measure of capacity.

Imagine you have to cross a toll bridge. You arrive at a payment plaza, stop at the barrier, roll down your window, and throw your change at someone shivering in a plastic box. You nearly fall out of your car trying to get the ticket/receipt, and the barrier is lifted, allowing you to traverse the bridge.

In this analogy, transactions per second is how many toll booths there are. For Bitcoin, the plaza is 3-4 lanes wide, with 3-4 toll booths. For PayPal, there are 193 lanes/booths, and for Visa 1,667.

This doesn't tell you anything about how fast you can go over the bridge.

For networks like Visa and PayPal that are apparently massively under capacity, the existence of 65,000 toll booths means nothing to the 1667 transactions. Go ahead, knock yourself out and add 65,000 more, it won't increase the speed because capacity is nowhere near its limit.

I appreciate that the difference between capacity and speed is subtle, and that there is a relationship between the two, especially if we start to talk about reducing capacity. However, the toll booth is just one part of the transaction, and it's not clear that the entrance to the bridge is where the traffic jam is. Adding more toll booths won't make it take less time for me to drive to the bridge, across the bridge, or to my destination. Spending an extra ten minutes at the toll plaza doesn't matter if I have to spend three days driving to my destination.

A transaction isn't what you think it is

When talking about transactions, we often think about it from the point of view of the consumer. I pay my money; I get my prize; transaction over. However, when a customer has paid and the Visa card reader goes "beep" is not the end of the transaction - it's the start.

Consider this from the point of view of the merchant selling you your cool can of Coca Cola. For them, the transaction is complete when and only when they receive their money. That is the end of the transaction.

Merchants don't get paid when your card payment is authorised. They get paid when the payment has been processed.

In the best case, authorised payments will be collected by the payment processor and sent to Visa for clearing at the end of the day. In the worse case, it can take a whole week, depending on the payment processor and time of purchase. After payments are sent to Visa, processing can take anywhere from 24hrs to 3 days. Adding it all up, a Visa transaction can actually take as long as 10 days for an individual recipient, or as "little" as 24hrs for payments made just before collection time. The average for most merchants is 3 days.

In the case of Bitcoin, a new block is added to the blockchain about every ten minutes. Sometimes blocks are added faster than this, but generally the average time is ten minutes. You might think this means that the worse case transaction speed is ten minutes, but there is actually no guarantee that a given transaction will make it into the next generated block. Or even the block after that. Or any block at all. It will eventually make it into the blockchain, providing the user hasn't cancelled it first. The average confirmation time varies, but is around 10-15 minutes (with 90 minutes being the "peak" average for transactions in February 2017 for some reason...)

For PayPal, it's a bit more complicated. The transaction times depend on whether or not the person paying has a PayPal account or not, and if you want the money transferred to your bank or just kept in your PayPal merchant account. For the sake of comparability and fairness, let's look at the example where a PayPal user purchases using money in their PayPal account, and where the merchant uses a PayPal account as their business account.

Unsurprisingly, this is the fastest transaction, taking what PayPal likes to call "a few minutes". I can't find an exact number of what "a few minutes" is, but it sounds like it's between two minutes and five minutes. Let's land on three minutes to be generous to PayPal's slow competitors.

The real transaction Speed

Looking back at the table at the top of this article, and applying what we've discussed, we get a very different picture.

Payment System	Min Tx Time	Max Tx Time	Avg Tx Time
Visa	1440	14400	4320
PayPal	2	4	3
Bitcoin	1	90	10

Visa is actually the slowest payment system, since payment collection and processing takes days to complete. Bitcoin is 400 times faster, taking a reasonable 10-15 minutes due to the time it takes for blocks to be confirmed by multiple nodes on the network before a transaction can count as verified. Unsurprisingly, PayPal, the centralised company that carries out transactions by subtracting a number from one row in a database table and adding it to another row is the fastest, taking just "a few minutes", or about 1000 times less than Visa.

This isn't going to be the end of the comparisons. Visa is now offering "fast payments", which can see you getting your money in a best-case four hours, worst-case two days (a whole day earlier than otherwise!), and I'm sure they won't stop there. Bitcoin now offers Bitcoin Lightning, with a theoretical capacity of 1,000,000 tps, and (as of yet) no figures on what this will mean for real transaction speed.

Visa taking three days on average also isn't a reason to throw out your POS terminal and start accepting Bitcoin. There are other factors at play, and they offer different advantages and disadvantages beyond when money?

If I were a Bitcoin developer and wanted to dominate payments, I wouldn't spend my time in a tps race with Visa and PayPal. I would focus more on things that would make people want to use Bitcoin for payments, like widening acceptability; increasing security and trust; and price stability.

But please don't look at price stability until I'm a millionaire, thank you.

What's the point of Bitcoin?

Bryce Miller — Fri, 30 Dec 2022 20:44:20 +0000

With the bankruptcy of high-profile cryptocurrency-exchange FTX; fraud and money-laundering charges levelled against their former CEO; and the general fall in value of various cryptocurrencies (including bitcoin); people have been reacting with anger, frustration, and in some cases, superiority. If you lost money in the FTX collapse, your anger and frustration is of course justified. If you have been disapproving of Bitcoin for a while now, then you should certainly enjoy the current climate, but some of the self-righteous seem unaware of what problem bitcoin solves and what use-cases it has. In general, they ask: what's the point of Bitcoin?

I understand the scepticism. I personally didn't think much of Bitcoin or blockchain until I delved deeper and took some professional certificates. I also remain critical of the general cowboy behaviour of many in the crypto sector (reminds me of the web's early days, actually), and the prevalence of scams, frauds, and cons (who could have thought that a trustless system would have a trust problem?).

A lot of what I write in this article will apply not just to Bitcoin but to other cryptocurrencies as well. There are some legitimate criticisms of specifically Bitcoin in terms of transaction speed, electricity consumption, and environmental impact, as compared to private money transfer networks such as Visa; which have been solved in other cryptocurrencies/networks, but I want to focus on Bitcoin because Bitcoin was the first digital currency to practically solve the Double Spending Problem.

The Genesis of Bitcoin

October 31st, 2008 wasn't just any old Hallowe'en. It was exactly one week after many of the world's stock exchanges had experienced their greatest loss in history, signalling the largest financial crisis in human history. This had followed the collapse of Iceland's three biggest banks; the introduction of federal guarantees for US depositors; the bankruptcy of Lehman Brothers; a bank run in Great Britain; and the subprime mortgage crisis. And it was the day that the white paper describing Bitcoin was published.

This was no coincidence. The financial crisis created a crisis in trust among ordinary people when it came to banks and financial institutions, going so far as to precipitated a mass, grassroots political response in the US on both the right (in the form of the Tea Party Movement) and the left (in the form of Occupy Wall Street). The Bitcoin white paper can be viewed as a reaction to this loss of trust as Bitcoin provides a way to exchange money digitally without the need to use a trusted third-party such as a bank, credit card company, or other financial institution. But why can't we just send each other money? We can't because of the Double Spending Problem.

The Double Spending Problem

Alice is a fan of pop-country icon Taylor Swift. Her friend, Bob, is also a Swiftie. He managed to get two tickets for Taylor's concert in their home town, so Alice owes Bob $200 for her ticket. A few nights ago, Alice went on a big night out with her friend Charlie. For convenience's sake, Charlie put everything on her card, and texted Alice afterwards with the damage: $200 for food, drink, and karaoke. Alice just received an e-mail with $200 from her Aunt, so she only needs to find another $200. Luckily, her computer can easily make counterfeit money, indistinguishable from the original, by simply making a copy of any money file. So Alice makes a copy of the e-mail, and sends it to Bob. She then makes another copy, and sends it to Charlie. Alice has effectively spent the same money twice because she has an infinite duplication machine.

Of course, in a real-world scenario, we wouldn't accept money sent as a file in an e-mail. We would have no way of knowing if it actually was genuine money, or if it was a counterfeit copy. In centralised systems, we rely on the trust we have in a provider such as a bank, credit card company, or an app like Venmo (we let them decide if the money has been spent or not, and trust their decision). But in 2008, trust was at rock bottom, and Bitcoin proposed a way to solve this problem without requiring trust.

Bitcoin's solution is to store identical, public copies of the list of transactions on multiple servers. Batches of transactions are verified by solving a puzzle, with each puzzle including the solution to the previous puzzle. In this manner, a tamper-proof chain of blocks (or a blockchain, if you will) can be created. If someone attempts to change one of the blocks so that they can spend the same money twice, then we can easily detect this, because the solutions would no longer match, and the chain would be broken.

(There are other mechanisms in place to avoid other potential clashes, and the blockchain can actually be tampered with using a 51% attack, but for a network as large and diverse as Bitcoin, this is unlikely to happen.)

As the chain is public, anyone can independently view and verify the transactions at any time, thus removing the need for trust in an institution, because trust is built into the very way Bitcoin works. This unlocks the ability to have a fully functioning currency network, where individuals can transfer money digitally in much the same way as they would with cash.

Bitcoin Use-Cases

Now that we know what problem Bitcoin is actually trying to solve, I want to present two use-cases of Bitcoin.

Payment

Bitcoin is meant to be a currency, so of course payment in exchange for goods or services and the settlement of debts is an absolute no-brainer use-case with some 15,000 businesses accepting Bitcoin as payment globally.

In a free society, making payments may seem trivial, but in stricter regimes, authorities may attempt to block online payments in order to maintain censorship regimes. For example, in China, the sale of texts critical of the government, or relating to restricted religious movements (e.g. Falung Gong, Christianity), or LGBT-related materials, or the film Avatar are banned. In 2016, five people were arrested for selling Christian literature, receiving a minimum of three years in prison.

Even the land of the free provides us with a good payment-related use-case for Bitcoin: purchasing reproductive healthcare. Some ten US states ban abortion completely, with at least three states making moves to also ban some forms of contraception. If the purchase of at-home abortion pills or day-after contraception is restricted by law, then financial institutions such as credit card companies will not facilitate such transactions. In Texas, citizens can sue those who assist women before or after an abortion, and can receive $10,000 in damages for doing so, even if they are not party to the abortion, companies that provide reproductive healthcare can be targeted by literally any texas resident. Being unable to access reproductive healthcare is a terrifying prospect for victims of abuse, where such access could be life-saving.

Bitcoin can circumvent these restrictions as the network cannot be shut down by a single actor, transactions can be made anonymously, and cannot be reversed or cancelled, so it is significantly harder for the state to interrupt payments.

Remittance

For those of you lucky enough to be reading this from the comfort of a wealthy, western country, you might not have heard of the word "remittance" before, but for Indians, remittances are worth $87 billion, and for Tajikistan remittances count for over 40% of the country's GDP.

Remittances are simply money from an overseas worker in a rich(er) country, sent back to support relatives in their (often significantly) poorer home-country. Countries such as India, China, Mexico, and the Philippines are among the top recipients of the total over $715 billion remitted globally each year.

The biggest problems with remittances are that sending money internationally is expensive for the sender, administratively time consuming for the sender, the receiver, and the company carrying out the transfer (having to turn up in person to send/receive cash can result in a loss of money; physical forms increase error rates and require staff to process), and that it can take between two to five days for the money reach the recipient.

Bitcoin solves this by having lower transaction costs. The sender can send as much bitcoin as they like for between $0.04-$0.90, depending on how quickly they want the transaction to be completed. As Bitcoin is a digital currency, the sender can leverage digital tools to fill out the transfer details automatically, without having to go down to a remittance office or fill out a form in person and reducing the risk of mistakes and potentially losing money. As alluded to above, Bitcoin can be transferred significantly more quickly than a money transfer, taking anything from within ten minutes up to an hour, with the Bitcoin Lightning Network offering virtually instantaneous transfers for $0.04. Knowing that they can receive it so quickly in the case of an emergency is a great comfort to people who rely on this money, and being able to access it without being at the mercy of the remittance office opening times, or distance from where you live makes a huge difference. The sender and recipient can even share a Bitcoin wallet, eliminating the need to wait

Since Russia's invasion of Ukraine in February 2022, another remittance-related problem has arisen: sanctions on money transfers from the Russian Federation.

9-11 million migrant workers send remittances from Russia to their home-countries. As mentioned above, remittances count for over 40% of the GDP of Tajikistan, and over 30% of the GDP of Kyrgyzstan. When Russia was rightly sanctioned for their illegal war on Ukraine, remittance companies ceased operations in Russia. Russian banks were also excluded from the SWIFT system for making inter-bank transfers. This removed the ability of many migrant workers to send remittances. Obviously, Russia's actions in Ukraine are wrong, but the blame does not lie with a desperate Tajik family who are reliant on money from a construction worker in Russia.

Similar to the points about Bitcoin protecting payments from state interference, Bitcoin can also ensure that vital remittances continue because the network cannot be controlled by governments, and transactions can be made anonymously.

You Probably Think I'm a Cryptobro Now

Don't get me wrong. I don't think Bitcoin is some panacea. I don't think the government is out to get you. And I do think that Bitcoin is currently more suited to being a commodity than a currency. But I also think that Bitcoin does have a purpose; has legitimate use-cases; and does solve real problems that touch people's lives.

While those that are critical of Bitcoin, cryptocurrencies, and the abundance of bad actors in the space are right to criticise, and are right to enjoy the current moment, I do think it's glib and facile to say Bitcoin has no purpose and solves no problems. I've shown here that Bitcoin overcomes an important hurdle
in developing digital currencies. I hope I've shown exactly how simplistic such reactions can be.

The Functional, Usable, Delightful of... Ketchup

Bryce Miller — Tue, 25 Oct 2022 18:49:57 +0000

Functional

It's not coming out! Just hit it! It's still not - oh.

The nostalgic taste of frustration.

Usable

Let gravity do the hard work for you.

If your planet doesn't have enough gravity, it's squeezable too.

Delightful

I vant to dispense zis ketchup

All Your Metaverse Hot Takes are Wrong (and mine might be too)

Bryce Miller — Wed, 07 Sep 2022 19:26:54 +0000

In which I make a bold claim that may prove to age rather poorly

A lot of people have been enjoying clowning on Mark Zuckerberg and Meta Metaverse lately. As a Millennial who has just opened himself up to ridicule be using Gen-Z slang, I too am sorely tempted to jump on the bandwagon and criticise the floating, severed torsos; the graphics that would make Animal Crossing fans throw their Nintendo Switch in the bin; the bulky, expensive headsets and Nintendo Power Glove controllers; and the way that Mark Zuckerberg really leans in to being perceived as an emotionless robot. The truth is, however, that I am conflicted.

I am conflicted because I can't help but think back to a mistake I made fifteen years ago ~~this very night~~; a mistake concerning the prospects of a company that is now the second most-visited site on the entire internet, generating ~$30billion in revenue. It was a mistake that led me to mouth-off about how nothing is going to come of this website; that the site is economically infeasible; and that nobody in their right mind would ever want to watch anything on a screen that small. I was talking about YouTube.

The First Year of YouTube

In early 2006, YouTube was haemorrhaging a million dollars a day on bandwidth and serving low-quality, low-resolution videos, that took ages to load even for someone like me who had the most advanced home internet connection available (twin ISDN, anyone?).
To me, the idea that YouTube would have mass appeal was ludicrous, because it just wasn't good.

At the time, I thought this was a perfectly reasonable conclusion to draw from the evidence provided. Obviously, I was majorly wrong, and that was because I was making a mistake called static thought.

Static Thought

Static thought is a term used in Developmental Psychology to describe a child's belief that the world is unchanging. They believe that how things are in the present is how they always have been and how they always will be. Please note, that when I made my terrible YouTube prediction, I was not, in fact, a child, but rather a 21 year-old adult with only a few months left on my degree (with Honours) in Computer Science, from a university ranked in the global top 50. So I should have known better.

Specifically, when it came to YouTube, I was guilty of thinking that the level of technology that we had in 2006 would never improve, even though a cursory glance at the recent past would show such an idea to be completely wrong.

I believed that the video resolution would always be low, failing to predict HD and 4K video formats. I believed the videos would always take ages to load, unable to foresee the massive increase in internet speeds that were just over the horizon. I thought the general quality of the produced videos would always be terrible, unable to understand that not only would cameras get better, cheaper, and more accessible, but also the people making the videos learn, adapt, and grow, and improve the quality of their content as well. Most laughable of all, I actually thought that the size of the video player would always be tiny, and that would be a huge problem. Yes, I even thought they would never be able to go full screen.

I was dead wrong.

The Metaverse is Actually Within Reach

Fundamentally, the reason it is so easy to make fun of the Metaverse is that the reality is so monumentally far from what we've been promised.

When Mark Zuckerberg revealed Meta's vision for the Metaverse in the autumn of 2021, we were presented with hyper-realistic graphics, as good as any CGI render, with the real-world Mark Zuckerberg walking around this environment. Although he does mention putting on glasses or a headset, Mark enters the Metaverse without these. He shows us a girl in a park playing table tennis with a remote opponent, in real-time (and she isn't wearing a headset, either).

This impressive, superlative, perfect vision is what we are led to believe the Metaverse is, but what's actually been delivered is a mega-bucket of disappointment. The graphics suck, everyone has half their body missing, even the promotional material seems to take place in an empty nothing-space, inhabited only by Mark, the Friendly Ghost. It's like those hastily-thrown-together, obvious-scam, crappy phone games that are not anything close to the advert of screenshots on the Play Store. The quality is just so degraded, it's absurd. We've been promised the holodeck from Star Trek, and they've delivered some sort of paper doll puppet theatre.

But to write the Metaverse off at this time, and to believe that how the Metaverse is now is how it will be ten years from now is to make the same Static Thought mistake that I made with YouTube fifteen years ago.

If we look at the development of computer graphics, internet speeds, technological miniaturisation, and the emergence of digital holograms in the entertainment industry, then we can clearly see that every element required to make the Metaverse vision a reality has a very good chance of actually happening.

Computer graphics on games consoles are approaching the point of being indistinguishable from reality. 5G mobile internet can already deliver up to 1000Mbps, with the potential to reach as high as 4Gbps in the future, with 6G mobile internet already in development. Miniaturisation has led to commercially available processors with 64 cores, computers the size of a phone, and phones with multiple tiny cameras of a better quality than the last actual camera you bought, priced at the budget end of the market.

Holography seems the most out of reach, but just consider the great strides taken between Tupac's 2012 Coachella appearance and ABBA's 2022 Voyage tour. The advancement with the Tupac hologram was that it really did look like he was on stage, even if it was still clear he was a hologram because he was shining like a lighthouse on an otherwise poorly-lit stage. The ABBA digital ABBAtars look like actual human beings, with minor lighting problems creating an uncanny effect from time to time. The challenge for Meta is to make these digital holograms render at such a high quality in real-time, something which all the other technological elements mentioned above will have a hand in.

It could still be rubbish, though

I'm not saying that the Metaverse will happen and that it will be a great success. Meta could decide to move in another direction, and just cancel the Metaverse project, just like they did with their virtual assistant, M. They could double-down on the graphics and make the cartoon-ish style a decision rather than a technical limitation. Or they could ruin it in some other, unforeseen way, just like how Facebook ruined Facebook by turning it from a place where university students organise their social lives to a place where conspiracy theorists organise insurrections. The Metaverse could just turn out to be something that few people actually want to spend time on, like Second Life or Habbo.

The point is that all of these jokes about the graphics, the quality, the headsets, and how objectively terrible it is is a static thought, equivalent to how the Toyota Prius was literally the punchline to a joke about electric cars 20 years ago, and now electric cars have become the ultimate middle-class status symbol.

We should step away from our static thoughts and consider that the Metaverse vision actually has a good chance of being the reality ten-fifteen years from now. If I'm wrong, you should let me know then, because right now the Metaverse is a Smosh video filmed on a webcam in 2006, loading on a dial-up modem, and just as it was a mistake to judge YouTube based on that, then, it is a mistake to judge the metaverse based on how it is now.

You've reached the end! Thank you so much for reading!

Read Next:

>> That Time a Usability Test Made me Want the Earth to Open up and Swallow me Whole

>> Self-Driving Cars can't Solve the Trolley Problem, Neither can You, and That's OK

>> The Functional, Usable, Delightful of... Park Benches

The Crypto-Krone is Just Around the Corner. You Won't be able to Live Without It.

Bryce Miller — Mon, 15 Aug 2022 19:16:59 +0000

If you live in Norway like I do, then it will be no surprise to you that Norway has the lowest physical cash use in the world, with fewer than 4% of transactions using money you can touch. Sure, there was a pandemic, and the shops that remained open only accepted card payment (despite the risk of transmission via cash being low), but since you live in Norway like I do, you also know that we were basically becoming cashless anyway.

Between card-only bars, vippsing Margrete at work for the wine lottery, and it being impossible to buy a bus ticket without a smartphone, there was a sense of inevitability here, guys (if you're one the several billion people who don't live in Norway, well, now you know some cool facts you can tell your workmates at lunch #lunchboss).

However, even if you do live in Norway, you probably didn't hear this news: Bergen-based crypto-tech company Nahmii has been chosen by Norges Bank, the Norwegian central bank, to provide a test environment for digital currency experiments. Every bank in Norway is expected to participate in these experiments, building experience using digital currencies. Visa and Vipps is not the end of the digitalisation process.

The end-goal is to create a CBDC, a Central Bank Digital Currency. These are digital versions of national currencies like the Pound, Euro, or Yen, which are government-backed, legal tender, and exactly equivalent to physical coins or banknotes, and where every transaction involving these currencies is stored on a publicly available digital ledger. And, as you probably have already guessed, Norway isn't alone in investigating CBDCs.

Sveriges Riksbank, the central bank of Sweden, another country with extremely low cash use, is also looking at issuing an e-Krone. India is planning to introduce a digital Rupee for its 1.4 billion people by the end of 2023. Both the Bank of England and the US Federal Reserve are investigating CBDCs for the world's largest financial centre and largest economy. Even the Eurozone is preparing for a digital Euro.

The world's money is becoming increasingly digitised, and the central banks of the largest countries and economies are acutely aware of the advantages that CBDCs afford. While the plan to introduce a crypto Krone hasn't received a lot of news coverage in Norway, it will only be a matter of time before we see it next to bitcoin and ethereum in our digital wallets.

CBDCs will come with both advantages and disadvantages. The velocity of money will increase dramatically, improving cash-flow for businesses and individuals. The digital public ledger will make black market and under-the-table transactions impossible. Taxes will be collected and benefits distributed instantaneously. And one hack, one denial-of-service attack, one vulnerability could shut down new transactions entirely, make it impossible for individuals to access their cash, and bring the national economy to a standstill. In a less extreme scenario, we will become ever more reliant on electronic devices as they become our only way to access to basic necessities like food and clothing. No phone, no food; no signal, no shelter; no power, no payment.

As I mentioned earlier, CDBCs appear inevitable. Despite this, most people (even in a high-tech, early-adopter-filled society like Norway) have no idea what crypto currencies actually are and how they work, let alone that central banks are actively pursuing them. So when the time comes to embrace the new currency format, most people will have no idea what the repercussions will be, both for good and for ill. And eventually, just as it's becoming increasingly difficult to live in Norwegian society without a smartphone, it will eventually become impossible to do so without a smart wallet, and the crypto-krone will really become something you can't live without.

Self-Driving Cars can't Solve the Trolley Problem, Neither can You, and That's OK

Bryce Miller — Tue, 31 May 2022 19:29:39 +0000

The Brain of a Four Year Old

Recently, I recreated the classic trolley problem using a wooden Brio train set. A train is hurtling down a single track. Up ahead, I placed five Playmobil people on the track. Between the train and the five figures is a junction. The junction leads to a section of track with plastic giraffe on it (we had run out of figures).

The question I posed to my pre-school tyke was what will you do? Will you put the train down the first track and hurt five people, or... LISTEN, LISTEN! Or, will you put it down the second track and hurt the giraffe?

You can play along too and decide for yourself which of the tracks you would send the train down.

My genius son knew immediately what he would do. He picked up the entire track and shook it until it fell apart, thus rejecting the problem entirely. A pair of black sunshades appeared from nowhere on his face and everyone clapped.

Why am I telling you this? Apart from boasting about the little rascal's genius-level intellect, it's because ~~I can't drive~~ I am interested in self-driving vehicles.

Mo' Trolleys, Mo' Problems

The type of Trolley Problem often associated with self-driving cars is one called The Tunnel Problem. What's unique about this problem is that the choice is not between you murdering more or fewer people, but between your own self-driving car murdering a stranger, or murdering you.

The car is approaching a tunnel. Suddenly, a mother with a pram steps in front of the vehicle in order to cross the road in front of the tunnel. Should the car protect the passenger (you), by ploughing into this innocent mother+baby combo, or should the car drive directly into the tunnel wall, killing the passenger inside (you)?

Most people take a utilitarian view of the first problem. Five lives are "worth" more than one, so flip the switch, and kill the one person. Job done.

For the second problem, most people abandon the sober, rational calculation, take the selfish view and say push that baby under this car and let me ride my self-driving chariot to safety town.

It shouldn't really be surprising that when it comes down to it, we abandon utilitarianism for our own survival. What is surprising is that when we discuss self-driving cars, Trolley Problems come up at all.

Let me explain

Trolley Problems are the biggest red herring in any discussion about autonomous vehicles. 96% of all road accidents are classed as preventable. This means that if the driver had kept to the speed limit, stopped the car before fiddling with their phone, or taken a taxi after having had too much to drink, then they would have gotten home safely instead of into an accident.

The remaining four percent of road accidents are divided into causes such as mechanical failure, adverse weather conditions, the physical condition of the road, or, yes, people walking in front of a tunnel.

The fact is, Trolley Problems are vanishingly rare in real life. Autonomous vehicles don't get tired or drunk. They don't get distracted or drive over the speed-limit. A self-driving car will never be the cause of these types of accidents, not because they have some moral reasoning module or follow some prime directive of protecting the passenger at all costs, but because they simply don't get into the situation where these accidents will occur.

Accidents caused by other road-users appearing from "nowhere" can also be reduced. A human can't look through a poorly-maintained, over-grown shrub to see a hidden cyclist, or round a corner obscured by a wall, to find a semi-trailer, but an autonomous car can use various technologies to do just that. Self-driving cars can prevent accidents from happening that for a human driver would be unavoidable.

Trolley Problems can't occur if we are able to mitigate them. Ethics and morality modules aren't needed if we avoid situations requiring them.

You can't solve this problem either, driver

There will still be cases where technology cannot be employed to circumvent a potential accident, such as the time a deer jumped straight off a cliff and onto the bonnet of my friend's car.

In the title of this post, I boasted that you can't solve the trolley problem. But I just did! I hear you cry, you walked us through the scenarios and I solved it every time! Well, you certainly solved it sitting down at a desk or kitchen table with your head shoved up your phone, but would you be able to solve it while driving a car at speed?

40% of drivers don't hit the breaks during a car accident. People just have a tendency to tense up and do nothing. Hitting the breaks is the simplest, easiest thing to reduce the horror of an accident, and yet a little under half of us can't manage to do it. In fact, in some accidents the driver actually presses sharply on the accelerator, increasing the chance of collision. If a car simply applies the breaks to avoid collision, the number of accidents can be reduced by over 40%. When Tesla introduced auto-pilot, similar results were also found.

Self-driving cars don't have to be perfect and they don't have to solve myriad trolley problems. They just have to be a better driver than you, and at least in my case, they already are.

The Functional, Usable, Delightful of... Tea Bags

Bryce Miller — Wed, 11 May 2022 19:48:14 +0000

Functional

Try removing this tea bag from your cup. You will burn your fingers off

Usable

The pyramid allows more room for the tea to circulate, and the little tab on the string makes removing the tea bag easy-breezy.

Delightful

What? You were expecting something cute, maybe?

Modern Cookie UX is Rubbish

Bryce Miller — Wed, 27 Apr 2022 17:38:47 +0000

Look at the State of This Place

Navigate to almost any page of the web today, and you will be met with a modal pop-up, full of jargon-ridden text about cookies and links to privacy policies and terms and conditions so long that you couldn't possibly read and understand it all before consenting to the use of cookies. In the meantime, the site is visible through a semi-transparent layer covering the page, and by the time you've accepted all the cookies, you've forgotten just why you visited the site in the first place.

This is not a good user experience...
...And it's all over the web.

Why is it Even Like this?

The rules governing cookie consent are laid down in Directive 2002/58/EC of the European Parliament and of the Council - a long and difficult text, full of legalese that is as transparent as your cookie policy. Have you read it? I bet most people who implement these solutions didn't either - and those that have read it would have a hard time knowing what to actually do.

It's not surprising that most solutions are identical - who would want to read through and interpret such a text when they could just copy a "best practice" example and call it a job well done?

Beyond the confusion caused by the legal text, it's simply easier for the developer to package everything into a central, one-shot consent modal than to integrate a more user-friendly and sophisticated solution. Even easier is to purchase an off-the-shelf module and integrate that - and of course such a solution would not be architected in a sophisticated manner, tailored to your website, but rather in a way that makes it quick and easy for the developer to integrate - just add a javascript file to your page template, and a central, one-shot consent modal will solve all your cookie consent problems!

Finally, departments in companies often have competing goals that affect the choice of implementation. The revenues department may want to maximise advertisement revenue, so will want a solution that nudges the user to accept targetted ads from the first page-load, even at the expense of the overall user experience.

What each of these explanations have in common however is that they are focussed on making the company's life easier. To create a solution that makes the user's life easier, we need to understand what types of cookies exist, and what sort of consent is required.

The Four Cookie Types

We can categorise cookies in many different ways - duration, origin, function, etc. For our objective, we will split cookies up into four types by purpose.

Strictly Necessary Cookies
Cookies which are necessary in order for users to use the website. This includes features like user authentication and shopping carts. Normally, these features will be implemented using first-party session cookies.
Preferences Cookies
Cookies for remembering user settings between sessions. For example: language and regional preferences or information for automatic login.
Statistics Cookies
Analytics cookies used to harvest information about how users use a website - Which pages have they visited? Where did they click? Is this visitor unique?
Marketing Cookies
Cookies which track the websites a user has visited in order to deliver targeted advertising.

Consent is not required for Strictly Necessary Cookies or Statistics Cookies, but the existence and purpose of the cookies should be explained to the user. For all other cookie types, consent is required.

A Solution

How could we structure a better solution? For Stricly Necessary Cookies and Statistics Cookies, my suggested solution is straight-forward - a link visible on every page called "Cookie Policy". This link will take the user to a page detailing what the cookies do, and why they are necessary, thus fulfilling the requirement to inform users. It could be in the nav-bar at the top of the page, in a side-bar, or at the bottom in your footer menu. The important thing is not the placement, but that it is clearly visible and accessible.

For Preference Cookies, I think we have a few options: requesting consent at time of use, requesting consent at login/signup, not saving preferences for non-logged in users.

Requesting consent at time of use can be achieved through a simple checkbox when submitting the preference or at first interaction, as appropriate. The label for the checkbox can link to the cookie policy for that specific cookie or a more general policy. It might become annoying for the user to constantly tick checkboxes for every preference setting widget a website has, but to be perfectly honest, I'm having a really hard time coming up with a use-case for a preference that I would want/need to persist across visits. Answers in the comments below?

Not saving preferences for non-logged in users is pretty straight forward, and we can use techniques from the "old" web (query string params, anyone?) to persist across pages, but not across visits.

Requesting consent at login is also pretty straight-forward and trivial to envision. We could employ the same check-box and link in label solution for requesting consent at time of use, or we could take today's modal popup and cram that into the sign-up/account setup page.

The real problem (and the real reason for the ePrivacy Directive) is Marketing Cookies. This is why you're getting the big modal popup - so that the website can make more money from adverts that are targetted specifically at you.

We've already discussed an unobtrusive way of requesting consent from users with an account. This method can be used in this case alongside a time-of-use consent mechanism. Near any advert a user sees, we can place a button that says "Show me relevant ads", with a link to our cookie policy beside it. When the user clicks the button, they consent to the site's marketing cookies. Users who don't/haven't yet consented can be served adverts based on approximate location.

Yes, I know, your colleagues in ad revenues will be upset that they don't pay as well as targeted ads. But do you what pays even better? Actual brand deals. They require no cookies, no tracking, no targetting, and will earn you more! This is what youu say when the ad revenues department complains.

High-Five

We've solved this now, I guess? Well, we've solved part of it. I think. It sure sounds nice - visit a website, only consent to what you want to, when you need to by checking a few boxes or at signup. Turn on targetted ads if you like, or get adverts for your local area restaurant if you don't. So what's missing?

We've only really solved the user experience. We haven't solved the other problem I mentioned at the start of this article: privacy policies and terms and conditions so long that you couldn't possibly read and understand it all before consenting. And if you haven't read the terms and conditions, can you actually give consent? In common law countries the standard isn't even consent, but informed consent. So the answer is no.

Until companies write their cookie policies in such a way that you don't have to be a lawyer on a four week holiday just to understand them, the UX part is the only part developers and UX specialists can solve. Let's not rely on store-bought cookie-cutter solutions, but bake something better; something more elegant, less obtrusive, and delivers a world class user experience.

The Functional, Usable, Delightful of... Chocolate

Bryce Miller — Tue, 12 Apr 2022 18:38:44 +0000

Functional

Sure is chocolate!

Usable

Pre-divided into squares that can be easily broken off, and wrapped in foil to keep the chocolate fresh and your fingers clean.

Delightful

Childhood nostalgia in the shape of an egg

The Functional, Usable, Delightful of... Chopstick Rests

Bryce Miller — Tue, 05 Apr 2022 20:10:07 +0000

Functional

A flimsy paper stand. It will last the whole meal.

Usable

A sturdy, re-usable, wooden rest, with neat little grooves for the chopsticks and a spoon.

Delightful

It's a cat! Look at the cute little cat, hanging on to your chopsticks for you! Tickle the cat's little tummy-wummy!

The Functional, Usable, Delightful of... Park Benches

Bryce Miller — Tue, 15 Mar 2022 19:02:31 +0000

Functional

It's a stone cold, cold, stone slab. You can _sit on it,_ although you're just as likely to be lying _underneath it_.

Usable

A back rest, an arm rest, a shaded, sheltered rest. Also, your arse won't fall off.

Delightful

Guys, it's a swing! **It's a swing!** It's got hearts, guys! Look at the hearts! _It's adorable, I want one!_

That Time our Estimates were Accurate

Bryce Miller — Sat, 12 Feb 2022 12:53:50 +0000

Have you ever estimated something exactly right? I have, and it's the greatest boast I as a developer can ever make.

If there is one thing developers are good at it, it's massively over-estimating how quickly we can implement something. Ask any Product Owner, and they will cheerlessly list the myriad times a developer has let them down. Ask a Scrum Master when was the last time one of their scrum teams completed the work they forecast, and they will laugh in your face (or at least they laughed in my face).

Under-estimation is so normalised that people in customer-facing roles have a standard formula for transforming your estimates into something they can tell the customer without losing trust. Ask them, and they'll tell you that they take your number and multiply it by three. That's how unrealistic your estimates are. That's how wildly detached from reality developers like me are. And even that number is often inaccurate.

Estimating is hard

I get it. Estimating is hard. Developers are often being asked to build things we've never built before, and that may never have been built before. We're asked to predict, some time in advance, how long it will take to make something we don't really know how to make yet, and haven't really thought about.

The trouble with programming (especially for web) is that there is great uncertainty attached. How many times have you developed something using Chrome on Windows and found out afterwards that it doesn't work in Safari on iOS (or Chrome on iOS!). How many times have you developed something locally, only to find that it isn't working as expected in the Test Environment (or Production Environment)? How many times has a tester found a bug in your perfect and elegant solution, which, when you fix it, turns it into a complex, Frankenstein's monster?

And these are just the things that can go wrong when you know exactly what you're going to do! How many times has the scope increased while you're in the middle of developing a feature? How many times have you realised something you never thought about only after you've started to build the feature? How many times have you thought you knew what to do, only to find out that actually you can't do it, and it's a lot more difficult than you thought?

We're to blame as well

But developers can't just blame the complexities of the job. We give a lot of just ridiculously stupid estimates as well. I continuously hear that something will only take "two minutes" - nothing takes two minutes.

Two minutes isn't enough time for you to put the task into the correct column in JIRA, update your develop branch, and make and push the new branch. Your two minutes are up before you've even written a single line of code. You haven't even found the place you need to update, or observed the current behaviour. When you estimate "two minutes", you know that is not realistic. I get that you're trying to say it won't take long, but it's not an actual estimate and it tells me that you don't actually know how long it's really going to take. Add in all the stuff we've just discussed about the complexity of the job and do you still really think it's only going to take two minutes?

Even the slightly more realistic "half an hour" is a bad estimate.

Sure, things like changing the colour of something, or updating a text can take half an hour. Half an hour is the minimum estimate you should make, and you should make it for the absolute minimum effort tasks. The problem with estimating “half an hour” is that it's the same as estimating "two minutes" - you haven't actually thought about the task and what's involved. You've just shoved your finger in the air and felt the breeze. This is not an estimation method that will give you accurate estimates.

We need to accept that we're bad at estimating. We need to accept that the data on JIRA that shows us failing to complete a sprint time after time is a reflection of our own estimation abilities. The excuse you come up with in your retrospective each time for why you didn't deliver may be correct on the surface, but the fundamental problem is with how you estimate. Unless you realise that you're bad at estimating, you won't actually change anything.

For some people, accepting that they are bad at estimating isn't actually enough. For some people, being bad at estimating is just a sign that they should give up on estimating altogether. Unwillingness to improve doesn't solve the problem. Your product owner needs good estimates, your sales team needs good estimates, your support team needs good estimates, and ultimately your customers need good estimates. I cannot imagine any other aspect of work where, having discovered you're not good at it, you can just refuse to try and expect it to be OK.

Related to refusing to estimate is the belief that you will get better at estimating with time. On the surface, this appears to make sense, and certainly I believed it for a while - you get better through practice, so the more you practice estimating, the better you will get, right? Disappointingly, no. I have seen developers who not only have decades of experience programming, but decades programming the same exact programme, who still give estimates that are way off. This is a great example of the difference between practice and deliberate practice. If you make your estimates by sniffing the air, then it doesn't matter how many times you've done it - you're still just sniffing the air; you won’t improve.

Finally (I'll give us a break after this point, I swear), we have a tendency to forget or not include everything that goes into the task as part of our estimates. There is so much more to any feature than just implementing it. Personally, I am super guilty of this. I've forgotten about testing, accessibility, communication with stakeholders, refactoring code before the code review, refactoring code after the code review, necessary functional creep, unexpected problems, changes due to misalignment, documentation, and so much more!

Fixing your estimates

Let me tell you how my team got better at estimating. First, we accepted that we were bad at estimating. It wasn't actually difficult - the numbers on JIRA speak for themselves. If someone on your team isn't facing up to reality, show them the data from your own sprint management software. The numbers don't lie.

Having established how terrible we were, we made a long-term commitment to experimenting with estimation. In your retrospective, make getting better at estimating something that you want to improve. Know that this isn't a one-sprint commitment, and know that because it's an experiment, it's totally OK to fail, as long as the trajectory is mostly upwards. In fact, you probably will fail the first few times. Then you might do really well, and the next sprint really badly. But it's an experiment. You're finding out what works, what doesn't and that way improving. This is deliberate practice.

There are different ways of improving your estimates. The discussion above may have inspired some methods you'd like to try. One thing we did was to keep track of our estimates, keep track of actual time used, and make a spreadsheet where we could see exactly how much we'd mis-estimated by. This way, we had real, actual numbers which we could use to inform and refine future estimates. If we had a future task that was similar to a past one, then we would know to estimate at least the same amount as we used on the past task.

Something that may be controversial is that we were not afraid to adjust estimates as we learnt more, even if we were in the middle of a sprint. If any team-member thought at any time that a task was wildly underestimated or that we would have trouble finishing the sprint work, then we would have a touch-down meeting, re-estimate the task, and decide what to do: stop the sprint, extend the sprint to compensate, remove tasks from the sprint to compensate. Sometimes, we would call a touch-down, and work out that everything was fine, and this is fine too. It's better to have the touch-down and find out you're on track, than to not and fail again to deliver.

So why have I described this as controversial? Some people think this is "cheating" or "gaming" the system. Some companies evaluate teams according to how much of their sprint they deliver, and bonuses and promotions are given out accordingly. Your team has made a commitment to be judged on delivering certain tasks in a certain time frame, so if you change the parameters, then you're "cheating" in order to "win" the bonus/raise/new title. The point of estimating is actually to give stakeholders a degree of certainty and clarity about when things will be ready, so that they can plan the things they need to plan, and manage customer expectations. Adjusting plans as early as possible, and improving the quality of the estimate is just good communication and builds trust. Your customers would much rather find out that something will be late as soon as possible, rather than find out the day before launch.

The final thing we did was add in extra time to account for the fact that we know our estimates will probably be wrong. This may be termed "uncertainty" or "contingency" or "slack", but whatever you call it, the point is to anticipate unexpected events, and anticipate the things you couldn't think of. Every sprint I've worked something unexpected has happened, and we've blamed failing to deliver on that unexpected thing. Even if it's true that losing two developers to a crisis is what made us fail, we can mitigate failing to deliver by having this extra time built-in. The amount of extra time you estimate should be in proportion to the uncertainty involved in the task. The more certain you are, the less extra time you'll probably need; the less certain you are, the more time you'll need to add on. As mentioned above, this is about providing the best possible estimates to stakeholders, and including an estimate for unexpected events will result in a more accurate picture of how long something is actually going to take. If you don't need the extra time, then just deliver early and enjoy seeing the smile on your Product Owner's face for once.

You could boast, too

Next time you have a retrospective and the Scrum Master asks what you can improve, tell them you want to get better at estimating. Tell them you want to experiment; you want to try a few things to give more accurate estimates. You might get some pushback, but assure your teammates that they won't be required to do anything different at first, and that no-one will be personally singled out. You'll just be building up a catalogue of estimates, and reporting on how accurate they were as part of the next retrospective.

I can't guarantee that doing these things will result in your team giving perfect estimates every time. But your estimates will get better. And as your estimates get better, your estimates will be trusted more. As your communication gets better, the times that you fail will be seen as times of honesty instead of times of deceit. And one day, by the law of averages alone, you will estimate some task exactly right, and you too can then make the greatest boast a developer can make.