Programmer Tim Clemans Resigns from Seattle Police Department After Six Months
thestranger.com
thestranger.com
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".
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 ?
[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.
- 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.
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.
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.
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.
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.
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.
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.
That's a very accurate view of most police.
Fixed it for you.> 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.
“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.[0]http://www.seattletimes.com/seattle-news/spd-tech-officer-re...
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.