Owen on software

What if we made developers pay for their bugs?

16 April 2012 - Comments

Pulled across from my old blog.

But really, what if we did, or could? It’s an interesting thought right? I’ll come back to bugs later, because what I want to talk about is the heart of the issue – what is the real cost of software?

Writing software on credit cards

Studies have shown that people will spend more on the very same item when paying on credit cards than they would if paying by cash. In short, willingness to spend increases with our distance from physical money.

I think the same is true for many of the decisions we make during the software development process. Have you ever worked on a project where the cost implications of decisions were regularly taken into account at the developer level?

I’d suggest that most developers, and probably a lot of managers, are blissfully unaware of the cost implications of their everyday choices. For the most part, this isn’t their fault, we simply don’t track and quantify real cost for development teams.

Time = money

I know what you’re going to say, ‘we track and estimate the cost of our development in time’. However, I think there are two fundamental problems with the way we generally approach this.

Firstly, I don’t think that gives the full picture, because most of these time costs only include developer time. In the real world, each bit of software you cut includes at least the following:

  • development time
  • test time (some factor of the size/complexity of the work)
  • management time (x% overhead)
  • release time

and it is these costs that often are not factored in.

Secondly, time equals money, but that’s not always clear. Time is too far removed from hard cash to make the cost real to most of us. It’s too much like shopping on credit. Time feels free to the average employee. When we spend it, it doesn’t feel like we are spending money.

What if we costed the software we develop?

Okay, sure we can’t necessarily calculate and expose the true cost due to a few factors:

  • variance in salary
  • disclosure of salaries
  • complexity of determining an exact cost

However, even a guide price would probably give us food for thought, and achieve the same end. For instance, we can get around salary disclosure by providing a cost for the average developer/tester/manager hour.

Would we build the same things? Would we build the same way?

I’m convinced we’d make more cost effective decisions and solutions, if we had this kind of information available at lower levels in organisations.

People would be better informed. They’d understand the cost implications of their decisions. They’d understand the ‘minor’, and possibly unnecessary, change they are suggesting would cost £5k. Maybe they’d think again.

Also, it would encourage good investments. Maybe you’ve got something in your process that’s not ideal, it’s slowing you down and needs fixing. If you can quantify how much it’s costing then you have a much stronger case for investing time (= money) in fixing it.

… back to bugs

What if we really could make developers pay for their bugs? Or at least, what if we could make them aware of the financial cost of the bugs they wrote this month? I’m pretty sure people would be motivated to write fewer bugs.

There’s the financial incentive end of the spectrum, where you could provide a bonus from which the cost of each defect a developer wrote was deducted. Ouch! That would definitely reduce the number of bugs written. Obviously, you’d want to make sure people weren’t discouraged from writing code!

At the more practical end of the spectrum, you could just run a dashboard, showing people the cost of their bugs. For most people that will be a significant incentive. That still leaves options for distributing pay and bonuses more favorably to your more cost effective developers.

However, that said, for me, the most powerful motivation for costing software development would not be related to remuneration, but would be to change and improve the way we develop software.

I really don’t think we would build the same things, the same way, and make the same decisions if we understood the true cost of software.

Tags: Ideas


comments powered by Disqus