Hacker News Reader

Comment by pascalmemories | Hacker News Reader

You read the story quite differently from me.

I don't think he changed how they operated at all.

He gave them a program which highlighted the most critical calls for most urgent attention.

That's EXACTLY how 911 operators are SUPPOSED to operate.

CAD systems are supposed to do that but it can be difficult to properly do that when lots of calls come in - and when a really critical calls does come in, it frequently is reported multiple times leading to duplicates as other operators key it simultaneously. Many CAD systems will not automatically connect them and require intervention. It sounds like metrics like this and others were being used to automatically suggest critical calls.

He helped them do their job, in the way they should do their job, but in a way which was efficient and directly led to better, and possibly life-saving, outcomes to residents of Seattle.

But you are suggesting he should have been fired ?

[edit:spelling]

View on HN

I don't know that much about 911 dispatch centers, but highlighting calls as more important definitely sounds like a change in the operation procedures of the center, and definitely sounds like it should have been approved first.

Can you imagine the PR nightmare the captain would have had to deal with if someone died or was severely injured because one of the calls wasn't highlighted when it should have been? I think the captain was right here.

PR nightmare... can you imagine the legal fallout? E911 operators are trained to treat every call as an emergency because that's what E911 is for. I don't think they can prioritize them either correctly, for example, how do you treat a domestic abuse call where the victim is talking in very abstract or nonsensical terms, for example, "I'd like to order a pizza?" in order to avoid alerting the abuser who might be a few feet away. Assign it a low priority and you risk getting someone seriously hurt or killed.

Yes, it's how they are supposed to operate. But what makes a call "high priority?" Are 911 operators actually working off this list? What happens if the program fails; what's their back up plan? What happens if there's a bug in the program, is he going to fix it or will he have lost interest? Are their regulations about maintaining a log of what was displayed in case of a lawsuit? Where's the source code, what happens if this guy resigns 3 months later?

There are so many questions that need to be answered and thought out. I'm sure it was a good idea and probably should have been pursued.

As for firing him, it's not because of this program. It's because of the unprofessional way he reacted to criticism. The article says he actually had to be escorted out of the building. I would completely expect someone to be fired for that, especially if the SPD really where such a hostile environment to new ideas.

I'm not saying he HAD to be fired, but the article seems to take the tone that the SPD was being unreasonable. It would seem they where being very accommodating even in light of his childish behavior.

Not knowing much of anything about 911 dispatch, this would be my short list of criteria for elevating call priority:

  - Caller has indicated a situation wherein a delay in the arrival
    of emergency responders may contribute to more serious harm
    being done in the caller's vicinity
  - Caller has indicated a situation wherein a delay in the arrival
    of emergency responders may result in them being unable to
    render any meaningful assistance
  - Caller has described a situation that may require multiple
    units of responders or multiple types of responder to bring
    under control
  - Caller is unable to respond to the dispatcher

I would also assume that the normal method for elevating call priority would be for the dispatcher connected to the call to click a button or use a keyboard shortcut. I further assume that this priority was usually indicated by something like an asterisk in a table column, or even something like appending "-PRIORITY-" to the end of a string. The idea to highlight the entire row in a GUI for a priority call would not be inherently risky, other than the possibility that an extremely incompetent person might set Visible="Collapsed" or something.

But I don't know any of the details. It may well be that the 911 dispatch software is so badly written that business logic is present in the view layer. I have seen it before in software used by government entities. The code is so brittle that everyone is deathly afraid of doing anything to it unless something is already clearly broken.

I think you're missing a lot of the bigger picture that the comment you're replying to had.

When you work on governmental projects, a lot of requirement are legislated in. 10 years ago there might have been some incident that caused the city of Seattle to enact an ordinance stating that all escalations had to be logged. Perhaps that came through the state legislature. That's not some requirement that you can 'get to later' or 'iterate' in. It's technically 'against the law' to deploy code without that requirement satisfied.

I'm not sure if the outcome of his meeting with the captain would have resulted in his banishment from working with the 911 operators if he didn't blow up at them. But, had one of my developers coded a small web app and deployed it without telling anyone, I'd be miffed, if he did it to another group without telling that group's manager, I'm sure I'd get talked to by that manager.

If that developer had gone in and changed a mission critical piece of code without telling anyone, or getting the code reviewed, if it worked, they'd get a stern talking to, if it broke the system, they'd be on a PIP.

The level of detail in the article is insufficient for us to be arguing over this.

But having worked on government software projects before, I am aware that some fraction of them are dominated by office politics and contractor ass-covering rather than any desire to provide some benefit to the public in exchange for its tax dollars.

Absent any additional facts that would contradict, my default assumption is that peon employee was reamed for making his superiors look bad, rather than any genuine technical or legal limitation.

Here's what I saw in my head.

  Dev: Mind if I watch how you use this program for a bit?
  911: Nah.  Slow today.
  Dev: Hey, what's that mean there?
  911: That's a priority call.
  Dev: What's the difference.
  911: Real emergencies, instead of cat stuck up a tree type calls.
  Dev: People actually call 911 for that?
  911: You have no idea.  People call when their drive-through order is wrong.
  Dev: Wouldn't it help if those were, like, highlighted, or something?
  911: Yeah, but they told us it couldn't be done on this system.
  Dev: I bet I could do it.
  (30 minutes later)
  Dev: See, look.  I knew I could do it.
  911: That's great!  Go show this to Mgr!
  Dev: Hello Mgr, look what I did!  The dispatchers love it!
  Mgr: You're a loose cannon, Dev!  Turn in your badge and gun right now!
  Dev: Wait... what?
  Mgr: You have to follow the rules in this department, Maverick.  Lives are at stake!
  Dev: I literally feel like you are speaking a different language right now.
  Mgr: If you so much as pick your own nose without approval, your ass is mine.
  Dev: I'll just be going now, thanks.

In this fictional scenario, the boss isn't mad because the dev changed the system, but because he had already told people that what was done was impossible, or had to wait years until the next major upgrade version. The end-users discover that there is a layer of resistance between them and the developers, which exists only to resist change and make it more expensive. When someone sees that a feature they have previously been denied can be implemented by some punk kid the same day, it undermines the authority of management.

And it interferes with that deal where management enters the feature request on behalf of the end-users, the crony-packed development contractor quotes eight weeks and $50000 for it, and some punk kid still does it in one day, but with a bunch of other people skimming off the top at taxpayer expense. That gets rolled into a periodic upgrade package that the end-users are conditioned to fear, because it always interferes with their work for at least a week.

That's just the stuff I make up in my head when I don't know the whole story, because that's what matches up with my anecdotal life experience.

He helped them do their job, in the way they should do their job, but in a way which was efficient and directly led to better, and possibly life-saving, outcomes to residents of Seattle.

How did it determine call priority?

How did it order priority?

How was the ordering presented?

Was the computer system itself modified, or was it running on a parallel, out-of-band system?

Did the call system computer need to run new, untested and unverified processes?

Did the call system computer need new untested dependencies installed?

Was the deployment procedure for the new system worked through with IT? Could IT restore a system with the new call prioritization display on it?

What are the security boundaries for the new call system with the prioritization display? Is the threat model the same? Has he assembled a threat model? Does he care? Does he know what a threat model is?

But you are suggesting he should have been fired ?

On the spot.

Are all of your questions rhetorical? Or would the answers to them change whether you think Clemans should have been fired on the spot? Would it matter that, as badly as Clemans may have behaved, he was significantly better than the other IT staff that worked in the center?

Just based on the post, I don't expect its author to even know enough to ask any of the questions you have. Why are you assuming the worst? Is there anything specific that makes you think Clemans was irresponsible?

Are all of your questions rhetorical? Or would the answers to them change whether you think Clemans should have been fired on the spot?

If any of those answers were any different than what I expect they are, it would have required the participation of the larger IT apparatus at the SPD. In which case, his boss probably would have been suspended as well.

Would it matter that, as badly as Clemans may have behaved, he was significantly better than the other IT staff that worked in the centre?

better? That is positively dripping in thoughtless elitism.

But for the sake of argument, better than the other IT staff who worked with their superiors to define solutions to requirements rather than railroading their pet ideas through? Better than the other IT staff who understand the extraordinary intolerance the public has for acute and sudden failure in public agencies? If this clueless cowboy had brought the 911 dispatch system down, heads would have rolled. Clemens can waddle off and get a new private sector job, but what about everyone else caught up in the mess?

The hissy-fit he threw when he didn't get his way? Why, based on this article, would you ever give Clemens the benefit of the doubt? Especially when he's pitted against a public servant who has most likely risked his life on more than one occasion in the line of duty?

Here's an important question: was the list of keywords he was using to highlight the calls in any way skewed such that it would, intentionally or not, result in one group of callers being prioritized over others? This could lead to accusations of racial bias.

> He gave them a program which highlighted the most critical calls for most urgent attention.

Sounds like he changed how they operated to me

Calls are categorized by primary dispatchers. A Chief Dispatcher, the ones using this highlighting tool, used to ensure they saw messages they needed to see. The tool shows all messages at once whereas the tool they use right now can only show messages for one call at a time and doesn't highlight important ones.

I'm not making the point that it program you wrote isn't an improvement, which it sounds like it likely is, but that it would ,in fact, change how "they" operated.

That's not why he was fired.

I wasn't fired and wasn't asked to resign. SPD tried to keep me.

Reply on news.ycombinator.com