Case study
What was at stake
SIATA is the early-warning system for Medellín and the Valle de Aburrá. It is the network that watches the weather, the rivers and the air over a metropolitan area of several million people, and tells the city when something is about to go wrong.
Behind the public-facing side sits a set of internal applications that the teams use to manage risk and disaster response. Those tools are not a convenience. When there is a flood risk, they are what the people making the call are looking at.
The constraint
The tooling had grown the way internal tooling usually grows: one application at a time, built to solve an immediate need, by whoever needed it, without shared standards holding any of it together. That works right up until it does not. The software becomes hard to change, hard to hand over and hard to trust, which is a particular problem when the people using it are working under time pressure during an actual event.
There were two distinct problems in there, and they needed to be treated separately. The applications were technically below standard, and they were also hard to use.
What I built
I migrated several of these applications onto better technical standards and better usability, rebuilding them in Django for the teams that live in them daily: operational staff, weather monitoring, flood monitoring. A lot of it was taking research-grade code, written to answer a question once, and turning it into software that has to run every day without its author present.
The users were the point. Each of those teams has a different job and a different sense of what “urgent” means, and the tools needed to reflect that rather than expose whatever structure happened to be convenient to build.
Getting that right was not a design exercise done at a desk. It meant going to the teams, understanding what they were watching for and what they needed to do about it, and accepting that a workflow which looks redundant from the outside is often load-bearing for the person running it at three in the morning. The technical migration was the straightforward half. Agreeing on what each tool was actually for was the part that required people.
What came of it
The applications the risk and disaster teams depend on became software that can be maintained, handed over and trusted, instead of a collection of one-off builds each understood by one person.
It was also the first time I worked on something where the users were not other engineers and the stakes were public. That combination teaches you quickly that “technically correct” and “usable by someone under pressure” are two separate requirements, and only one of them is visible from inside the code.