Moving beyond simplicity

We prefer simple models to complicated ones. Circles to ellipses, a single ancestor to a soup. But is that really because the simple explanation is more likely?

The value of keeping assumptions to a minimum is cognitive.

Philip Ball, The Tyranny of Simple Explanations

Simpler theories are more useful because we can think about them more easily. We can pass them from person to person.

But now we have software, which can encapsulate complicated theories almost as easily as simple ones. We can package them up into products and make use of them, without taking up brainspace with all those complications.

Maybe you still find simple models most likely in physics. Simple models are not accurate in biology – much less in human interactions.

In biology, everything going on had some reason it got that way (might be randomness) and many reasons that it stays that way. Most adaptations are exaptive — used for some purpose other than their original purpose. Most have many purposes, the proteins participate in multiple pathways, the fur is warm and also distinguishing, the brain anticipates danger and builds social structure.

In our own lives, every action has multiple stories. I’m playing this game to relax, I’m playing this game to avoid writing, I’m playing this game to learn from it.

We choose based on probability spaces from many models, stacked on top of each other. I buy this dress because I feel powerful in it, because I deserve it, because my date will like it, because I am sloppy with money. I value this relationship because I don’t know how to be alone, because they’re a kind person, because we belong together, because he reminds me of the father figure from my childhood.

This is right, this is healthy, to have all these stories. In real life, the simple explanation is never complete. Taking action for exactly one reason is unnatural. Like gaming a metric, it fails to account for the whole rest of the system.

Everything we do in a complex system has many effects, so it is right that we have many overlapping reasons. This doesn’t make life easy, only real.

When I started in software I loved that it was simple and predictable. Now I love that it is complex and messy, because that’s where I learn the important stuff.

Learning as becoming

businesses… need a new worldview… that shifts the emphasis… from success as accomplishment to success as learning.

Jeff Sussna, in Designing Delivery

“Success as learning” doesn’t mean learning lessons. This is not learning as facts.

This is learning as becoming. It is learning that bakes into who we are and how we do things, bakes into people and software.

Success is becoming a person, a symmathesy, an organization that can do more than before.

Don’t know. Find out.

Legacy code is software that is no longer alive in someone’s head. No person has a mental model of how it works, no one has the stories of why.

This is already the common case in software systems, and it will only grow more normal.

Understanding an entire piece of the system is a luxury. We get it while we build it, but after a while, that knowledge fades too. Then, we reconstruct portions of the model we need for each change or fix.

As software grows, it is unrealistic to expect a complete mental model of it to exist, even across a team or company. Instead, aim for the ability to construct what we need as we need it.

Readable code is only the beginning. We need observability, discoverability, and operator interfaces that teach. We need to see what’s going on live. Only once we narrow in our target must we mentally simulate the runtime by reading code.

This is true at a large scale, too.

From early in Jeff Sussna’s book, Designing Delivery: “so-called rogue or shadow IT, where business units procure cloud-based IT services without the participation of a centralized IT department, makes it harder to control or even know which data lives” where.

Yeah! You won’t know all your data lives off the top of your head, nor is this recorded in a binder somewhere. You will know how to find out. And know that each location of data meets the security and recoverability needs of its business unit.

Let’s stop asking “how do we know?” We don’t know, usually. Instead, ask “how will we see?”

direct aims, broad interests

You can want something, or you can just be interested in things.

On a dating site, you can decide what you want in a partner and filter people for that and message them. Or, you can find many things about people interesting, and look for any of these traits or hobbies, and ask about them.

In software, you can set an engagement metric and aim to move it. Or, you can aim to “be more useful,” think of many possible ways that could happen, and look for ones that you can try.

A danger of aiming for one metric is: in moving that needle, you may degrade essential properties. If your added information makes the page so busy that I can’t look at it, then your needle may move while the software becomes less useful.

In people, the world has more wonder in it than I can think to want. Wide interests invite widening surprise.

There is a place for purposive action (as Gregory Bateson calls it). For deliberately moving directly toward a goal. Maybe that place is limited to systems we can understand and predict.

I’ll be specific about my wants, in the small: I want to write this post. And open to whatever finds me, in the large: someone will subsume it in more interesting ideas.

Developers are system changers

Some people work in a system, and some people work on a system.

Like, you can be the person who washes the dishes, or the person who installs and maintains the dishwasher.

You can be the person who assembles the reports every week, or the person who automates that report assembly. (Jacob Stoebel told this story on >Code #148 today. That’s how he got into software development.)

You can conform to a system, or you can participate fully — part of serving the system is changing the system to better serve you.

Developers are inherently system changers. That’s what we do. No wonder we’re hard to manage!

No wonder software communities are full of turmoil and rabble-rousing and shifting technologies: we are a whole industry full of system changers.

Also on >Code today, we talked about personal automation. Chante Thurmond remarked on the tools that exist today to let people (not just developers!) customize, tweak, and automate their work. We can all craft the systems we operate in. More and more system changers.

This is the real change software makes in the world.

Regret

I am locally very important, globally not important.

It helps that I’m not important, that the world moves on whatever I do, it doesn’t need me to push it

The people close to me, they count on my help. Local systems, my family and my team, what I do matters to them. Failing them, this hurts. It is okay that it hurts.

I want to make a big difference to my family and team, and small differences in the world.

There is a wrenching drumb in my chest today
It squeezes in a nearby beat
Walk with it into a new self, a new world.

To scale it up, smooth it out

To scale up the system you’re changing, scale down the changes.

The bigger and more complex the system you’re working on, the more people involved, the more affect a change can have — the smaller each change needs to be.

When change is expensive, when it’s scary, don’t make fewer changes. Work to make changes less expensive (no matter how expensive that work is), so that everyone can make smaller changes, because tiny changes aren’t so scary.

Commit code sooner, work in small batches, get the code out there before the merge conflicts erupt. The State of DevOps Report for 2019 remarks that this helps in open source software. And that in business, a heavyweight change process makes everything worse, including the very risk it was supposed to reduce.

Economies of scale are reversed in software. One big change is more expensive than many small changes. To get bigger, get smaller.

(see: Kent Beck on Limbo and scaling software beyond current imaginings)

skills and/or understanding

There’s a story about some brilliant design that made carrots more accessible to everyone, and the man who made it happen:

Sam [Farber], a delightful person to work with. He understood the business, but what was important was, he understood design. If he could have been a designer himself he would have been, but he had none of the skills necessary.

Mark Wilson

Understanding design is not coupled to having the skills of design, to being able to do it yourself! And that understanding can combine with other areas — such as business, where Sam has both the understanding and the skills — to make a person really effective.

In software too! A person can understand software development without having coding skills. These people are valuable, when they connect that understanding of software with the business.

And a person can have coding skills without understanding software development. We all started somewhere.

If you move from day-to-day coding into management, architecture, or any business role, you use your understanding of software development. And you can update and deepen that understanding without maintaining your hard-core coding chops.

This is where conference sessions and keynotes shine: at deepening our understanding of software development. We develop our skills at work, in play, or in workshops.

Value this understanding, in yourself and others. And try to gain understanding of other parts of the world, such as design and business, even if you don’t have the skills. It’s the combination that gives us power.

Increasing potential as a specific output of flow

In Projects to Products, Mik Kersten divides flow items in software products in four: features, defects, risks, and debt.

If you only count features added and bugs fixed – changes visible externally – then you neglect the other outcome of our work: the next version of the team+software.

I prefer to think of “technical debt” work as groundwork for future changes. I like Kersten’s suggestion to do more of this at the beginning or a release cycle, while preparing to add a lot of features.

Pretending that software is “done” at the end of a project is dangerous. Naming risks and technical debt as part of the output of flow makes caring for our future explicit.

Closed games vs Open Games

From The Grasshopper, by Bernard Suits:

When you play a board game, or a game of baseball, you’re playing a closed game. There is a defined end, and a defined set of means to reach it.

When you play pretend, or when you build a career in baseball, you’re playing an open game. The objective is to keep playing, to make it more interesting. While some means are proscribed (don’t deny what the other player added, no steroids), it helps to bring in new people or tools.

Software projects are run as closed games. The objective is to end on time and on budget, using business-approved resources.

Software products are open games. The objective is to keep being useful in a changing world. We can bring in new tools, and new people, and there is no “done.”

When we play open games, we play for the future. Outcomes. We care about the people who come after us. Closed games (such as annual performance goals) lead to crunch time, when all we care about is checking boxes whether it does any real good or not.

Closed games can be zero-sum. You win, I lose. In an open game, for me to win, you have to win too.

Every business is an open game. Life is an open game. Can we keep the closed games to the dining room table and sports, please?