4 ms·

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 prog

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.

logfromblammo 11y ago
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.
- jboy55 11y ago
  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.
  - logfromblammo 11y ago
    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.

logfromblammo 11y ago

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.

jboy55 11y ago
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.
- logfromblammo 11y ago
  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.