Nate Meyvis

A model of how simplicity gets rewarded

Yesterday I wrote a little about the politics of simplicity. The problem of rewarding simplicity has many causes:

  1. Not that many engineers value simplicity.
  2. Even fewer managers and leaders value simplicity.
  3. Those who do value simplicity cannot always recognize it.
  4. The benefits of simplicity are often invisible.
  5. The failure modes of complex systems are unpredictable, so the benefits of avoiding them cannot always be known, much less communicated.
  6. Designing a simple system often means foregoing the chance to do future work on that system, which tends to be professionally valuable.
  7. Simple systems tend not to use trendy tools. Using trendy tools can be professionally valuable. (And fun.)
  8. Complex solutions tend to be more institutionally legible.

So, it's hard to reward simplicity. Here's one model for how institutions do it:

  1. Make no real attempt to measure, understand, or recognize simplicity or other high-judgment aspects of system quality.
  2. Cultivate a high-trust, high-judgment culture full of expert individual contributors.
  3. Let those people decide, however they like, how well their peers are doing in these high-judgment areas.
  4. Come performance review time, everyone allocates some scalar amount of positive recognition to each of their peers.
  5. But you don't explicitly give someone, say, 7 points; you translate it into institutionally legible notes about high-profile projects, measurable effects of their work, and so on.

To be clear: this is not how it actually works. At many places, it's nowhere close to how it actually works. But sometimes, in some places, it's a reasonable model for some fragment of the process. It helps me think about, for example, how at least one company with very high intangible code and system quality also has strange-looking, widely accepted collusive practices to prepare for performance reviews.

I don't intend this cynically: to me, it's the opposite. You really can reward simplicity and any number of other subtle, poorly understood, and hard-to-measure things. You just have to do it indirectly.

#sociology of software #software