Hacker News new | past | comments | ask | show | jobs | submit login

The part interesting for us:

“The fire warning system at Notre-Dame took dozens of experts six years to put together, and in the end involved thousands of pages of diagrams, maps, spreadsheets and contracts, according to archival documents found in a suburban Paris library by The Times.

The result was a system so arcane that when it was called upon to do the one thing that mattered — warn “fire!” and say where — it produced instead a nearly indecipherable message.

The message (assembled):

“Attic Nave Sacristy.” “ZDA-110-3-15-1” “aspirating framework”




The article makes it clear that the fire alarm system did warn "fire":

>The employee monitoring the smoke alarm panel at Notre-Dame cathedral was just three days on the job when the red warning light flashed on the evening of April 15: “Feu.” Fire.

and

>Finally, the guard radioed the fire security employee to call the fire department. It was 6:48, 30 minutes after the first red signal lit up the word “Feu.”

The message specifying the location of the fire could have been more clear, but the fact that the fire alarm was going off was clear. When you see "Feu" flashing red on the alarm panel, the correct course of action is obvious. The greatest failure was that the guards tried to go find the fire, wasting 30 minutes, instead of just calling the fire brigade immediately.

If a tsunami warning is being sounded, would you go down to the beach to try to spot it first, or would you run for the high ground?

If a warning of a bombing came, would you go outside with binoculars and try to spot the planes first, or would you run down into the air raid shelter?


That probably depends on the training and the frequency of false alarms.

If air-raid sirens (which we do have here in Switzerland) would start sounding, nobody would seek shelter, because everyone would consider an attack too unlikely.

Of course, in retrospect, it would have been better to call the firefighters first. But to make such consequential decisions three days into a new job requires proper training and clearly defined procedures.


> The greatest failure was that the guards tried to go find the fire, wasting 30 minutes, instead of just calling the fire brigade immediately.

This is actually standard procedure in many places. Security guards often have x minutes to see if it's a false alarm:

* https://gps-securitygroup.com/the-role-of-security-guard-reg...

Non-residential buildings are often charged for false alarms, so the landlord may wish to first confirm if the fire brigade is actually needed. If you work in an office tower, or live in an apartment or condo, you'll often have multi-stage fire alarm system: you don't actually evacuate unless either (a) it's a confirmed real incident, or (b) the confirmation timeout has been reached.


Given that we now know that it was well-known to experts and people in charge that the attic was a tinderbox, and that the roof and vaulted ceiling would prevent firefighters from spraying water to extinguish a fire in the attic, and that there were no sprinklers installed there, it would make sense to treat any fire alarm as an actual emergency, as the consequences of even a slight delay in the event of a real fire were high.


> it would make sense to treat any fire alarm as an actual emergency

They were using a industry standard operating procedure (SOP) in a non-standard environment. Sometimes it's hard to know the situation is non-standard until after the fact.


Makes you wonder if the millions of euros and years (decades) of construction delay caused by the fire alarm system at the BER airport will, in the end, be worth the effort [0].

[0] https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Con...


That's an astonishing list of failures.


> An 11 October 2016 committee session found that motors used to open and close windows do not operate above 30 degrees Celsius and they need to be exchanged. Three thousand smoke detectors went missing, but were later found. Technical issues involving the electric doors became public on 18 January 2017. It was discovered that 80% of the doors would not open, which created concerns around venting of smoke in a fire. The sprinkler system has sustained failures in the south pier. The sprinkler heads were replaced for increased water flow, but the pipes are too thin to withstand the increased water pressure. The roof needs to be opened and the pipes will get exchanged. On 5 March 2017, the transformer station exploded.


Imagine how many more they'll find when they throw actual human passengers at the place.


Wonder why the system didn't call the fire department itself. Why bother with the human element of the guard at all? This is Notre Dame we're talking about.


Most major monuments in France have resident firemen, for this reason.


Too many false alarms?


One sensor detecting a fire can be a false alarm. More than one sensor detecting a fire is very rarely a false alarm, and really ought to call the fire department.


Most automatic alarms are false. As far as I remember it's more than 90% in Denmark.

Accepting an error rate at 98% for Notre Dame should be a no-brainer.


There's a cost for deploying firetrucks, both in dollars and opportunity cost -- when you send 5 trucks to Notre Dame twice a week just in case the alarm is real this time, those trucks and firefighters aren't available to respond to a real fire


I dunno. Do you want fire trucks sirening through the city blocking traffic every day?


That's already a fact of life in every large city I've ever been in.


Do we know this to be true? If the alarm is going off for a good solid few minutes it might be worth a checkup.


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. Often when working on a concept, you're too deep in to see the simple solutions anymore.


> 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.


The thing is: usually there's a fire plan - firefighters arrive at the building, read the code and look it up in the plan where exactly the trigger (or inlet for the aspiration tube) is. They do this insanely fast as they have been trained for this - while that security guard and the overtired technician were not.

This is a lack of training and a procedural failure - the usual configuration/process is that any alarm either automatically calls firefighters/police or via procedure the guard manually does this - immediately, not after 30min.


It's a very, very vague error, and totally understandable that the new guard sent his colleague to the wrong place.

We'd expect a phrase to provide more granularity: (or YYYY-MM-DD), and as such, you'd read it exactly as: fire in the attic of the sacristy. The "nave" text is a bit weird, as the sacristy doesn't have a nave, but at the same time, the nave doesn't have a sacristy.


In the article, it says that the area was divided into four zones — my reading of this message: fire in the nave attic in sacristy zone. The bunch of numbers is an id of fire detector.


From the article: "First it gave a shorthand description of a zone — the cathedral complex was divided into four — that read “Attic Nave Sacristy.”"

So the entire zone is called "Attic Nave Sacristy", and from that all you know is that there's apparently a fire somewhere in that zone -- could be on the floor of the nave, could be in the cathedral attic, could be somewhere in the sacristy building (even in the attic of the sacristy).

The irony is that you've made a version of the same mistake that either the security employee or the cathedral guard made -- assuming a specific location within that zone. Yours ("the nave attic") happens to be correct; one or both of them assumed it was "the attic of the sacristy building".


Attic nave sacristy is a location


But the nave doesn't have a sacristy, and the sacristy doesn't have a nave.

Sacristy seems to give the location of where in the nave, which considering that the cathedral is cardinally aligned, is a rather poor choice.

"Attic nave south" would have been a perfect description.


It really meant something more like "the part of the cathedral complex containing the cathedral's nave, the cathedral's attic, and the sacristy building".

The real problem was that both the main cathedral and the sacristy (a separate building adjacent to the cathedral) had attics; either the security employee got confused and told the cathedral guard to check the sacristy's attic, or the guard got confused and decided to do that.


Perfect unless the guard didn't know which way was south and went to the wrong place. Then maybe the HN elites would be saying, "why not use the location of something unambiguous instead of 'south', like the sacristy building" ;-)


As someone who has written software that interprets signals from fire alarm panels, I can tell you that it's decipherable if you're trained on the panel model.

I suspect the employee, having been on duty only a few days, was not.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: