This is a series of posts I’ll be writing about my work at Transparent Blue, specifically on WatDis. In this first post I will give a super-short intro to water networks and talk about the software engineering challenges in WatDis. Following in the series I will talk about the solutions we give to this problems and I will end the series by writing about my personals experiences in Transparent Blue, what I enjoyed of the WatDis project and what we achieve as a team.
Water networks 101
WatDis is a system for the analysis of water pressure distributions networks. The software allows engineers to evaluate the behavior of the pipe network and to evaluate its performance.
Before water reaches your tap, it must be pumped into elevated tanks and them is carried down by gravity to your home through a network of pipes. Hydraulic engineers are the specialists in charge of planning these networks and they take numerous design decisions, like which pumps to buy so tanks get filled in time before consumption peak, which pipes to place to maintain stable pressure and how high tanks must be elevated.
These ‘simple’ questions gets answered by solving a not-so-simple system of differential equations, that can be built and then calculated using a ‘system for the analysis of water pressure distributions networks‘, like WatDis.
The input to the system is a model of the hydraulic network. This model can be rather complex, since it contains many elements like pipes, consumptions, many types of valves, water reservoirs and pumping stations, just to mention a few. Therefore, a great deal of effort is made to input the model to the system. These challenge software builders to achieve a system both powerful and easy to use.
Software engineering challenges of WatDis
When Alejandro Escandón, CEO and founder of Transparent Blue told me that water goes down by gravity, I was shock by this rather obvious fact. Water going down itself is not shocking, but the fact I never thought of it was. For me, you just opened the tap and that was it: water.
This made me realize I was designing a software for a field in which I was clueless. Alejandro presented me with the current WatDis code at the time, some spaghetti I decided to discard completely and start from scratch. Since I did knew nothing of hydraulics, I feared finding myself in a situation where a feature would catch me by surprise and to add would mean to change the whole design(with the corresponding hours of coding this convey).
Like stars around Goofy’s head when banged with a hammer or similar, the word “plugin” was rounding my head . But… plug-in what? What is going to be plugged into what? To answer these questions, I enjoyed myself looking at the ceiling, drawing imaginary boxes and connecting them with al sort of arrows. Finally, with the aid of Inti, the third founder of Transparent Blue, we found a solution that allowed WatDis grow like a well-oiled machine: Everything is a plugin.
Currently, Microsoft have already an extensibility framework as for .NET 4, however, at .NET 2.0 it did not exist. We also look at OSGi, but when we ran screaming in panic when we say the specifications, we needed something more simple.
Another challenge was that the properties of the hydraulic model’s elements needed to be first class citizens. For example, there where all sort of property tables, users could add custom properties, we needed color keying visualizations to show results, genetic algorithms to calibrate the model, etc. All these algorithms have in common that they take the value of some property and do some with it, potentially writing back to other properties of the model. We solve this initially with reflection. BIG mistake. Terribly complex and terribly slow. We moved on into a simpler solution that we called lightweight reflection.
Thanks for reading this far. In the next post I will talk about the WatDis plugin system and the lightweight reflection.