Sure, the software has a bug. Software does. Almost always. What is broken here is that it is possible to get stuck in an airport with no possibility of escalating sensibly to a chain of human beings with agency to resolve it. You could have a software process which works 99.9% of the time, and have staff at hand which could solve any solvable remaining issues like this one. They call the Home Office internal hotline, explain the issue, resolve it by manually interfering on the spot (and have a bug filed), and everyone carries on.
Instead, we demand a 100% correct system, and save money on actually having people around who can deal with the edge cases and make sure everyone has a good time. Of course, getting a project from 99.9% to 100% costs a lot of money, because that includes literally all edge cases ever (getting to 100% is as likely as reaching ∞ by multiplying any given starting number by 2 until you reach it), and so it will likely end up being more expensive in budget overruns than the 99.9% plus humans system.
Obviously, politicians must choose for the fictional 100% case, because they can't afford the cheaper 99.9% plus human one.
> A Home Office spokesperson said: “Over 10 million people have already successfully used eVisas to prove their immigration status. ..."
So how many people did not successfully use it? Could be 100 million for all we know. Do they think just throwing out a large number without anything to compare it to is somehow proving something?
It sounds to me like this number indicates broad success.
The rough estimate seems to be that only about two per cent of border crossings use an eVisa anyway (British passport holders don't and non-immigrating visitors don't).
Even over summer that would probably only mean maybe 2.5 million border crossings, so the other uses are not at the border — they will instead be employment/landlord/benefit/healthcare checks using the online systems.
So for example, renting a new property, starting a new job, applying for a new benefit, or needing non-emergency healthcare etc.
How? How can a single absolute number indicate broad success? You can't read from it if failure rate is 1% (completely unacceptable) or 0.01% (probably acceptable as long as problems are quickly mitigated). Also what do they even count as a success? If someone is stranded somewhere for a month and the problem then gets mitigated, they did eventually successfully use it, didn't they?
The strongest indicator that the system is riddled with issues is in what they did not say. If they had less than 100 cases where the system initially failed and the issues got resolved within a few hours I'd bet they would brag about it.
> Do they think just throwing out a large number without anything to compare it to is somehow proving something?
Welcome to the last 20 years of UK public policy communications. Politicians know that people do not question big numbers or have the skills to put them in context.
I remember the May government shouting that "more children go to schools rated good+ by Ofsted than ever before". Me and you would say, well, there's more children alive than ever before, so it's hardly an achievement.
I've had issues with this e-visa implementation and was told I could not board flights.
As a someone in tech, I feel this a classic case study of how NOT to roll out a release and develop a solution.
The release was chaotic, none of the airlines staff were trained on how to use this. So they still insisted on the expired cards and then picked on the expiry dates.
Next, almost everyone makes you generate a verification share code in front of them by logging into the e-visa website even if the rules say I can print it out and just use the code. It takes a few minute to get on the website and generate one.
This solution assumed that everyone has access to a smart phone and a good wifi connection to make this work.
> Whoever built this didn't test it on the ground.
God this happens all the time. Software written by people that don't use the software themselves. It has happened to me so many times, I come across a piece of software with weird bugs or interactions that would be immediately fixed if the developer just spends 5 minutes using the software like an end user would. Dogfood all the things!
> Software written by people that don't use the software themselves. It has happened to me so many times, I come across a piece of software with weird bugs or interactions that would be immediately fixed if the developer just spends 5 minutes using the software like an end user would. Dogfood all the things!
My experience is completely contrary: developers typically do care deeply about such things. The problem is rather that very commonly managers actively disallow these poor developers to apply their diligence to the software that they develop.
I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI").
Don't do that. Rather fight the people who are really responsible (who are often (project) managers or Scrum masters).
"I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI")."
Paranoia?
There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it. Has nothing to do with devs who are blocked by management.
>
There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it.
Note that in my comment I wrote nothing about dogfooding - for a very good reason:
It is well-known that dogfooding leads to software that has rather few bugs, but also dogfooded software often shows a tendency to be "biased towards programmers and power users". So, there often exist very good reasons if the programmers actively don't dogfood their software, and rather trust someone else (who is very trusted by the programmers) that the workflow that the programmer should implement does make sense for the user, even though most programmers would implement this aspect very differently.
Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-)
>
Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-)
Lessons that you should be taking away is rather:
- Every tool that possibly might be good for improving the quality of the software is just a tool that can also cause harm if used in a wrong way.
- Deeply distrust keynote speakers and thought leaders who sell their method for improving the quality of the software or improving software development as a panacea. Every method is only useful under specific circumstances and is harmful of used wrongly. Keynote speakers and thought leaders who don't go into details when their methods are helpful and when they are harmful are simply scammers and snake oil salesmen and should be called this.
Well, I think you should always do that(if your constraints let you). But working with actual users and valuing their input is to be prefered of course. Every user can be a power user if you give them the tools so they empower themself.
So did we, although we were in the end able to persuade them to let us board the flight by showing a screenshot of my friend's eVisa status from the UK government website (so secure!)
To be fair to the airlines here, if they get it wrong then the UK government fines the airline. This is why they are pretty risk averse, and also why I'm surprised that the screenshot worked.
I bet you 100% it was built not by in house team but farmed out to an agency for £££££ millions. They will have been saying in their case studies some absolute nonsense about how they saved the government millions rather than burned loads of money too.
It'd be lovely if articles like this named the people responsible for actually building the systems. It's almost certainly never a government department.
They'll have paid one the many software/technology companies to build this thing. Who will be hiding their shoddy crap behind their client (the government department that paid for it). There are some patterns that I'm sure would start to arise from naming the consultancies that are churning out crap.
Actually this was developed by the government, in a meaningful sense, but it seems like it's Entrust (more or less inevitably) and Accenture who are the outsourced parts.
So basically both US multinationals (Accenture have a Dublin HQ as a fig leaf)
I have identical twin boys - when signing up for a bank account app and while completing all the associated hoops for ID, the second to do it got the rather dystopian error message 'an account has already been registered with this face'
I wonder how it's possible they didn't think about this problem. Considering everyone involved in building this feature, not a single person thought about the possibility of twins or simply people who are very alike? Also, can't people open multiple accounts?
I imagine that it probably went like this "what about identical twins?" / "Don't worry about that for now, we'll solve for it before we go live, but it's not in this milestone". Then someone pulls rank and decides the product is "good enough, we can't wait for all bugs to be fixed" and gets it deployed.
Just look at the "falsehoods programmers believe about ..." articles that pop up from time to time. There are plenty of complexities in the real world that people either don't know about, aren't front of mind when they are tackling a larger problem, or simply don't want to deal with in the here and now. Lost knowledge and new problems are part of the reason why programmers are discouraged from rewriting software from scratch and why businesses in general are hesitant to replace legacy systems that still work.
Based on my experience I assume someone mentioned the risk, others said it’s unlikely and only a small percentage, that we should care about the 99% for now. Then the issues isn’t revisited until someone impacted complains enough.
p99 is ok for web stuff, not for systems that impacts people in their life, but I’ve seen too often things being dismissed because they are edge cases (which becomes an actual real issue at the scale of a country of course)
Because it probably does the dystopian tracking well enough, they don't care if it's not 100% accurate. Edge cases in the new world have no recourse, citizen.
What is strange is that even the best face recognition algorithms have false positive. So surely they must have planned for two unrelated customers resolving to the same embeddings.
I suspect this case has origins less to do with the programming itself, and more to do with UK bureaucracy just not giving a shit, as with the post office scandal where authorities, including the legal system, blindly believing in the outsourced systems led to hundreds of false prosecutions and thirteen suicides (https://en.wikipedia.org/wiki/British_Post_Office_scandal).
Sure, the software has a bug. Software does. Almost always. What is broken here is that it is possible to get stuck in an airport with no possibility of escalating sensibly to a chain of human beings with agency to resolve it. You could have a software process which works 99.9% of the time, and have staff at hand which could solve any solvable remaining issues like this one. They call the Home Office internal hotline, explain the issue, resolve it by manually interfering on the spot (and have a bug filed), and everyone carries on.
Instead, we demand a 100% correct system, and save money on actually having people around who can deal with the edge cases and make sure everyone has a good time. Of course, getting a project from 99.9% to 100% costs a lot of money, because that includes literally all edge cases ever (getting to 100% is as likely as reaching ∞ by multiplying any given starting number by 2 until you reach it), and so it will likely end up being more expensive in budget overruns than the 99.9% plus humans system.
Obviously, politicians must choose for the fictional 100% case, because they can't afford the cheaper 99.9% plus human one.
So how many people did not successfully use it? Could be 100 million for all we know. Do they think just throwing out a large number without anything to compare it to is somehow proving something?
It sounds to me like this number indicates broad success.
The rough estimate seems to be that only about two per cent of border crossings use an eVisa anyway (British passport holders don't and non-immigrating visitors don't).
Even over summer that would probably only mean maybe 2.5 million border crossings, so the other uses are not at the border — they will instead be employment/landlord/benefit/healthcare checks using the online systems.
So for example, renting a new property, starting a new job, applying for a new benefit, or needing non-emergency healthcare etc.
The strongest indicator that the system is riddled with issues is in what they did not say. If they had less than 100 cases where the system initially failed and the issues got resolved within a few hours I'd bet they would brag about it.
Welcome to the last 20 years of UK public policy communications. Politicians know that people do not question big numbers or have the skills to put them in context.
I remember the May government shouting that "more children go to schools rated good+ by Ofsted than ever before". Me and you would say, well, there's more children alive than ever before, so it's hardly an achievement.
As a someone in tech, I feel this a classic case study of how NOT to roll out a release and develop a solution.
The release was chaotic, none of the airlines staff were trained on how to use this. So they still insisted on the expired cards and then picked on the expiry dates.
Next, almost everyone makes you generate a verification share code in front of them by logging into the e-visa website even if the rules say I can print it out and just use the code. It takes a few minute to get on the website and generate one.
This solution assumed that everyone has access to a smart phone and a good wifi connection to make this work.
Whoever built this didn't test it on the ground.
God this happens all the time. Software written by people that don't use the software themselves. It has happened to me so many times, I come across a piece of software with weird bugs or interactions that would be immediately fixed if the developer just spends 5 minutes using the software like an end user would. Dogfood all the things!
My experience is completely contrary: developers typically do care deeply about such things. The problem is rather that very commonly managers actively disallow these poor developers to apply their diligence to the software that they develop.
I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI").
Don't do that. Rather fight the people who are really responsible (who are often (project) managers or Scrum masters).
Paranoia?
There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it. Has nothing to do with devs who are blocked by management.
Note that in my comment I wrote nothing about dogfooding - for a very good reason:
It is well-known that dogfooding leads to software that has rather few bugs, but also dogfooded software often shows a tendency to be "biased towards programmers and power users". So, there often exist very good reasons if the programmers actively don't dogfood their software, and rather trust someone else (who is very trusted by the programmers) that the workflow that the programmer should implement does make sense for the user, even though most programmers would implement this aspect very differently.
Lessons that you should be taking away is rather:
- Every tool that possibly might be good for improving the quality of the software is just a tool that can also cause harm if used in a wrong way.
- Deeply distrust keynote speakers and thought leaders who sell their method for improving the quality of the software or improving software development as a panacea. Every method is only useful under specific circumstances and is harmful of used wrongly. Keynote speakers and thought leaders who don't go into details when their methods are helpful and when they are harmful are simply scammers and snake oil salesmen and should be called this.
To be fair to the airlines here, if they get it wrong then the UK government fines the airline. This is why they are pretty risk averse, and also why I'm surprised that the screenshot worked.
Back in my day, visas were handled by init scripts. And we like it that way!
They'll have paid one the many software/technology companies to build this thing. Who will be hiding their shoddy crap behind their client (the government department that paid for it). There are some patterns that I'm sure would start to arise from naming the consultancies that are churning out crap.
So basically both US multinationals (Accenture have a Dublin HQ as a fig leaf)
p99 is ok for web stuff, not for systems that impacts people in their life, but I’ve seen too often things being dismissed because they are edge cases (which becomes an actual real issue at the scale of a country of course)
Jokes aside, when helping someone I know return to the UK, I wasn't sure if I have a stroke or someone who wrote the guidance had a lobotomy.
Clear as mud.
https://spectator.com/article/the-british-dream-by-david-goo...