I am incredibly grateful that Sean Goedecke published his beautifully written article Seeing like a Software Company. In it, you will find a wonderfully balanced presentation of why companies often choose legible practices over more efficient, illegible ones. Sean very clearly details the kind of (in my words) doublethink that goes on at companies involving these very needed, but often hated, illegible processes. If you are hoping for that sort of balanced, nuanced take, please read his article instead. Sean has freed me from the burden of needing to write that way myself.
Deep down on reflection, you don't care about OKRs, you don't care about code review, you don't care about coding standards, you don't care about lint rules, you don't care about style guides, you don't care about deadlines, you don't care about job titles, you don't care about standup, you don't care about code coverage, you don't care about any of these processes.
Your values are complicated. They require context and consideration. They aren't simple mechanical rules that can be captured by any metric, any process, or any methodology. You may believe these practices and tools we've adopted are pragmatically correct decisions to achieve your values. But they aren't the values themselves. And yet, they are the "values" that the "company" holds, or, more accurately, they are the values the company wants you to hold.
Processes adopted by a company aren't about the end result of the work. Their stated goals and their actual goals are always distinct. An initiative related to applying coding standards isn't about making the quality of the code better. It is about changing the behavior of the engineers writing that code. By making code uniform, it reinforces some of the legibility myths (my word) Sean Goedecke says that companies rely on.
- Any engineers with the same job title perform roughly the same.
- Engineers can be shuffled and reorganized without substantial loss of productivity.
- A team will maintain the same level of productivity over time if it has the same number of engineers.
These are all false. Everyone knows they are false. It is easy to think of these as idealized assumptions, but they aren't. You can't find physicists out in a field trying to shove a cow in an orb to make their equations work out better, but software engineering directors are more than happy to do so to software engineers.
Legible assumptions are not merely assumptions. They are coupled with practices trying to make their assumptions reality. This is first by placing barriers (processes), but it goes much deeper than that. Barriers can be circumvented. Gatekeepers can be ignored. The modern software enterprise has realized that the only true way to make its legible assumptions true is to change the very nature of those creating the software. To transform them from an illegible force to a legible one.
Every software process does the same thing: it converts a rich, multifaceted value into a single metric. "Are our customers happy with our product and support?" is not the same question as "how high is our NPS"? "Is this team performing well?" is not the same as "What is this team's 'velocity'?". "Are we working on the right stuff?" is not the same thing as "Do we have a prioritized backlog?". Yet we constantly mistake these questions for each other. Not only that, we don't even realize that these are conflations. Why? Because we are rewarded for fixing the latter and not the former.
The excuse always given for this disconnect is that the former questions don't work at "scale". But what precisely does that mean? If you have too many people, each divided into small groups (teams), they can't each ask these questions? No, these rich questions are actually quite easy to parallelize. What they don't do well is compose and reduce so that those at the top can understand them. Don't confuse something not working at "scale" with something that doesn't make an executive feel warm and fuzzy.
But the real reason for this conflation is not simply that it makes executives feel good, but that these metrics are an incredibly powerful means of changing behavior and values. In other words, they are a way of making the world fit the assumptions those at the top have already made.
Value capture occurs when an agent's values are rich and subtle; they enter a social environment that presents simplified — typically quantified — versions of those values; and those simplified articulations come to dominate their practical reasoning.
By making these metrics, the company can change how we behave. They can make our behavior properly legible.
The sad fact is, as an industry, we long ago stopped only letting executives enforce rules on us; we enforce them on each other. We create rule after rule that we will make it so that "good software" is the necessary outcome. We all bring our own flavors of these rules. Our own dogmas we hold to, our own tastes we apply to others. We shame other engineers who do not follow our rules. The rules are the values.
They constantly try to escape
From the darkness outside and within
By dreaming of systems so perfect that no one will need to be good.
- T.S. Eliot
In Rules: A Short History of What We Live By, Lorraine Daston distinguishes between thick and thin rules. Thin rules are the algorithmic, mechanistic rules we in software favor; they are rules that can be obeyed and enforced unambiguously. Thick rules, on the other hand, are rules of thumb; they are guiding principles. Daston shows how there has been a historical progression from thick to thin rules. That today, we almost always think of rules as this thin, algorithmic process.
By following these thin rules, we not only produce worse software, we also steer our behavior to one that isn't sensitive to the real things we value. "Did the code pass code review?" is the wrong question. How much bad code have you seen pass code review? But the very fact that "passes code review" is the thin rule we have adopted ends our conversation. We can try to revise our "code review checklist" to "closer" approximate our true values, but this is a losing battle. What we care about can't be captured by our thin rules.
Legible processes are impossible to escape if you work for a company. Maybe they are necessary. Maybe companies of a given size must adopt them or fail. You don't have a choice but to follow some of these processes if you want to keep a job. But what is in your control is whether you let yourself be value captured by these metrics and processes.
You can choose to embrace the legible. As an IC, you can choose to value your work on the basis of these legible processes. You can set aside your own personal values about code and map your behavior to what the company cares about. As a manager, you can have your team follow the legible processes to create software that meets all "success" criteria, but still sucks.
Or you can choose to truly care about something. You can choose to push back against the legible processes that are trying to make you an abstraction. Not because you are selfish and stubborn. Not because you think you know better than others. Not because you don't want to follow rules. But because you value something that can't be captured in simple metrics. Because you know the company will benefit from these things. As Sean tells us, illegible work is essential. So why not be essential?