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?

Closing the feedback loop from the customer

Feedback loops are essential to learning. In business, they’re essential to getting the product right. We need to know what the customers think, what they’re struggling with, what they value.

There’s one department that has a lot of contact with customers. Whole conversations, where we can learn a lot about what frustrates people. Yet, customer service is generally operated as a cost center, optimized for low pay instead of high knowledge acquisition.

business experts talk to developers, who create an app, which is used by a whole slew of customers, who then call customer service. Does customer service get to send that feedback to the business experts?

Is the business getting feedback from this rich source of customer contact? or are we too busy coping with a quantity of calls? So many different people using the app. Each call represents only a tiny piece of customer experience.

In software-as-a-service, where the customers are developers, each of them is responsible for millions of uses of the app. Developers are high-leverage this way. What they struggle with, what stops them from using the product more, stops their applications from using the product LOTS more. The impact of each developer-customer is orders of magnitude larger than that of a single customer of a consumer product.

For this reason, in place of (or in addition to) customer service, we have Developer Advocates. A developer advocate answers questions, gathers experiences, and interacts with developer-customers at high bandwidth. Developer advocates are hired for impact, not for low pay.

replace the slew of customers with a few developers controlling their software which uses our app; these devs talk to a developer advocate, who talks to developers, business experts, and influences our app directly.

Developer advocates share feedback with developers of the product. They can impact the customer’s experience with the product directly: by changing it, and by adding plugins, tutorials, documentation, etc.

Feedback loops are short and thick compared to traditional customer service. It makes sense that this is possible in software, because the quantity of humans we need to interact with is much lower, and the impact of each is higher.

This seems like a win. I 💓 software-as-a-service.

Generativity

Generativity is about caring about what comes after you.

In a social context, it’s when old people care about subsequent generations, instead of maximizing their own happiness for the last few years.

In business, it’s when executives care about the health and outcomes of the whole executive team, instead of their own career after this job.

Generativity is building the next version of yourself, your team, and your organization. This includes current work and all the work you’ll be capable of in the future.

For software development teams (among many others), companies care about the work they’re capable of doing. They care about productivity — the outward-facing work of the team.

productivity is externally visible; generativity improves the team

If we look at productivity as a property of individuals, if we measure and reward “how many tickets did you personally close?” then we give people reasons to work alone, to rush, to keep information to themselves. This cuts away at the potential of the team.

If we care about the team as a whole, both now and in the future, then we encourage generativity. Teach each other, communicate, craft software so that people can understand and work with it.

Generativity is hard to measure, but not so hard to detect. Ask, who helped you today? Who answered your questions and taught you something useful? What scripts or documentation or comments or variable naming made your work smoother?

long-term productivity comes from a healthy team

If productivity is the externally visible work that is attributed to you, then I define:

Generativity – the difference between your team’s outcomes with you, vs without you.

It is not about me, and it is not about right now. I want to make my team and my company better for the future. I want to be generative.