Code Underwriters

Lloyds of London is able to do what they do thanks to the concept of underwriters. The simplistic version is that a risk is spread amongst a group of underwriters. If nothing goes wrong they get a cut of the profits relative the the percentage of the risk they took on. If things go wrong they take pay for whatever portion of the risk they agreed to take on.

It occurred to me that being a software developer is in many ways like being an underwriter, except, in most cases, without the big payoff. You see, each developer on a project tends to take responsibility for a portion of the code-base. We talk about spreading this responsibility around by increasing the bus count but the fact of the matter is that this rarely ever happens.

Most code-bases tend to be divided into sections each with a bus count of one or two. When something goes wrong the developer(s) responsible for the responsible piece of code are generally expected to do whatever it takes to make it work now. In some cases this means being woken at 3AM, hauling your butt into work, and remaining there until the bug is squashed. Just like an underwriter at Lloyds, the more risk you take responsibility for the more screwed you’ll be when things eventually go wrong. Unlike a Lloyds underwriter we don’t get a cut of the profits relative to the amount of responsibility we take on.

It is, obviously, quite debatable just what portion of the profits would constitute a “fair” portion of the profits, but in general we just get paid our salary. The first employees of a company frequently do get the payout, but most developers aren’t them. I’ve also heard tale of magical things called “bonuses” but it seems rare that developers actually get them or that they’re enough to buy you more than one box under the Christmas tree if you do see them. So, for the most part, we can treat these things as non-existent, which brings us back to our salary. Which is, in many ways, like insurance. While you don’t get a huge portion of the profits, you do get a guarantee of sorts from your employer that you’ll continue to get paid well even if things don’t work out. Which makes your employer a fellow underwriter in the development of your software.

There are three things that need to be underwritten in any given software project: The effort that will be required to fix things when they break, the money that will be required to finance the fixing of broken things, the money that will be required to finance the creation of potentially broken things. There’s also the money required to finance the project(s) needed to compensate for the projects that didn’t bring in more money than they cost to create and/or maintain but that’s a bit too recursive for this example.

From a financial standpoint, I think it’s understandable why developers don’t get a larger cut of the profits. While the worst case scenario for us is rather unpleasant, it’s also very short lived. But, we still get paid quite well during all those months and years when the project wasn’t bringing in anything notable, and even when it tanks.

Unfortunately developers are human, and humans are emotional creatures. We tend to not pay attention to the thing that are present in our every day lives, like regular paychecks, and focus on the atypical large events. Like having a fear of flying. If you’re afraid of flying then your brain is not paying fair attention to the boring everyday fact that millions of people are whizzing about the skies without any problems. It’s just that when a plane goes down it does so in such an atypically spectacular way, and that’s what we focus on.

So I’d like to propose a couple things for my fellow code underwriters to help mitigate our risk, and thus minimize the atypical large events and bring our perceptions more in line with the small portion of the risk that we’re actually taking on.

• Write your tests: unit, integration, and system. It’s like getting underwriters for the risk you’ve underwritten yourself. They’ll put in the hours of work patrolling your code and making sure it isn’t broken so that you don’t have to put in the hours fixing the code later.
• Increase your bus count. The bigger the bus count the more people you can throw at the problem so as to fix it faster and / or the greater the likelihood that the problem can be assigned to someone other than you.
• Practice Defensive Development. You don’t wear a bicycle helmet because you’re afraid of falling over. You wear a bicycle helmet because you’re afraid someone else will make you fall over.