The setting: a tech industry project with a lot of smart software people, working around the clock in VC-funded startup mode. Among many other elements, their system had a sensor to detect a safety-critical parameter, which we’ll call “OSEP”. OSEP was a big deal to monitor and control… its value changed as the system operated. OSEP was safety-critical… everyone knew that. And for that reason, redundant OSEP sensors had been installed at position 1. Everyone felt good about that.
And then additionally a separate single OSEP sensor was located at location 2. With that, we therefore had third OSEP sensor (counting the single sensor at position 2, and the two redundant sensors at location 1). Even better.
And then as it turned out, a supplier provided a full control module that also had it’s own redundant OSEP sensing capability built in. That was redundant also... so with two measurements of OSEP, measured at location 3.
So, three locations, and five total sensors to measure OSEP, were built into the system hardware. Along with the safety team, I nodded in approval. Lots of redundancy is good for safety. Right?
I felt sure of it at the time. But I became less sure over time.
Application coders performed a weighted average of all the OSEP sensors and called it OSEP-3.
The supplier also called their value OSEP-3, because it was located at position 3.
The Osep sensor at position 1 wrote three values: OSEP-1, OSEP-2, and OSEP-3 (which was simpy an average of the first two values). Uh-oh. Now there were three separate signals known informally as OSEP-3.
There was also a signal called Verified OSEP, which was the average of the redundant readings from position 1 and position 2. The folks who came up with that hadn’t anticipated the supplier OSEP sensor.
And then there was Golden OSEP. The notes on that variable listed it as “the verified OSEP value” which meant it was a combination of two of the sensed values which were also plausibility checked for too-high and too-low values by a small bit of diagnostic code. Sounds good; but that meant two variables that referred to “verified” signal either in the variable name or in the variable description.
And so on and so forth, etc, etc. In software, 20 coders were inventing 20 or more OSEP values on the fly, with no naming consistency and not even a process to discuss naming consistency. With so many coders defining and re-defining a massive library of OSEP values, no one knew which value reflected which sensor, or which combination of sensors evaluated in which ways.
The result was mass confusion. In any meeting that required coordination on OSEP, arguments and misunderstandings reigned supreme. No one knew what anyone else’s value meant; everyone thought their value was right or good or unique. It was chaos.
What everyone agreed with vigorously however was that defined and rigorous software development process was a waste of time. For this venture-backed start-up, it was all about speed … get there first, break things fast, race against the competition, etc. etc. So all these individually-smart speed-driven developers raced forward without the encumbering grind of process, while simultaneously encumbering themselves with mass confusion over the most basic information. And in fact the OSEP signal was just one such case. Lots of stuff was redundant, mis-named, inconsistently labeled, and argued over in circles each day.
In the end, it wasn’t better. It wasn’t simpler. It sure wasn’t safer. And wasn’t any faster. But it continued on, this naming inconsistency, and not just at this client but many others over the years. Why?
Well:
Everyone knows what a programmer does. He or she writes code. And management views writing of code as a valuable task, worthy of prioritizing and measuring.
No one knows what a naming consistency engineer does. No one aspires to be one. And management doesn’t see the need for it.
Any number of solutions can solve a relatively simple problem like the OSEP sensor name-game. Systems architects, data architects, variable naming conventions, review processes, change and configuration management properly applied to variables… any or all of the above can set and enforce naming consistency. In the longer run, good documentation has the same effect when done properly.
But to gain solutions to a problem, one must first decide the problem is worth solving, and that the solutions are worth having. In cultures that defined themselves as anti-process, anti-hierarchy, and anti-documentation, none of these solutions could take root.
In the end analysis, I can say they wrote code with tremendous speed. And that’s about all.