Programming Without State Chaos
At OutSystems, we strive to keep our codebase modular and easy to understand, so we can quickly improve parts of our systems and components without requiring too many changes. One of the challenges we face is programming without state chaos. As you shall see, state is a good candidate for the deepest cause of software complexity and lack of modularity. Why is it a problem? How can we manage it? Here are some answers.
State is anything that can change. When code depends on state, you multiply the complexity a thousand fold and you can’t easily reason about the code; you have to check the internals and look under the hood. Thus, modularity is diminished.
When hitting a bug, this line won’t even be on your suspect list. But after debugging you find that for some odd reason, this piece sometimes is not working as expected. Your local reasoning and intuition told you that the function isElementClickable must be self-contained, but after looking at its internals you find that's not the case.
You ask yourself “How could I know that the function relied on a changing state?” Well, you couldn’t! Only by looking at its internals.
