Business versus Technical Solutions
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!
· October 23rd, 2006 · 1:33 pm · Permalink
“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.”
Sheesh! Most developers can’t even understand simple cost/benefit ratios (except when it’s in favor of their chosen technical solution… funny how that works). Now you’re throwing opportunity costs into the equasion. 🙂
· October 23rd, 2006 · 1:50 pm · Permalink
Yeah, I didn’t want to use the exact term, but the opportunity cost is very crucial to the decision making process.
And in defense of developers as I was one, and often still am one, it’s hard to look past just finding the best solution. You want to solve the problem to the best of your abilities, and this is often not the best way to tackle the solution as we’ve just seen. You want the best solution for everyone, to make the most people happy.
The majority of the suggested solutions I received were great, were very intelligent coming from very intelligent people. It’s just that I rarely saw anyone look at the cost/benefit side of the equation, with a few exceptions of course…
· October 23rd, 2006 · 2:46 pm · Permalink
Do you mean 5% or 0.05%? 0.05% of 6667 is actually 3.33 customers, so the cost per customer even in scenario 1 is $333.33.
· October 23rd, 2006 · 3:02 pm · Permalink
Hi Chad,
You know what, you’re absolutely right!!! I did * 0.05 where I should have done 0.0005 (just out of habit). You actually brought the point home even more! Now the bug fix is costing twice the price of the software. If you look at total lifetime of customer, assuming upgrades are discounted 50%, then you need the customer to stay with you at least 3 years to break even. And that doesn’t include the cost of acquiring the customer (marketing), or supporting them (technical support, etc.). And this is just for one bug fix. If all bug fixes were like this, you could easily bankrupt a company.
· October 23rd, 2006 · 9:12 pm · Permalink
If you do these sorts of analyses and follow this logic, you quickly find that fixing almost any bugs is uneconomical. Then you have a buggy product, reviewers deride it, and your competitors with code that ‘just works’ clean up in the marketplace. Not that that isn’t a good thing of course.
· October 24th, 2006 · 4:50 am · Permalink
Why not just document the issue and describe a way to rectify (i.e. re-save a CMYK JPG as RGB)?
· October 24th, 2006 · 12:26 pm · Permalink
Hi Scott,
Yes, you’re right that only using this logic can make many bugs uneconomical. However once you start to factor in other costs such as design debt, this quickly changes the equation.
The main difference with this bug was that the solution appeared to be VERY xpensive (just look at the size of Mozilla’s implementation and they didn’t even fully solve it. I’m sure there’s a lot of hours involved in this solution alone with a lot of different experts (open source).
Now considering the massive expense for the small payoff, it doesn’t make much sense… Normally bugs aren’t nearly that expensive to fix, and those that are, are generally due to other underlying issues that need to be resolved anyways.
· October 24th, 2006 · 12:28 pm · Permalink
Hi Jo,
That’s very close to what we’ll do. But documenting it alone isn’t enough for a shrink wrap public application. Imagine if Microsoft Word just documented such bugs? You also need to provide the user with feedback, show where the error occurs, provide them with a way to solve it, make it very friendly, and so on…
· October 24th, 2006 · 12:52 pm · Permalink
As a hard core developer, I would have voted for the “scan the header for color model” solution I proposed, but that’s only because I’ve already implemented that functionality myself for other project (you guess, Java imaging projects, not real estate software) and would do it by reusing my own library. Thus, the header check would be only twenty lines of code pasted from other project and an additional .jar file in the project, plus testing.
If I were in Steph position, I’d hate to spend my money in applying the “right” fix on to something that is affecting a small user base and adds little value to my software. I agree with Steph in this case.
· October 24th, 2006 · 1:01 pm · Permalink
Hi A Reader,
Your comment is VERY interesting for me. You pointed exactly the situation in which I think it’s appropriate. And not only that, knowing the effort, you mention that it’s not worth it in my situation. That’s very interesting coming from someone who’s gone through the effort!!! Thank you for your comment.
Btw, do you mind if I ask how much total effort it took you to implement that functionality? Where my estimates in-line with what reality, assuming of no initial knowledge of how JPEG’s are encoded?
· October 25th, 2006 · 12:57 pm · Permalink
$1000 / day in salary? Let me send you my resume!
You are also forgetting that not fixing the issue does not have $0 cost. You are paying tech support people to answer this question every time it comes up. You need to either spend time training them on this issue, document it and train support how to find it, or ignore it and pay for them to learn on their own when they hit it. You have the cost of management spending time evaluating options, discussing, and deciding not to fix this – usually this involves several people who make more than developers. You have programmer time spent everytime a bug report is filed doing research to decide if it is the CMYK issue or not (can be significant if there is a bug with similar symptoms or in the same area).
And then you have the full $1000 cost of developer time if you ever change your mind and decide to fix it later.
Better to just spend 1 day developer time, especially if you have the developers, and they aren’t working on anything higher priority. Otherwise, just queue in your bug tracker as a low priority item, and let it work its way through the process.
· October 25th, 2006 · 2:41 pm · Permalink
You’re absolutely right, leaving a known bug in a software application definitely has a support cost element to it! No doubt about it. As well, like you mention, there are other hidden costs such as management, project planning, etc. These do add up quickly.
As for putting the full solution as a low priority bug, to be honest I like to close off bugs if I can. We’re still a small company with lots of growth, and especially lots of growth in terms of application features. We already have more than 5 years of features development planned assuming our current resources, and several more in the pipeline that we know we can’t get to until then.
Not to mention the fact that we receive a lot of feedback from our current customers, and prospects, asking us for other new features! We generally try to implement to most requested features first, and the list is very large. There’s never a quiet moment here, and that’s what I like about smaller companies 😉
· December 19th, 2006 · 9:04 pm · Permalink
[…] Ok, so getting back to our calculations, assuming about 200 workdays, and assuming 1 hour is lost each day, that represents 200 lost hours of labor. But before I go on, I’ll just take a minute to talk about the cost figure I’m going to use for a developer hour. In a previous article I used $1000/day per developer, which caused some people to comment that this was too high. The reality is that this isn’t too high from the businesses perspective, this is the cost of a developer. The developer won’t receive $1000 in salary, they’ll just receive a portion of that. What you have to remember is that the business also has to pay for the employees benefits, real estate (for example IBM saved $700 million in real estate costs by having workers work from home), hardware, software, etc. All these things quickly add up! […]