Comment by hyperman1

I once got a program that was a never-ending source of bugs. It had huge forms, with fields becoming valid or invalid depending on the state of other fields. Each field had listeners to activate/deactivate controls as needed, but the interactions had become so complex that they were full of tiny mistakes. Each tiny mistake slightly corrupted the state, triggering other mistakes, until the whole thing snowballed out of control. Costly business mistakes followed.

After a while it occurred to me that all state was duplicate/triplicate/..., e.g. a checkbox on screen and a boolean field. Most bugs amounted to inconsistencies between the duplicates. So we wrote for each form 2 big methods: One copied the records to the UI, the other the UI to the record. All listeners became a 3 step process: Copy complete UI to record, do the change only in the record, copy complete record to UI.

In a way this was wasteful: Typing 3 characters would enable or disable most GUI elements 3 times. But computers had become fast enough that this was unnoticeable. The dynamic of the program changed: instead of tiny mistakes in the code spiraling out of control, they would disappear as the next user action would most probably fix them. Bugs basically dried up overnight after what amounted to a small code change.

In this case, it was too late to make invalid states unrepresentable, but we managed to declare 1 part of the state correct, and derive all the other state from it. I learned a lot about state management from that experience.