When authors write books, they need to know their readers; that’s how they choose their words. When directors make movies, they keep their audience in mind, too.
In the same way, software engineers need to know their end users.
Emergency response software is too often written for a committee of middle managers and accountants. The people who will actually use the software are not in decision-making positions. So, when new software systems are installed in public facilities, everyone in the bureaucracy gets a piece of software code with thier name on it — and the day-to-day users have to live with the result.
Here’s an example from today’s Minneapolis/St. Paul Star Tribune:
Dispatch ‘upgrade’ slows fire response
Minneapolis, MN — Minutes can mean lives to firefighters battling flames or answering medical emergencies. So when Minneapolis spent $4.2 million upgrading its computer dispatch technology this year, Fire Chief James Clack was hoping for the faster response times the maker promised.
Instead, things are worse. Since the upgrade, firefighters are getting to fewer emergency calls within the five minutes they use as a standard.
Minneapolis dispatchers say the new system has advantages, but it also makes some illogical choices…
The problem here is a failure to understand the difference between fire and police — which probably came about when a committee tried to order software that would serve many masters, but with a “one size fits all” user interface. Of course, the data is all there, but allowances are required for the differences between fire and police departments.
While both organizations have a similar mission — to safeguard the community – a dispatch system designed for police response is not a perfect fit for fire response.
Consider these facts:
- Police buildings were never designed to have a pole to slide down because the stairs would be too slow. Firefighters still use the pole.
- Firefighter outfits are arranged in advance so the guys can literally slip into them on the way to the fire truck.
- Police carry notepads to meticulously collect details. That’s done after a fire.
.
Firefighters begin with the assumption that an emergency is already in progress. Police assume there is an annoyance in progress, and they need to be convinced otherwise. I’m not criticizing anyone here. I’m explaining a fundamental difference in the nature of the job. Multiple confirmations are needed for police becuase that’s what they get when there is a real emergency.
Firefighters have equipment and tools. They need to bring with them everything they might need to match a situation. With police, the issue is usually a person. A person can be brought back to the station, where they have all the necessary tools, like jail cells. I know they have guns and other tools. My point is they don’t have to have what amounts to construction equipment in the trunk of their car.
Committees, by design, incorporate a wide range of people with a wide range of viewpoints. And, it would be a rarity for any of them to have experience in software development process. Programmers need clear, concise instructions. The typical beaurocratic process can change objectives on a dime, based on competitiveness and politicial manuevering. After objectives become clouded, the software winds up being written for the guy who spoke loudest after the budget was used up.
So, while I don’t know any more specifics of the Minneapolis dispatch system than this news story provides, the situation is a classic example. The problems would be solved — maybe for less money – by having the right people working with each other.
