by Jtsummers | 2025-07-06 02:36:36+00:00
This has come up a lot at work for me the last few years.

I've ended up (unintentionally, but satellite control systems is a small world) working on systems both using the same framework (a COTS satellite C&C system) though with differing attitudes on how it should be used. The framework has a lot of issues, among them the creators don't understand that if adding two 64-bit values gets you a 32-bit value it's probably not working correctly (it has its own bespoke scripting system).

However, one of the things I think they got right, at least in principle if not in the precise mechanism, is that the end users can develop their own automation scripts, displays for telemetry and other data, etc. very easily. What's been interesting is the perspective the two projects take on this.

In one, the operators are given a write-protected baseline. This means they cannot mess with the known working (or working but with known issues) versions willy-nilly. However, the operators make modifications to scripts as, for instance, it turns out the documentation on a satellite's command language is wrong (happens more than you'd expect for 9- to 10-figure systems). They make their own modified versions of the displays. They attach to the automation hooks so that when some telemetry values pop up, specific scripts are triggered, and so on. They're programming even if they don't recognize it as such, and actively engaged with improving their system.

In the other, the operators are actively discouraged from this. They are encouraged to provide feedback, but not to make their own scripts, to attach to automation hooks, or to make their own displays (as new displays or their improved, for their mission needs, version of the display).

It's been interesting because while the former had some issues, like the operators making scripts that failed because the scripting language has subtle errors that people on my side (more actively involved in maintaining the systems) understood and they didn't, it worked pretty well. They'd send us how they want things to look and flow with working scripts and custom displays not just descriptions. It wasn't speedy or always the most congenial, but it was collaborative. In the current one, though, it's more like there's a lack of trust in the operators. An assumption that they will fuck things up and a fear of how to restore the system to a known good state overriding a desire

There are true idiots out there and malicious people, you have to take some precautions. But it's been interesting to me to see two organizations dealing with the same kinds of critical systems (screwing up a billion dollar satellite is a big deal) taking almost diametrically opposed positions on operator customization and modifications to their systems. I like the more open one better, add in some reasonable constraints (they have sims to test against, use version control and peer reviews and engineering reviews) due to the criticality of the systems in question, but let them make the modifications. A perfect system can't be engineered without input from users, and users making modifications to suit their needs shortens the loop instead of taking weeks, months, or years.