Tools -> capabilities -> acclaim

Here’s a lovely graphic from the folks at Intercom. It describes the difference between what companies sell and what people buy.

Even though customers buy this [skateboard parts]… they really want this [cool skateboard trick].

We don’t want the tool, we want what we can do with the tool. Take it further – maybe what that skateboarder really wants is: the high fives at the end.

skateboarder getting high fives from the crowd

Our accomplishments feel real when people around us appreciate them. If the skateboarder’s peers react with “Why would you do that?? You could die! You look like a dumbass,” titanium hardware doesn’t shine so bright.

It reminds me of the DevOps community. Back when coworkers said, “Why are you writing scripts for that? Do you want to put us out of a job?” automation wasn’t so cool. Now there’s a group of peers, at least online, ready to give you high fives for that. The people you meet at conferences, or get familiar with on podcasts, or collaborate on open source tools with — these take automation from laziness into accomplishment.

Giving developers polyurethane wheels and hollow trucks won’t let them do tricks. Move to a culture of “our job is to automate ourselves out of better and better jobs.” Give us the high fives (and let us pick our tools), and developers will invent new tricks.

Safety and Progress

At Papers We Love conference, Dr Heidi Howard described requirements for distributed consensus: Safety and Progress.

In distributed consensus, multiple servers decide on some value and then report that to their clients. Safety means that the clients never learn about different values; the consensus is all correct and consistent. Progress means that clients do eventually get the values. It doesn’t get stuck.

There are lots of ways to guarantee safety. The trick is to find ones that allow progress in all circumstances.

It reminds me of the conflict between security and development. Security teams are responsible for safety: prevention of bad things. Development teams are responsible for progress: making good things happen.

Separate these two responsibilities and you get deadlock. The obvious ways to get safety prevent progress, and the fastest routes to progress erode safety.

Algorithms, processes, designs that give you progress and safety exist, but they’re subtle. You won’t find them by fighting with each other.

In distributed consensus, the algorithm designer holds responsibility for safety and progress. To build the features that advance your business with the security that keeps it safe, put these responsibilities on the same team.

Safety and progress can be at odds. Don’t bake this conflict into your org structure.

Keep them entwined. Guarantee progress while allowing safety.

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.

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.

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?