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).
Slightly off topic, but I strongly believe that the rise of "professional" CEOs was the beginning of the end for quality products and services. Before, you were generally an expert in your particular domain and was invested in solving the customer's problems.
I recently worked for a company in the cybersecurity space who hired a CEO who had neither IT, nor security, nor cybersecurity experience...
... I saw last week that they just had their (latest) 25% headcount reduction, followed by their (latest) "executive offsite retreat" to pat each other on the back and figure out what they'll do between now and the next one.
>
If CEOs were legally required to regularly use their own products as an ordinary customer, the world would be a better place.
This is like the argument "developers should use the software that they write" (dogfooding).
Let me give one example: the previous person who designed and developed the previous version of the software which I now work on really could use "his" program insanely well. The problem was rather that he was basically the only person who really did understand it sufficiently well to not to be triggered by problems other users had. Yes, a huge part of my job is over the years to turn this piece of software into something that is understandable by other people, too,. :-)
Sometimes it's so painfully obvious - that you can turn a piece of crApp into something that works well by just modifying yourself or the situation so you're following the path that the developers do.
Bugs caused by edge-cases in data are exactly the types of bugs that are usually not caught in smoke tests.
In my experience with large regulated systems, the engineers writing the software don't have the expertise to even know what the correct specifications should be in most cases, and especially in edge cases. Software engineers are not experts in customs and immigration legal requirements and would be relying on heavily on guidance from experts in those fields to determine the proper rules to apply.
In my experience with bugs like this, it is usually scenarios that all parties involved in the design did not consider... especially when implementation is rushed due to tight deadlines.
My experience is rather that the typical software developer is ultra-cautious, and will always leave some loophole open in the workflows of the software in case something unexpected occurs that could not be foreseen, in particular considering the high stakes that are involved when something goes wrong with the software: I am not exaggerating when I claim that if something like what is is described in the article happens to some people, they often will start praying to their god that he kills the responsible people for this bug in the software in the most brutal imaginable way. Software developers know that.
Other stakeholders typically don't apply such caution.
Yeah, the typical way to fix an unforeseen data issue is that someone is empowered to update the data manually on the backend which sounds like exactly what happened. That being a slow process is not a software engineering issue, but an organizational issue.
Yes, but the end users are not (yet) code, they are humans. In order to fix the data in the system, the organization will have to place a human behind the keyboard with the authority and ability to change the data from incorrect to correct.
> will have to place a human behind the keyboard with the authority [...] to change the data from incorrect to correct.
Whether such a person has such a permission in the system or whether the permission system of the software can actually model this is a work process that has been turned into code.
"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.
No, while the patent poster expresses their opinion quite strongly I have more than once encountered product managers and project managers who get almost personally offended when developers try to use their brains and don't just blindly implement incorrect specifications. If they have a vendetta I don't know but they clearly hate having to depend on engineers with free will.
That said I have also encountered lazy engineers who are totally fine with implementing obviously broken software, those are a perfect match for the egotistical product manager.
Shoot where I am at, it can also change on a week by week basis. This week, I can get away with some shit to improve the UX and depart from the mock up. Next week, if the feature doesn't look and function just like the mock up says that was handed in the case, I'm in trouble. No matter how bad it is.
>
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 are 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.
I write software that we use daily, and we still find things in the wild that we would never find until the thing in the wild occurs. Luckily for me, none of these found in the wild issues interfere with people's lives and just means a file gets completed a little closer to the deadline. I'm fine with that.
Not sure if this situation falls under the "push it to prod and let the users QA it" or if this is truly edge case situations. It's easy to bash and make fun of, but I've been in the trenches of catching what is an edge case for most people but run of the mill for those providing the data to me.
I’ve been in the weird situation of working in a startup where the founder doesn’t use their own product. Needless to say I got out of there pretty quick.
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.
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.
Also for years prior it was explicitly said share code were _not_ to be used for travels and that airlines were not allowed to ask for them.
And now that they are the airlines do not have the system to check them so you have to print the webpage which also explicitly said should _not_ be used instead of the share code...
I hate these alcohol fueled company parties. Every one of them I've been too (at-least 7) ended up with 1 or more people being fired because they can't handle their drinks. I avoid them of go back to my hotel room after they open up the bar.
There more things in a pull request other that just reviews. It can run a build pipeline and give feedback, provision test instances to run quick tests.
It can also be used to add context and have a conversation around the why's before merging. And yeah while it's not the main purpose we've caught a lot of bugs too just from the statically reviewing code.
I switched from Claude code to the GitHub copilot app recently. Since our repositories are hosted on GitHub I find the copilot app better integrated for the PR workflow with PR management available in the app. I don’t think I miss any of the features of Claude code I never thought I would make the switch but copilot upped the game.
Also it became very hard to convince management to keep both Claude code and GitHub Copilot enterprise licenses.
I am learning music. I used codex to create a native metronome app, a circle of fifths app, a practice journal app. I try to build a native app alternatives.
I have no plans of publishing them or making the open source, so it will not be a part of this metric. I believe others are doing this too.
I think this is what makes traitors such a popular series - absolutely everyone things they can tell when someone is lying, but the truth is it's really difficult. Especially if someone is a stranger, it's next to impossible to separate what might be possible tells from what might just be their personality.
I don’t think it’s bad on its own, but from my experience, the rollout can be messy and lock people out. Aadhaar in India had long registration queues, biometric issues, and banks making it mandatory. Even in the UK, the digital residency permit switch caused issues at border control.
It’s hard not to be overwhelmed by the Sagrada Família — it feels less like a building and more like a living organism stretching toward the sky. Makes Barcelona along all that it already offers a beautiful city to visit.
I also feel the tragedy behind its beauty. From what I've read, Gaudí dedicated later part of his life completely to it and he died poor and unrecognised, hit by a tram and mistaken for a beggar.
Not a fan of the new Safari design. I used to like it for its compact and minimalist look, but now the address bar and tab bar feel like they take up more space than they should.
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.