Last week I published an article here entitled “LandlordMax’s Most Challenging Bug” which received lots of comments both online and through personal emails (probably more people sent emails than commented). One thing that really struck me was the difference in thinking between people who run a business (from small ISV owners to managers) and technical people (developers, architects, etc.). Based on their background the solutions varied substantially. I’m not talking how to tackle the problem technically (btw there were some great tips and information being shared, thank you!), there was no doubt there was a lot of variation here, but I’m talking in terms of what types of solutions made economical sense.

What really struck me is that most developers completely ignored the cost to benefit side of the equation! I’m not saying that you should always base your decision on cost to benefits (I don’t want to acquire design debt for example), but sometimes this becomes a strong factor in the decision making. This is something that I use to lack, I always wanted to get in there and find the correct technical solution. The reality is that sometimes it’s not the right thing to do. This is a hard pill for technical people to swallow. I know it use to be for me. Not so much anymore being a lot more on the business side of things, but in the past it was a common issue.

Using my last article as a basis for this argument, let’s look at the cost to benefit of different types of solutions. Not actual solutions, but cost to benefits of the types of solutions. Rather than share my actual numbers, let’s just round realistic numbers to make the calculations, it’ll be much easier that way. So our first assumption is that allocating a developer to a task for 1 full day will cost $1000 in immediate salary. We should of course add in the costs of benefits, hardware, software, training, testing, etc., but for now let’s just say it’s $1000/day for a developer. Now remember this cost does not include any testing!

Ok, now I’ll assume that our fictional company makes $1 million in revenue a year, a simple round number. Assuming we have a unit price of $150 per unit, then this means we sell 6667 units per year.

Now before I proceed, let me backtrack a little. For those of you who are interested, you can read the full article here. However, just to get everyone up to speed, here’s the quick version. We found a bug in LandlordMax regarding how it reads certain types of JPG images. This bug is also present in many larger software application such as Internet Explorer and FireFox, so it’s not a simple solution. Also, images aren’t part of our core functionality. Don’t get me wrong, they’re a great feature, but we didn’t have them in the first 3 major versions. Now the problem is that we have two solutions, one that’s quicker to implement and one that isn’t. This problem only affects 0.05% of our total customers, and of those 90% will be satisfied with this solution. The other solution is complex, will take more than a week or two, and probably won’t fully work (IE and FireFox with very large resources still don’t have it full working). This solution will satisfy 90% of those customers too, possibly more.

Using these parameters, we can see there are two sides to this coin. Most technical people will want to fully solve the issue, to get it right. Yes the costs are high, but let’s do it right. The business side want’s to see what’s the cost to benefit. Now just a quick side step, you have to remember that you can’t always just look at the cost to benefit otherwise you’ll get so far into design debt that you’ll eventually kill your company. However, in this case, we’re not very likely to expand on this issue once it’s solved so it’s very unlikely that we’ll add any design debt no matter what solution we decide.

In any case, let’s look at the two solutions.

Solution 1:

An acceptable solution to the problem which will take about 1/2 a developer day, padded to 1 full day for safety. In this case, the cost is $1000. Now if we calculate it terms of cost to benefit, it means we’re paying $1000 for 0.05% of our 6667 customers, or 333 customers. On average, this means that we’re paying $3.33 to add this solution for these customers, of which 90% will be ok with the solution. The remainder would like a better solution but will probably live with it since this is only a small part of why their using the software, after all this is not the core functionality of the software. Also remember that these few people who are used to using this type of image mode also use to having this issue with a number of other major software applications. So it’s nothing new.

Solution 2:

We provide as best a technical solution as we can, knowing that we probably won’t be able to solve it fully as other software companies with budgets multiple orders of magnitude bigger larger than our total revenue can’t solve it. We’d be lucky to spend only a week, probably 2 weeks, and this might only reduce the number of people facing the issue by a percentage. But let’s be optimistic and say that we’ll solve it for 90% of the people who use this image mode.

Then in this case, we’ll spend 10 developer days, $10,000, to solve it. This means that it costs us $10,000 for our 333 customers. On average, this means we spend $30 per customer on this solution alone. This is now a significant percentage of the purchase price (20% of the total purchase price for fixing a small bug). But again, remember that it’s only for 90% of these 333, so we’re only really solving it for 300 people, bringing our per customer solution price to $33.33, or 22% of the total purchase price. We still have to deal with the remainder 10%, or 33 people. Assuming we use solution 1 for the remainder, this now brings up our price to $11,000, $10,000 for the initial solution and $1,000 for the remainder. Our total price per customer is now $33 for just this bug fix, or 22% of the total purchase price.

Which Solution is Right?

Which of these two solutions would you be more inclined to implement from a business side? What about from a technical side?

From a technical side, at least from my experience, we always want the perfect solution. But from a business side, it makes a lot more sence to go with solution 1. And don’t forget, solution 2 is probably a lot more costly than we estimated, it might take us a month, maybe two, or what if it’s a never ending series of issues? If the solution takes two months, which is not so hard to imagine once you see how Mozilla (FireFox) solved it (and that’s not even fully working), that brings our cost per customer to approximately $120 per customer. We’re now at 80% of the total purchase price for just one bug fix that’s not critical! Yes it’s only a portion of the customer, yes we could amortize it, yes we could calculate in the total lifetime purchases of the customer, and so on. But looking at the numbers when the first scenario is perfectly acceptable, I just can’t see how I can justify scenario 2.

As a developer, I can easily find ways to justify solution 2 such as design debt, etc. But from a business perspective solution 2 makes no sense!

UPDATE: Now add to solution 1 the fact that we now have an additional 9-10 developer days to add more features and benefits to the software. Let’s say we can increase our sales by 2% by instead allocating this same developer for the time difference to a new highly requested feature (maybe it’s only 1%, maybe it’s 10%, in any case, we’ll just use 2% since it’s easily feasible). If that’s the case, we can increase our sales of $1 million to $1,020,000, or by $20,000. Now not only have we paid for our bug fix, we’ve also paid for our developer and made a profit!

And the thing to remember here is that we’re not just helping 0.05% of the people (which we are), we’re also making 100% of the all our customers happier with a new feature (well maybe not 100%, but a much much larger percentage than 0.05%) that they wanted!

---

Permalink to this article          Discussions (13)

---