Static-dynamic interaction

Keywords: philosophy, change, stability, computer-science, planning

Is structure merely standardization? Is something “structured” when there are a set of rules? In order to evaluate the rules, we need to see how well they work. What is their utility? What is their role when dynamically interacting with the real world?

From mere rules to understanding why

Without rules, we are in free fall. There is no solid ground. There is no reference. Twisting and turning, our center cannot hold.

When there is nothing but rules, we are in stasis. There can be no change. Only a block of ice, eternal. No matter the force mashing against it, it will not move. It will not move.

We want neither extreme. Neither free fall nor stasis. We cannot work when everything is in unpredictable movement, and we improve that which cannot change. We need both. And we want the best of both.

By introducing some stability into an unpredictable environment, we can improve its adaptability. By letting a system evolve, get unstuck, it can move into a state that is more stable.

Let us consider some specific examples, and make static-dynamic interaction viscerally real.

Computer science: word confusion with immutable data structures

Popularized by Facebook’s React, immutable data structures has seen fresh wind in later years. Chris Okasaki’s textbook Purely Functional Data Structures came out all the way back in 1999, so the topic is by no means a revolution. The gist of immutable data structures is simple:

What’s a value? And what’s a reference? We’re digging down to the fundamentals, now. I state:

In other words, if you have a value, it’s persistent. It doesn’t suddenly disappear from under your nose. You can count on a value being the same the next time you look at it.

“That sounds all nice, Teodor. It doesn’t disappear! We like things that are solid that are stable. We like things stable! So, tell me the limits of your statement. Make some boundaries for me. When should we not use a value? Why not use values all over the place?”

We typically want some names to be references. We want to change what is behind the name. Take a Wikipedia page. I don’t really mind that a Wikipedia page changes. I trust that it will change for the better. Or, should it change for the worse, that some trusted Wikipedia community member will revert it.

“Best” by nature is a reference, because it is context dependent. And we need the context! We’re really asking for context when we ask “best”. It’s not specific. The implicit part is the meaning “best, as of now”. And “now” is a new reference. As I am writing this sentence, “now” is 2018-10-05 16:30:16. And now, now’s already something else!

Where does that leave us with the promised theme of “word confusion with immutable data structures”? When we’re advocating for someone to make use of immutable data structures, we’re not saying that they should go to Okasaki’s textbook everywhere in the application. If we only use immutable data structures throughout the application we’re writing, we can’t have any references to “current” or “now”. When writing a compiler, that’s not really a problem, because a compiler usually has all its data up front. “Current best” doesn’t need any qualification. We can just use “best”, and that’s enough.

So why would we advocate for managing something that changes all the time with immutable data structures? Why would it be a good idea to use immutable data structures for something like a single-page web application, which changes all the time? Because we’re implying “use immutable data structures for everything”. We’re wanting to say “use immutable data structures to implement a system where state changes are managed, so that we know what has changed and what has stayed the same”. We want good state management by having a structured approach to the static-dynamic interaction in our application. And that usually means encoding all values as values, and keeping our references to a minimum. Reference up top, and immutability all the way down.

Planning: making stable, agile systems by setting static-dynamic boundaries

“But! But, but! Butts! I can’t guarantee what will happen! I can’t say! What if it doesn’t work out the way we planned? What if something unexpected happens? I can’t give you an estimate! The scope will expand, and there will be like 103 revisions until everyone are happy!”

Current software engineering practices used out in the wild, typically all use some version of agile. At least they say they do. Since we can’t know all the requirements up front, we need to change, adapt and reconsider. No shit, Sherlock. The image of the old, terrible past is painted. “We’re not using waterfall! We’re agile! We’re changing as we go!”. The words waterfall and agile are set up against each other. From pitch black darkness to enlightenment. From no changes, to all the changes. This image is terribly low-resolution.

Agile isn’t about changing everything. It’s about changing things sensibly. And that means stability in the change. Change, nested in stability, nested in change. Agile methodologies even provide us with more things that don’t change. A methodology itself, is an attempt at describing what shouldn’t change. It’s an attempt at defining the part of the system that’s orthogonal to change.

“It’s about time you come back down to earth, Teodor. Give me some examples. Some meat.”

Yeah. No veggies for you. Methodologies typically define periodization. Implicit in it is something along “the way we chunk things over time shouldn’t change”. In personal time management, it’s often called timeboxing. Managers may talk about weekly, monthly, quarterly and yearly planning. It seems to me that we usually perfer to create a hierarchy of epochs with some logarithmic scale, with base between 2 and 4.

Let’s see how epochs look at base 4. We’re starting at a day. 4⁰ days = 1 day. Then there’s the work week. If we work all the time, we’re at 4¹ days plus one, five days. Or we’ve only got four effective days in a week, leaving us with 4¹ = 4 days. A month is about 4 weeks ≅ 4² effective days. The quarter is a little off, with three months a quarter. Let’s round that off. A quarter is 4³ days. And the year is actually four quarters, 4⁴ days. Each time we move up the scale, we multiply with approximately four.

“But why? What’s the value of that? Who the shit are you to say that your random smartass logarithm 4 hierarchy of epochs is sensible at all? I say we go for log 𝛑! Hah!”

Yeah. This is an optimization problem, really. Relevant considerations:

1. Cost. How much worse is the current periodization scheme than the ideal periodization scheme?
2. Practicality. Will it be reasonable to work this way? Does my periodization scheme mesh well with others?
3. Time variation. How much will the utility of the periodization scheme change over time?
4. Cost of periodization change. How many people will I have to drag with me into this new (and hopefully better) metasystem?
5. Predictability. How simple is it to plan up ahead?

Dear practical reader. You’re probably laughing your ass off for the sillyness of this question. Dear theoretical reader. Using weeks and months is what everyone else are doing. In my estimation, practicality (2.), cost of periodization change (4.) and predictability (5.) trump the possible suboptimality of the remaining points.

There is so much value in having the periodization scheme set and rather changing what goes into different epochs, that we generally keep the periodization scheme unchanged. It’s a static part of our planning system.

What about agile? Scrum dedicates a substantial amount of attention to process improvement. The Scrum retrospective is a case of managed change. We set a static point of introspection on our agenda. We manage the process change actively, codifying the process change. By explicitly saying that this is the scrum retrospective, we allow team members to have a predictable point in the agenda dedicated to change. We can then write one document with the changes we’re going to make, and have one set part of the next epoch when we discuss whether the changes were good.

What about within a project? We can’t set everything up front. The point is what things should we set up front. Optimization, again. A shared common understanding of goals is useful in most projects. What’s a goal? Or rather, what is a good goal? I would say that a good goal helps us aim, and doesn’t change all the time. A good goal is a somewhat stable target. We can aim for it for a while, and not have it move. Then, what is planning? In part, it’s exploring the static-dynamic interaction we’re going to have, and searching out the static parts. Because the static parts won’t change (that much), and are usually good to know early.

Focus: increased efficiency through stabilization

The world is quite complex. Lots of things can happen. We explain things as simple as we can, and then “the world usually isn’t that simple.” That really annoying voice. I’m about to race ahead, and something is saying “it’s probably not that simple”. Aaaah! And I just want to go ahead. Do. Work. More. Learn. Interact. “It’s not that simple”. Some times it is! Just shut up!

And if I can finally chase that annoying voice off, I can get some work done. At last. Look down on the details and act. Make something happen. Get progress. See results.

By pretending that the rest — all the things I’m not going to consider — are not going to change, I can make some small change more efficiently. But will it be the right change? I hope so. What makes it the right change or not? In large part, that depends on where the focus has been. Have we considered the right thing? Or has important problems been put off somewhere because they’re unpleasant? In that case, we may have a real problem on our hands.

Pick what’s important. Pretend the rest is static. Pretend that the rest is as you think it is. Then shove it off to the back of your brain, somewhere. Assume that your brain is going to tell you if you need to reconsider some of it. Then work on what matters. And since you don’t waste too many cycles on what doesn’t matter, you’re hopefully quite efficient.

Yin and yang: religion and philosophy already knows

In our circle of life, there is stability and chaos. Stable isles where we know what’s going on, surrounded by deep waters where monsters are lurking. We cannot see them, only fear what we do not see. The beach draws us. We come to the edge. Still standing on solid ground, we watch. We gaze out over the waters, perceiving. Perhaps even understanding.

Feeling extraordinarily adventurous one day, we decide to go on an adventure. We will explore the unknown. We don’t run into the waters and swim. That would be stupid. Instead, we build a little piece of solid ground to stand on. Not super solid, but a little. We build a boat.

It is time to set sail. We push our small boat off the beach, and climb on top. It’s not like standing on solid ground. It moves. Mostly, it moves as we expect. It follows the waves. Up and down. Back and forth. We hope the good weather is going to hold.

Days past, we feel the fear. Land is no longer in sight. Just our tiny spec of wood underneath us. We are not yet short on food supplies. At least not if we make it back in time. If we don’t face bad winds. Or get lost.

In the distance, we see our target. Sharp rocks pierce the water. Part black, part glittering in reflection. They tear up the surface, as the water moves up and down. A clean cut. It is here the great ships of old lie buried, far below the surface.

Our pulse is rising. Beating. Our chest moving visibly. Adrenaline is pumping. We’re scared and engaged. We know we may fail. There is no place to anchor our little boat. We don’t see what lies in the deep. There may be black creatures waiting, ready to pull us down.

We dive. Down. Down. Down. Darkness surrounds us. There! The glimmer. We see light reflected. Small. Golden. Our heart beats harder. We go up. Catch some air, move towards where it was, if memory serves us right. Down again. Down, down down. Where is it? We saw it! It was so clear! We swim back a few strokes. Turning. Wait, there! In the corner of our eye, it blinked. We close the distance, and feel the smooth surface. It’s so small. Fits well within our hand.

Back up in the boat, sitting down on our small deck, we inspect our treasure. The golden casing, well connected to the glass panel. Below it, a red arrow and a black. The black moves steadily with the rhythm of our boat.

It is time to take the compass back home.

—

We are living on islands of stability, surrounded by oceans of movement. There is so much movement that we cannot keep track of it. It is dark to our eyes. We don’t even know what we don’t know. In the dark near us, we see the parts of shapes. Moving our light closer, we can distinguish features on the shapes. See what they are made of. Yet even more shapes appear.

Sometimes, we need to leap into the unknown. Sometimes, the only path is by sea. And we need to keep going, even if there’s no land in sight. And if we’re steadfast and lucky, we may find something of value. Perhaps even a small island, in the sea of the unknown. We learn that we can build a piece of solid ground, and take it with us.

Yin and Yang symbolize change and stability. The boundary between change and stability is fluid, moving, negotiated. There is chaos nested within stability, and stability nested within chaos. Change and stability has been at the bottom of how we understand the universe for a long time.

Why? Utility.

Finding stability is not making a set of static rules. Finding stability is about identifying how the moving parts reasonably can be separated from the solid parts. When the solid parts are identified, they can be standardized, and we predictably move faster. When the dynamic parts are identified, we can focus on them.

What if you’re wrong?

When I’m wrong, I will strive to admit it, and correct whatever wrongdoing I have made. If I set static-dynamic boundaries that miss the mark, I will work to correct them. Of course, hitting earlier is better, especially when working with multiple people, where more coordination is required. At the same time, the likelihood of hitting the mark the first time is low.

I propose that the best we can do is to make a best-effort of identifying the static-dynamic boundaries, and move the boundaries when that is needed. Hopefully, by building a model that incorporates dynamism, the model will have to change less frequently than a dogmatic all-static model.

Takeaways:

• Identify static parts and moving parts over mere “standardization”.
• Scale can help you identify the static parts. If something isn’t stable, try move up one level of scale.
• By identifying stable parts, we can enable moving faster overall.

Thanks to Remi and Lisa for feedback on this text.