Facebook

It was six years ago that I heard Russ Roberts interview Nassim Taleb about Black Swans. Along the way, Taleb mentioned convex and concave payoffs. I’m usually a visual thinker but I really didn’t get it. Something bugged me, though. It seemed like convex payoffs were important. I filed the idea away.

Today I was thinking about the difference between predictive and responsive software development. Somehow I made the connection to my mental bookmark about convexity. I did a little searching and finally “got” convexity. What’s more, convex payoffs illustrate the opportunity of responsive development. Here, then, are convexity, concavity, and their application to programming.

If we plot the value of a payoff with the magnitude of success, many tasks end up with a curve like this:

This curve shows diminishing marginal returns–each increment of success brings a smaller increment of payoff.

Here is where Taleb lost me six years ago. This curve is concave from the bottom right of the graph but convex from the top left. Turns out I was drawing the graph wrong:

From inside the shaded portion, the graph is just concave. Don’t know why it took me so long to figure this out. Lucky I’m just that stubborn.

The corollary of concavity is convexity, where the payoff grows with success:

The cool thing about convex payoffs is that gaining success is more better than losing success is worse:

The romance of software development is the power of abstraction. If you’re building physical widgets, you can only get so much better at building widgets (concave). If you’re building software and you come up with a better way of building software (tool/language/technique/pattern/library), the only limits to improvement are the limits of human imagination (convex).

If I’m building software, I can build better and better quality, but the payoff quickly tops out for most applications. By building a better way of achieving quality (test-driven development) or a better tool for achieving quality (xUnit), the payoff grows such that greater success increases the rate of payoff (convex). The same is true for Jordan Walke and React or Christopher Chedeau and React Native. These are both severely convex projects.

Convexity is why software is eating the world. The more of the world connected to software, the greater the value of connecting the next bit of the world to software (convex). Good news for programmers, the greater the leverage of software the greater the leverage of improving software (doubly convex).

The message here isn’t “convex good, concave bad”. The goal is to maximize the accumulated slope of the payoff. If you’re in the steep stage of a concave curve, then you’d be dumb to switch to an uncertain, delayed convex payoff:

Be aware of both the shape and slope of the curve you’re on. When you get to the flat part of a concave curve, either raise the level of abstraction (build a tool, write a language, optimize your workflow, teach someone) to create a convex curve or find a different curve.

Back to the original motivation–what constitutes convex and concave projects? I don’t have a crisp connection between convex projects and responsive/network teams. Mumble mumble have to take more risks in convex projects and mumble mumble responsive/network teams can take more risks per unit time. Predictive/hierarchical teams are good at minimizing risks and mumble mumble matches concave projects. Know whether you have a convex or concave project, match team style, and switch from concave to convex before running out of money mumble mumble. That’s as far as I’ve gotten.