weblog.masukomi.org

Code Underwriters August 31, 2007

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
bust 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.
  

Popularity: 2% [?]