> That's really a textbook example of software projects going horribly wrong. It's often a good idea to take a step back and analyze whether you're overcomplicating things.

The question is what to do about it. Simply taking a step back and analyzing is not enough. Most of us have been on the projects that were overcomplicated and knew they were overcomplicated and knew a simpler solution and yet didn't have the power to do anything about it. The ultimate power is to be able to walk away form the project but how many people can afford that?

So, I believe the problem is not technical but rather socio-economic.

I am not sure how to solve it.

I've been in projects like this, where I asked 'shouldn't we show this in human readable text?" The response would be that everyone knows the codes, so no. In those cases it was the client deciding a less than optimal solution even though I as a developer proposed something that, I think, was better.

Next time you can cite the Notre Dame fire

Or the cost of a support call when a clear and human readable error would likely allow the user to help himself or be patient.

Beer testing has never looked saner than when faced with monstruosities like that.

Been using it since I learned of it on HN and it's impressive the number of times it makes you take a step back and realize you were getting lost between you and yourself.

"Beer testing" - usability testing after consumption of quantities of beer??

Take your project, whatever it is, on a laptop. go to the nearest pub or bar, not the drunken kind but the calm almost Starbuck like.

Find someone in the range of who your average user is, and offer to pay them a beer if they agree to use your interface to do some simple task on it for five minute while you take notes and record the screen. It's a sort-of game for them, short enough that it won't be a hassle, and they get a free beer out of it 'it's inexpensive for you and will reveal some obvious issues faster than a team of dedicated qa tester can ever hope to be.

Here it would be a simple "here is the alarm you get, identify what is the problem and where it is". Given parent post, 5$ and ten minute of beer testing would have told them how terrible it is.

Works fine with group too, ensure one person is the dedicated user, and offer to pay their drink tab.

Be ready to engage with them if they have question and do not be timid about keeping their drink coming if they so desire, as long as they provide valuable input.

It's so obviously stupidly simple, but the result are insane, it's very cheap and you get a perfect case of "how will average person x understand and deal with my software in that situation".

(first learned of it on a hn post years ago, adopted it for fun, kept it because it works too well)

Apparently, it is a different thing.

What I thought of was:

- State the problem

- Get drunk

- Find an answer

- Sober up

- Study the problem again

- If you came to the same conclusion as when you were drunk, you are OK.

Basically how the Persians used to debate: "In Herodutus’ discussion of the Persians, he wrote (Book I, chapter 133) that they decide upon important issues by first getting drunk. Once drunk, they start the debate and then come up with a decision. The next day when they are all sober, they decide whether they want to go through with the decision made. If yes, they go through with it. If they decide against it, they drop it and go back to square one which starts by getting drunk again."

[1] https://historydaily.org/drunks-debates-ancient-persia

What is beer testing?

Take your project, whatever it is, on a laptop. go to the nearest pub or bar, not the drunken kind but the calm almost Starbuck like.

Find someone in the range of who your average user is, and offer to pay them a beer if they agree to use your interface to do some simple task on it for five minute while you take notes and record the screen. It's a sort-of game for them, short enough that it won't be a hassle, and they get a free beer out of it 'it's inexpensive for you and will reveal some obvious issues faster than a team of dedicated qa tester can ever hope to be.

Here it would be a simple "here is the alarm you get, identify what is the problem and where it is". Given parent post, 5$ and ten minute of beer testing would have told them how terrible it is.

Works fine with group too, ensure one person is the dedicated user, and offer to pay their drink tab.

Be ready to engage with them if they have question and do not be timid about keeping their drink coming if they so desire, as long as they provide valuable input.

It's so obviously stupidly simple, but the result are insane, it's very cheap and you get a perfect case of "how will average person x understand and deal with my software in that situation".

(first learned of it on a hn post years ago, adopted it for fun, kept it because it works too well)

> Often when working on a concept, you're too deep in to see the simple solutions anymore.

I've seen at least as much stakeholder or designer (backed by stakeholder) ego keeping UX-harming crap in, while plenty of people on the project are very aware of it, despite its being pointed out to them repeatedly. Sometimes they even make you spend more time (money) doing things the wrong way. It's bizarre.

TBF, often times people at the top are there as the result of rejecting others' advice many, many times, and so rejecting advice does not set off alarm bells to them the way it might to most other people.