From the limited context of the article, Clemans sounds very talented and helpful but "blowing up, yelling, and cursing" when someone dismisses the helpfulness of a project is not an ideal way to change a culture.
And the reason he blew up was because any changes to the way 911 operators worked had to be approved. Wow. What I can't believe was that he was allowed to resign and wasn't fired on the spot.
Basically. Short of owning my own company, I've never been allowed to make sweeping changes unilaterally. Hell, I have a business partner, so even now I don't get to make changes unilaterally.
The first time someone isn't as impressed with this guy as himself, he goes red.
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 ?
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 ?
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?
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?
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.
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.
In 2005 I was creating a national 9-1-1 company for VoIP. It's understandable why people would be so conservative given the stakes. (Though sometimes they laughably underestimate the fragility they introduce, like initiatives to hook up every PSAP to the Internet and route calls that way.)
One PSAP in particular was very upset with our service. He insisted that we do not connect "Internet calls" to his PSAP, as "there might be viruses or something". Note that this was simply dialing the 10-digit number that's part of the public network - anyone can dial it.
Though it's hard to tell from the article if this was really just a procedural issue ("great software, but you must clear it and run through this checklist") or territorial/political.
A number of people thought it was important software including the Chief Operating Officer who immediately had it put to use in the Realtime Crime Center. It was the Captain who didn't want to have a checklist. My bosses, bosses, boss at the time tried to get the Captain to agree to a structure that would allow stuff like this to be developed but the captain refused.
It seems pretty clear that the captain wasn't dismissing the helpfulness but rather dismissing Clemans' authority to deploy the project.
It's a power play, and Clemans' disdain for rigid power structures clearly contributed to the friction between him and the SPD administration.
EDIT: the captain's response is not unwarranted at all. Emergency response call centers are a critical public resource and he is ultimately in charge of them.
What is worse, it is not even clear that the captain is entirely wrong here.
If Clemans screwed up, he had the potential to have 911 calls be routed to /dev/null. If he succeeded, the department became more efficient. However the 911 system is already working "well enough". Therefore in terms of outside perception any win will be small, and disasters could be huge.
He is not the one who has been give the authority to make this kind of risk decision. The captain is. If Clemans screwed up, the captain would be the one getting fired. Keeping the captain out of the loop is irresponsible. It doesn't matter that it worked. It doesn't matter how good the system is. You need to work with stakeholders, and not behind their backs.
However Clemans seems like the kind of person who can never understand this point.
You are absolutely correct that he had no authority to perform modifications to a critical public service, and that his actions bordered on reckless and negligent and that his response to the captain's accusations was cringe-worthy as well as indicative of the ignorance of his actions, but I think it stands to reason that the captain could have handled the situation more diplomatically.
Granted, I would probably get into a shouting match with Clemans for what he did (and I'm just another developer), but that hardly justifies barring him from entering the premises until further notice.
Clemans' actions can be chalked up to youthful ignorance and exuberance, whereas the captain has no excuse. He is the central source of truth and the ultimate arbiter in the situation, he should know better than to react so aggressively to one of his own staff members.
Clemans' actions can be chalked up to youthful ignorance and exuberance, whereas the captain has no excuse. He is the central source of truth and the ultimate arbiter in the situation, he should know better than to react so aggressively to one of his own staff members.
React aggressively to some aspergers-afflicted kid cavalierly modifying and possibly breaking a public emergency response system with an expected uptime of always?
The captain's response was 100% measured and appropriate given the situation.
You can't attack someone personally like that on HN—not that this would be shameful if it were true, but you clearly intend it as a slur, and that's not allowed here. Please comment civilly and substantively or not at all.
Clememns is in the comments explaining how the system worked. He just reads the current calls out of a database and displays them with some highlighting. There is no write.
... until the connection pool is misconfigured or something and the writes can't get in.
Touching mission critical things always has risk and those risks have to be mitigated at a political level. If the programmer is this bad at respecting political ownership of responsibility, he has no business touching production this way.
Not saying Clemans is right, but couldn't the captain have handled it better, instead of just banning him from the building? We have a talented, enthusiastic, but inexperienced youth on one side and a police captain (whose job by definition is to handle all kinds of personalities) on the other - he could have used a bit more patience and tact in explaining, containing Clemans instead of just throwing him out of the building. The cops lost more than Clemans here.
He "blew up," yelling and cursing at Rasmussen. He remembers saying to Rasmussen, "I'm going to PDR [public disclosure request] the shit out of you."
And you want to say the PD could have handled that better? Go into your boss right now and do the same thing. Let us know how he handled that from the unemployment line.
That said - I work for a private firm, not even remotely as crucial as the police dept. cops are trained to deal with all kinds of situations/personalities (my boss is not). The captain could've banned him for a month, instead of permanently. After both of them have cooled down, he could've sat him down and explained that shouting isn't going to help. He could've given him warnings etc. Instead, he seems to have gone on a power trip. Clemans is not some destructive guy, or some criminal. He is just a frustrated over enthusiastic young man. The real losers in this are the people of Seattle.
I hope some other police dept hires him and also he learns to control himself better.
"However, not long afterward, according to Clemans, longtime SPD captain Ron Rasmussen complained in a meeting that all changes in the center had to go through him. Rasmussen dismissed the usefulness of the highlighter program, Clemans said."
The Chief Information Officer at the time arranged the meeting to put structure around all this app development I was doing for 911: CAD remarks keyword highlighter, instant 911 call history, immediately show call out #s for a shooting etc (so dispatchers aren't leaving their desks to find the numbers in phone books), and TAC channel registration (again so they would leave their desk). It was the Captain that wouldn't go along with the Chief Information Officer was trying to accomplish.
Seattle (for city council, mayor elections, school board hires) seems to have a history of bringing in "outsiders" who are used to throwing stones at the process, who then (surprise surprise!) fail when trying to work within the process. (Edit: This is indicative of the people themselves, but also of that horribly over-inclusive beast dubbed the "Seattle Process").
Lets hire someone who has been antagonizing the SPD (and arguably visa versa) for a long time, and make them work together! What cold possibly go wrong?
I'm actually not trying to be a smart-ass. There is a very public history of tension between Tim and the SPD. Two parties with such a history mixed with an organization that is already mired in politics created a situation that was all but guarenteed to fail from the start.
Shame though, I personally would have love to seen the fruits of a better relationship between these two parties.
Because employers love hiring people for the purposes of berating them until they blow up, then firing them when they realize they screwed up and try to play ball.
That is a very perverse theory that can be disproved by another techie who has lasted there longer than 6 months.
It appears the programmer failed to realize how srructured and protocol driven the SPD is, #1, and #2, his tact was atrocious, which is probably what got him fired.
It's happened to me and to the best of us, failure to gauge the pulse of the environment... He seems very talented, however just a really poor fit for SPD. He will be much happier elsewhere.
edit for Azkar: then that's what I call a poor fit, without blaming myself or the employer.
This really isn't a problem that's unique to the SPD. I've worked for several corporations that are resistant to change for whatever reason and it is extremely frustrating. The engineers end up being told to do X, instead of being asked to solve problems.
I suppose it's slightly better than the usual alternative of ignoring, or suing, the outsiders, but yeah, this was pretty predictable. He's obviously a gifted programmer, but developing new software for a division without evidently consulting (let alone including) the stakeholders was obviously going to cause some kind of reaction. It sounds like he didn't have a manager to handle the politics (which is odd; most large public safety departments I've seen have their own IT staff separate from the rest of the city), and is tactless if not outright on the spectrum, so kind of an inevitable parting of the ways. Nice that SPD was so gracious on his leaving, though.
Unfortunately, policing culture is very territorial and operates at extreme levels of testosterone fueled territory marking.
A tech-nerd (with possibly some autistic traits from the descriptions) is never going to get along in that environment without someone seriously watching over them. And whoever that is, will have some serious work to do in order to get the best for the department.
Cops are trained to push peoples buttons and make them lose control. Tim seems to have not seen the play coming and was fairly easily sideswiped before he even got far off the ground.
It sounds like SPD are not up to the job - even though someone at least seemed to be in the right direction when they hired Tim in the first place. If they had been able to follow through with the right support, SPD could have been an incredibly awesome exemplar of Policing and tech done right. To me, it sounds like there are serious management problems with the department - this situation would never have happened if people were properly competent.
Sadly, in my own experience, Policing and tech are never done terribly well. It always ends up with the snoopers and intrusive abusers gaining more ground and the things which really help keep people safer and more secure being thrown in the ditch or run over completely.
> Sadly, in my own experience, Policing and tech are never done terribly well.
This is a poor example of the two cultures not getting along. No IT person worth his salt would ever allow someone to come in and start deploying one off applications like this in a 911 call center of all places.
"Cops are trained to push peoples buttons and make them lose control"
They are? I could see why, say, detectives interviewing a suspect might use that approach to try to get them to say something incriminating, but for regular cops I would think their job is made much easier if the people they interact with are calm.
Think of executing searches. A cop needs a reason to search someone (their person, their car, etc.), beyond just being suspicious. Frequently they can prod people into providing them such a reason.
Yes and it is for a good reason. Earlier today in New Jersey:
> A jury yesterday found Spolizino, 37, not guilty of death by auto and leaving the scene of a fatal accident in the death of 24-year-old Stephen Clifford on April 19, 2013. An aggravated manslaughter charge had been tossed earlier by the judge.
> Authorities said Spolizino was driving 60 miles per hour -- 35 MPH over the speed limit -- when his vehicle struck Clifford on Kennedy Boulevard. The state argued Spolizino caused Clifford's death through the recklessness of the speed at which he was driving.
> The jury disagreed.
> Video showed the pickup continue north on Kennedy Boulevard where it went through a red light at Montgomery Street before pulling over.
> The video then showed the pickup go into reverse and back up to Montgomery, the officer quickly dialed 911 and a witness said he saw the officer at the scene of the crash within five to 10 minutes of the impact.
> During the trial, Garrigan noted that Clifford was crossing against the green, implying that Clifford bore some of the responsibility. He also noted that speeding on Kennedy Boulevard is common.
I don't have any insight into the case in particular but I really doubt the outcome would have been the same if the person driving were not a police officer.
In other news, the NJ police had choice words for Tarantino.
> The New Jersey State Policeman’s Benevolent Association has become the latest police organization to call for a boycott of Quentin Tarantino’s films, following the director’s participation in an anti-police brutality march in New York last weekend.
[...]
>“Quentin Tarantino needs to understand that as a public figure his voice is one that people listen to,” Colligan’s statement continued. “He has an obligation to be more responsible. This is not a movie, this is real life where police officers lives are impacted by his words.”
You know what impacts police officers' credibility more than a director's words? The benches of police officers that filled up in solidarity of a police officer who doesn't deny that he was behind the wheel of a car in a hit and run case driving 60 miles per hour on a 35 miles per hour area. Would any of the police officers be there if it was... I don't know... an undocumented immigrant without a license or an out of state driver or anyone who was not a police officer?
It isn't a value judgement, but I would certainly prefer a system that is structured to reward rational actors and execute the stated mission. The current design seems pretty ironic to me.
> policing culture is very territorial and operates at extreme levels of testosterone fueled territory marking.
Business culture is that way. Heck human culture is that way. To be successful and / or engender change you must learn how to deal effectively with that culture. Hint blowing up and cursing aren't how.
I have to say...I'm very impressed that he lasted that long. And I think credit has to be given to both Clemans and the Seattle PD...Clemans, obviously, for putting his skill and ingenuity toward the public good. But also, to the police for not only being open to change, but willingly bringing in someone who so openly antagonized them. Given the amount of political ego in most police organizations...6 months of collaboration is pretty astonishing.
Even if the Seattle PD were at fault, the onus is on them to either adopt or ignore what Tim has done for them...sometimes the attention and public scrutiny is enough to change things, so I wouldn't see Tim's departure as the end of it. It doesn't have to be be, at least, and hopefully other Seattle civic hackers have been inspired by his work.
Let's talk about some of the things he did. The highlighting of the most important calls seems useful, but the article also mentioned he developed "blurring of anything that moves in police footage". What is the benefit of this?
It's for privacy. Before this feature, the SPD had someone manually blur out faces to protect privacy. The burden this placed on police resources was a large factor in why they didn't want to or couldn't comply with public records requests.
As a programmer, this seems like this is almost entirely Clemans fault. Good grief: you can't just walk into a mission-critical, production environment and start deploying crap, even if the dispatchers like it.
Yelling at your boss who rightly pulled the plug on that stunt is hardly justified. Whether or not it's a firing offense depends on a lot of things the article doesn't tell us, but..
This is really not the "idealistic and pure-hearted lowly programmer" vs "corrupt and overly political, turf-controlling police culture" it makes it out to be.
I'm not sure that the author of the post would understand enough to provide any evidence that Clemans deployed anything in an unsafe or inappropriate manner. Maybe he just deployed a webapp that the people in the communications center could access. The post is so light on details that I can't discern that he did anything wrong.
> Maybe he just deployed a webapp that the people in the communications center could access...
I can hardly thing of a single bit of code that should be deployed in such a literal life-and-death environment, which shouldn't go through FULL REVIEW.
Maybe it's a small webapp that gives a bit more information -- which leads dispatchers in the wrong direction one out of ten times. Maybe his "highlighting the most critical calls" was highlighting the wrong ones. Maybe he solved a minor problem only, but took up dispatchers' time in training.
Clemens is in the comment thread. It seems like the system he wrote read out of the 911 call database and displayed all the active calls. Then highlighted calls based on keywords so the head dispatcher could more easily see high priority calls ( crimes in progress ? ).
This seems very safe. The captain in question is just protecting his turf. Even if he saw the benefit he would never admit it because it wasn't his idea.
I'd love to read an 'AMA' style post, or even just an interview done by another programmer, to learn more about what exactly he did, and how he did it.
Phrased more charitably, "protecting his turf" is actually "doing his job."
With the little information available, I can see the captain's position. The programmer was new and rolled out changes to the surprise of the captain. Programmer hadn't earned captain's trust yet, and was pushing out new procedures which the captain did not (?) agree with. That'd be a no-no in any company, just substitute CEO for captain.
Regardless of whether his system was fantastic, the manager in any org is meant to be a safeguard, even when it feels like a bottleneck.
I wasn't in trouble for doing what I did. The meeting was discussing how to keep the innovation going in a more controlled manner. The Captain believes the only way to implement software in 911 is to take years and millions of dollars to do it.
How about all the important calls they let languish because of the bide-shedders interfering? How is that safe?
Can the naysayers be sued by the family of some kid who died because dispatchers weren't allowed to evaluate a new tool because change scares some people? (No, of course not. And that's why there are so many bikeshedders.)
Bikeshedding is when leaders ignore complex & core questions to focus on trivial ones that are easier to understand. The tools that dispatchers use to handle incoming called doesn't sound like a trivial question.
The core of bikeshedding is continued nitpicking at the trivial by those who can't understand or don't know enough to grasp the its actual significance. And it's not just leaders.
Certainly change would be bad if the programmer in question blidnly modified existing systems. But I don't see any of the reactionaries asking that - they just assume the worst and go off on how unsafe it might have been.
But a new webapp bundling data from other systems into a new view? It shouldn't be any problem at all. The professionals on the phones are the very ones who would have to evaluate the information it returned so there's no way around letting them use it.
The code itself might be intrinsically safe, but the process it generates might not be. The argument doesn't have to be "this code will crash the 911 system"; it might just be "people are going to get hurt when operators act on the information it attempts to generate".
And yet if some operator had an idea to keep some notes (license plates from APBs or something) on stickies and pass them around the room - a new procedure - nobody would act like the world would end.
"FULL REVIEW". How FULL exactly? I think a really thorough review should involve the people who defined the language used, and who wrote the compiler. Certainly everyone who ever worked on the code. And the Compliance team. Lets involve them early to speed up the process!
The professionals on the phone seem to have spoken very highly of the benefits from this program. Why are people second-guessing them?
Maybe it did go thru full review. I can't tell from the post whether it did and the police chief just decided post-hoc that no changes could be made without their express approval (i.e. in the future), or whether Clemans bypassed existing protocols.
And sure, maybe his changes were imperfect. But surely lots of changes made by others there could have had terrible consequences.
Or maybe his "highlighting the most critical calls" was simply visualizing info that the dispatch personnel were already entering.
Still, I can't tell whether he did anything wrong from the post itself. And I guess I'm inclined to believe he didn't, but maybe my prior belief is inaccurate.
In a government agency that has sensitive information about ongoing investigations about criminal activity and personal information, you can't put up a web page for ANYTHING without approval.
Also, he admits that when that happened, he "blew up," yelling and cursing at Rasmussen. He remembers saying to Rasmussen, "I'm going to PDR [public disclosure request] the shit out of you."
That alone will get you escorted out of a LOT of companies who will say you definitely "did something wrong".
Organizational Software is, in essence, bureaucratic automation. And if you try to impose bureaucracy, control, tracking and/or regulaiton inside a deeply "brotherly" organization, you are bound to have issues.
Yep wanna not improve SPD fine but I'm going to showcase everything you and your people do. You're be forced to improve once the media gets ahold of the mistakes being made.
Don't get it. This whole thing could have been solved in a 5 minute review with folks. Maybe they want more than just that 1 feature?
Either way, installing _any_ software, even those that only do a read (how does he even know that that's all it did?) to a mission critical piece must always be vetted, end of story. Heck, even a _read_ could take down the system if it did lots of JOINs a slower DB, etc.
Just because you can get something running doesn't mean you're a systems engineer.
Also in the Seattle Times[0], an interesting quote, apparently by Clemans:
“Basically, it all went to hell,” said Clemans, describing his
relationship with the department. “The problem is [the department]
wants to use technology, but it wants to have vendors who build
these large systems that cost a lot of money and are hard to implement.
I want things to go fast and I’ve been working with people
who realize government moves slowly.”
It seems Clemans got frustrated by the inefficiencies of bureaucracy, and the department got fed up with his disruptive attitude.
The software doesn't highlight calls it highlights messages with keywords. This was asked for by a dispatcher who said during emergencies it's hard to spot the important messages. This particular dispatcher's job was to monitor all of the other dispatchers and ensure that calls were prioritized correctly. The software itself did not do the dispatchers job for them. Calls are prioritized before the Chief Dispatcher typically sees them. There are calls the Chief Dispatchers are supposed to know about but are always notified of. This software was a tool to help keep the Chief Dispatchers in the loop. They dictated which keywords they wanted to use.
The meeting was scheduled by the director of IT at the time, a former Amazon VP who left two weeks after this incident, about how to allow me to continue developing apps like this. He was trying to put structure about it. The Captain wanted none of it.
What kind of messages? What kind of highlighting? What's a specific use case you were targeting? (I'm sure there was one! I just see too many of us speculating about it.)
The messages were by dispatchers. I'll give you an example, shortly after the center was no longer allowed to the app, someone called 911 and claimed his car had been shot. A dispatcher put it down as rock hit the car. A higher up told me that had my app been in used the Chief Dispatcher would have been alerted because they all had keywords for shot, shooting, etc. This is the only tool to see all messages for everything at once. I even asked them if they would like to hide messages and they said no.
Hey, sorry to derail, but I've been meaning to get back in touch with you, totally weird to see you here. Email me at x1799faa@gmail.com and I'll explain.
Enterprise software is hard not because writing it is hard, but the multitude of stakeholders that you have to convince and have a buy-in before it would even pass muster. However, you are brimming with good ideas, if Seattle doesn't want your ideas, there are enough police departments in the world that you'll find someone who is willing to try new things.
104 comments
[ 3.2 ms ] story [ 183 ms ] threadThe first time someone isn't as impressed with this guy as himself, he goes red.
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]
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.
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.
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.
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.
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.
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.
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.
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?
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?
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?
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?
Sounds like he changed how they operated to me
One PSAP in particular was very upset with our service. He insisted that we do not connect "Internet calls" to his PSAP, as "there might be viruses or something". Note that this was simply dialing the 10-digit number that's part of the public network - anyone can dial it.
Though it's hard to tell from the article if this was really just a procedural issue ("great software, but you must clear it and run through this checklist") or territorial/political.
It's a power play, and Clemans' disdain for rigid power structures clearly contributed to the friction between him and the SPD administration.
EDIT: the captain's response is not unwarranted at all. Emergency response call centers are a critical public resource and he is ultimately in charge of them.
If Clemans screwed up, he had the potential to have 911 calls be routed to /dev/null. If he succeeded, the department became more efficient. However the 911 system is already working "well enough". Therefore in terms of outside perception any win will be small, and disasters could be huge.
He is not the one who has been give the authority to make this kind of risk decision. The captain is. If Clemans screwed up, the captain would be the one getting fired. Keeping the captain out of the loop is irresponsible. It doesn't matter that it worked. It doesn't matter how good the system is. You need to work with stakeholders, and not behind their backs.
However Clemans seems like the kind of person who can never understand this point.
You are absolutely correct that he had no authority to perform modifications to a critical public service, and that his actions bordered on reckless and negligent and that his response to the captain's accusations was cringe-worthy as well as indicative of the ignorance of his actions, but I think it stands to reason that the captain could have handled the situation more diplomatically.
Granted, I would probably get into a shouting match with Clemans for what he did (and I'm just another developer), but that hardly justifies barring him from entering the premises until further notice.
Clemans' actions can be chalked up to youthful ignorance and exuberance, whereas the captain has no excuse. He is the central source of truth and the ultimate arbiter in the situation, he should know better than to react so aggressively to one of his own staff members.
React aggressively to some aspergers-afflicted kid cavalierly modifying and possibly breaking a public emergency response system with an expected uptime of always?
The captain's response was 100% measured and appropriate given the situation.
You can't attack someone personally like that on HN—not that this would be shameful if it were true, but you clearly intend it as a slur, and that's not allowed here. Please comment civilly and substantively or not at all.
https://news.ycombinator.com/newsguidelines.html
Touching mission critical things always has risk and those risks have to be mitigated at a political level. If the programmer is this bad at respecting political ownership of responsibility, he has no business touching production this way.
And you want to say the PD could have handled that better? Go into your boss right now and do the same thing. Let us know how he handled that from the unemployment line.
That said - I work for a private firm, not even remotely as crucial as the police dept. cops are trained to deal with all kinds of situations/personalities (my boss is not). The captain could've banned him for a month, instead of permanently. After both of them have cooled down, he could've sat him down and explained that shouting isn't going to help. He could've given him warnings etc. Instead, he seems to have gone on a power trip. Clemans is not some destructive guy, or some criminal. He is just a frustrated over enthusiastic young man. The real losers in this are the people of Seattle.
I hope some other police dept hires him and also he learns to control himself better.
Lets hire someone who has been antagonizing the SPD (and arguably visa versa) for a long time, and make them work together! What cold possibly go wrong?
I'm actually not trying to be a smart-ass. There is a very public history of tension between Tim and the SPD. Two parties with such a history mixed with an organization that is already mired in politics created a situation that was all but guarenteed to fail from the start.
Shame though, I personally would have love to seen the fruits of a better relationship between these two parties.
Once he was in the door, it was on him to prove he can work within their framework. He failed and escorted himself out of there.
Unless he accepts responsibility for his shortcomings -first-, blaming a powerful institution like a police department isn't going to do him any good.
That is a very perverse theory that can be disproved by another techie who has lasted there longer than 6 months.
It appears the programmer failed to realize how srructured and protocol driven the SPD is, #1, and #2, his tact was atrocious, which is probably what got him fired.
It's happened to me and to the best of us, failure to gauge the pulse of the environment... He seems very talented, however just a really poor fit for SPD. He will be much happier elsewhere.
edit for Azkar: then that's what I call a poor fit, without blaming myself or the employer.
A tech-nerd (with possibly some autistic traits from the descriptions) is never going to get along in that environment without someone seriously watching over them. And whoever that is, will have some serious work to do in order to get the best for the department.
Cops are trained to push peoples buttons and make them lose control. Tim seems to have not seen the play coming and was fairly easily sideswiped before he even got far off the ground.
It sounds like SPD are not up to the job - even though someone at least seemed to be in the right direction when they hired Tim in the first place. If they had been able to follow through with the right support, SPD could have been an incredibly awesome exemplar of Policing and tech done right. To me, it sounds like there are serious management problems with the department - this situation would never have happened if people were properly competent.
Sadly, in my own experience, Policing and tech are never done terribly well. It always ends up with the snoopers and intrusive abusers gaining more ground and the things which really help keep people safer and more secure being thrown in the ditch or run over completely.
This is a poor example of the two cultures not getting along. No IT person worth his salt would ever allow someone to come in and start deploying one off applications like this in a 911 call center of all places.
They are? I could see why, say, detectives interviewing a suspect might use that approach to try to get them to say something incriminating, but for regular cops I would think their job is made much easier if the people they interact with are calm.
> A jury yesterday found Spolizino, 37, not guilty of death by auto and leaving the scene of a fatal accident in the death of 24-year-old Stephen Clifford on April 19, 2013. An aggravated manslaughter charge had been tossed earlier by the judge.
http://www.nj.com/hudson/index.ssf/2015/10/acquitted_jersey_...
> Authorities said Spolizino was driving 60 miles per hour -- 35 MPH over the speed limit -- when his vehicle struck Clifford on Kennedy Boulevard. The state argued Spolizino caused Clifford's death through the recklessness of the speed at which he was driving.
> The jury disagreed.
> Video showed the pickup continue north on Kennedy Boulevard where it went through a red light at Montgomery Street before pulling over.
> The video then showed the pickup go into reverse and back up to Montgomery, the officer quickly dialed 911 and a witness said he saw the officer at the scene of the crash within five to 10 minutes of the impact.
> During the trial, Garrigan noted that Clifford was crossing against the green, implying that Clifford bore some of the responsibility. He also noted that speeding on Kennedy Boulevard is common.
http://www.nj.com/hudson/index.ssf/2015/10/jersey_city_polic...
I don't have any insight into the case in particular but I really doubt the outcome would have been the same if the person driving were not a police officer.
In other news, the NJ police had choice words for Tarantino.
> The New Jersey State Policeman’s Benevolent Association has become the latest police organization to call for a boycott of Quentin Tarantino’s films, following the director’s participation in an anti-police brutality march in New York last weekend.
[...]
>“Quentin Tarantino needs to understand that as a public figure his voice is one that people listen to,” Colligan’s statement continued. “He has an obligation to be more responsible. This is not a movie, this is real life where police officers lives are impacted by his words.”
http://www.ew.com/article/2015/10/30/new-jersey-police-quent... (sorry for quoting ew, you don't have to click the link)
You know what impacts police officers' credibility more than a director's words? The benches of police officers that filled up in solidarity of a police officer who doesn't deny that he was behind the wheel of a car in a hit and run case driving 60 miles per hour on a 35 miles per hour area. Would any of the police officers be there if it was... I don't know... an undocumented immigrant without a license or an out of state driver or anyone who was not a police officer?
Business culture is that way. Heck human culture is that way. To be successful and / or engender change you must learn how to deal effectively with that culture. Hint blowing up and cursing aren't how.
Even if the Seattle PD were at fault, the onus is on them to either adopt or ignore what Tim has done for them...sometimes the attention and public scrutiny is enough to change things, so I wouldn't see Tim's departure as the end of it. It doesn't have to be be, at least, and hopefully other Seattle civic hackers have been inspired by his work.
Yelling at your boss who rightly pulled the plug on that stunt is hardly justified. Whether or not it's a firing offense depends on a lot of things the article doesn't tell us, but..
This is really not the "idealistic and pure-hearted lowly programmer" vs "corrupt and overly political, turf-controlling police culture" it makes it out to be.
This article has a huge bias.
I can hardly thing of a single bit of code that should be deployed in such a literal life-and-death environment, which shouldn't go through FULL REVIEW.
Maybe it's a small webapp that gives a bit more information -- which leads dispatchers in the wrong direction one out of ten times. Maybe his "highlighting the most critical calls" was highlighting the wrong ones. Maybe he solved a minor problem only, but took up dispatchers' time in training.
This seems very safe. The captain in question is just protecting his turf. Even if he saw the benefit he would never admit it because it wasn't his idea.
With the little information available, I can see the captain's position. The programmer was new and rolled out changes to the surprise of the captain. Programmer hadn't earned captain's trust yet, and was pushing out new procedures which the captain did not (?) agree with. That'd be a no-no in any company, just substitute CEO for captain.
Regardless of whether his system was fantastic, the manager in any org is meant to be a safeguard, even when it feels like a bottleneck.
Can the naysayers be sued by the family of some kid who died because dispatchers weren't allowed to evaluate a new tool because change scares some people? (No, of course not. And that's why there are so many bikeshedders.)
Certainly change would be bad if the programmer in question blidnly modified existing systems. But I don't see any of the reactionaries asking that - they just assume the worst and go off on how unsafe it might have been.
But a new webapp bundling data from other systems into a new view? It shouldn't be any problem at all. The professionals on the phones are the very ones who would have to evaluate the information it returned so there's no way around letting them use it.
"FULL REVIEW". How FULL exactly? I think a really thorough review should involve the people who defined the language used, and who wrote the compiler. Certainly everyone who ever worked on the code. And the Compliance team. Lets involve them early to speed up the process!
The professionals on the phone seem to have spoken very highly of the benefits from this program. Why are people second-guessing them?
And sure, maybe his changes were imperfect. But surely lots of changes made by others there could have had terrible consequences.
Or maybe his "highlighting the most critical calls" was simply visualizing info that the dispatch personnel were already entering.
Still, I can't tell whether he did anything wrong from the post itself. And I guess I'm inclined to believe he didn't, but maybe my prior belief is inaccurate.
Also, he admits that when that happened, he "blew up," yelling and cursing at Rasmussen. He remembers saying to Rasmussen, "I'm going to PDR [public disclosure request] the shit out of you."
That alone will get you escorted out of a LOT of companies who will say you definitely "did something wrong".
Either way, installing _any_ software, even those that only do a read (how does he even know that that's all it did?) to a mission critical piece must always be vetted, end of story. Heck, even a _read_ could take down the system if it did lots of JOINs a slower DB, etc.
Just because you can get something running doesn't mean you're a systems engineer.
[0]http://www.seattletimes.com/seattle-news/spd-tech-officer-re...
The meeting was scheduled by the director of IT at the time, a former Amazon VP who left two weeks after this incident, about how to allow me to continue developing apps like this. He was trying to put structure about it. The Captain wanted none of it.