You are going to pay for bug fixes. And you’re going to like it.

The day is coming when you are going to have to pay to get bug fixes.  You won’t like it at first, but that is the way things are heading.  And you should like it.

I can remember the day when software came with free support.  You had a problem, you called up the company and spoke to a tech support representative who would help you with your problem.  For free.  For hours if need be.  It was expected.  Of course a company should support a product that they sold.  If it wasn’t easy to use or didn’t work right, they need to make good on it. 

You might, at this point, see where this is going.

Then, of course, economics caught up with the marketplace, and companies began to charge for support, sometimes upwards of $100 an hour. People didn’t like it at first.  But even that became uneconomical as the internet appeared, and people stopped paying for support when they could get free support on the internet.

I can remember the day when software came with a stack of manuals, sometimes two feet high.  Anyone remember the Borland C++ 4.0 box? It was so big it had a handle built into it.  (I looked for a picture of it, but couldn’t find a good one…)  Of course the company should supply physical documentation with their product!

Then, of course, economics caught up with the marketplace, and companies couldn’t afford to ship all that paper with the product, and the documentation became digital and shipped with the DVD.  Hard copy documentation fell by the wayside.  People didn’t like it at first.

I can remember the day when software came on DVD’s, and when you ordered a new version of your favorite software package, they mailed you a DVD with a nice case.  (Shoot, I can remember when they mailed you 3.5” floppies, but that’s another story.) Of course the company should send you a physical copy of the software.  You paid for it, damn it, and you should get a disc! 

Then, of course, economics caught up with the marketplace, and now, you don’t even get that DVD.  Instead, you get a download link for an ISO file and you burn your own DVD if you want a physical backup. Or you just download an installer.  More likely you simply stored the software file on a backup hard drive or, now, in the cloud.  People didn’t like it at first.

You definitely should see where this is headed now. 

Pretty soon now, we’ll all be looking back on the day when you actually bought a stand-alone license for your software, and you got bug-fix updates with that single purchase.  Of course a company should give bug-fixes for free – the product should work right in the first place, and so why should I have to pay to get bug fixes?

But the economics of that are going to catch up with everyone, and soon companies are going to stop selling licenses and start selling only subscriptions.  And in order to get updates – including bug fix updates — you will have to have a subscription.  People won’t like it at first. 

The future is already here for many software tools.  Adobe sells only subscriptions for their highly popular graphics tools.  Office 365 is sold as a subscription.  And if you own either of those, you are – surprise! – paying for bug fixes.  This is a trend.  Microsoft and Adobe are not small software vendors.  You will see more and more software tools being sold this way.  It’s inevitable, as economics and the marketplace do their thing and technology enables new business models.

A pause for some thoughts:

  • It’s a silly thing to believe that the complex software that you buy should be bug free.  No non-trivial software is bug-free.  All software is buggy.  Everyone knows this.  Developers, in particular, should know this.  Yet people still argue that the product should be bug-free and that they should be entitled to free bug fixes because they “paid for a product that should work out of the box”.  Well, I hate to break it to you, but no software “works right out of the box” and there is nothing that developers can do about it.  I’ll say it again:  all non-trivial software has bugs and there’s nothing to be done about that.
  • Even brilliant developers develop code with bugs in it.  Even a clairvoyant QA team won’t find all the bugs. 
  • All software development requires intense human labor.  Bug fixing requires intense human labor. Companies cannot afford to do things for free.   Good developers and QA people are not cheap. 
  • Thus, as we saw with free support, documentation, and DVD’s, something has to give.  And that something is the notion of “buying a single, stand-alone license” for your software.  It’s going to go away.  Software companies are slaves to the marketplace just like every other business in the marketplace, and they are being driven to a subscription model just like they were driven away from free and then paid support, as well as stacks of paper for documentation and DVDs for software distribution.

People won’t like this at first.  But they should. 

First, the overall cost of a subscription will be less than purchasing upgrades.  Subscription fees have so far proven to be a remarkably good deal.

Companies will have vastly more flexibility to add features on a more frequent basis rather than in yearly (or longer) upgrade cycles.  Companies that sell only subscriptions can also talk more freely about their future plans because – and I am mentioning this with great trepidation – they won’t have revenue recognition issues with regard to future-looking statements.

And yes, companies will be more motivated to fix bugs – perhaps even bugs in previous versions.  Because they will have a steady stream of revenue and because they will be off the “one big release” mentality, they will have more leeway to fix bugs.  Because they can bring features to market sooner than they might have before, they can spread the pressure of releasing new features over longer, less focused periods of time.  Removing shipping pressure increases quality. 

Some will argue that a subscription model incentivizes companies to care less about quality.  This is nonsense.  It will incentivize them to care more about quality, because there will be no more excuse not to increase quality.  If quality doesn’t increase, people won’t renew their subscriptions.  And companies will be very, very interested in renewed subscriptions.  Low quality will not be a good business model while providing subscriptions.  Since feature pressure will be reduced, quality can become more prominent.

Yeah, people won’t like this change.  You are probably firing up the comment dialog box as I type this.  But I think we all see the benefit of free internet support like StackOverflow, online documentation like wikis, and software downloads that get you your software immediately.  Those were changes that we didn’t like at the time, but that we see the value in now.

And so it will be with software subscriptions.  So, yes, you are in essence “paying for bug fixes”.  But bug fixing is both inevitable and costly.  However, you’ll also be getting more frequent updates, more frequent new features, higher quality, and more openness about the future.  You’ll always have the latest and greatest version of your software package.

Who doesn’t want that?

Trailer Hitches and Software Development

When I was in the Navy, I had a friend named Tom.  Not only a great naval officer, aviator, and all-around good guy, he was also a good husband.  And by good husband I mean that he modified his beloved Ford truck to include a tow hitch for his wife’s horse trailer.  It was a big horse trailer and he had to get one of those hitches that was attached into the bed of his truck.  It was a major change.

Being the wise man that he was, he went to get some estimates.  The first one he got was a reasonable price, but the second one was twice what the first one was.  Tom asked why, since the first price wasn’t small, and the second guy’s price was pretty hefty.  The guy said “Well, you can pay me to do it the right way, or you can pay that guy and then have your hitch rip off and have your horse trailer go careening off while you are cruising down the highway”.  The point, of course, was that there is an upfront cost to doing things right that can prevent even more costs down the road (literally, in this case). Needless to say, Tom went with the second guy.

“It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.” — Max Kanat-Alexander

This quote came from a book I read yesterday called Code Simplicity: The Fundamentals of Software
It’s a short book – I read it in a couple of hours – but it is a good one.  Full of wisdom about software development, it makes the point that no matter what, your software is going to change.  And when it changes, you will introduce defects, so you need to make it as easy as possible to change your code in order to minimize the bugs you introduce when changes occur and decrease the difficulty of adding new features. It’s a really good book – give it a read.

The bottom line of the book: – In order to manage complexity in the large, you need to code for simplicity in the small. Complexity is the key, and how you manage that will dictate the long-term success of your project.  It’s amazingly easy to create complexity, and it takes a lot of work to create simplicity.

So code is like the trailer hitch – you need to put your costs up front in order to avoid disaster in the future.  As Kanat-Alexander says – we need to put effort into the implementation of our code in the beginning so that costs are minimized during the maintenance period.  We need to plan for the long haul, designing our systems up front to be flexible and changeable and composed of simple modules.  You can build complexity by combining simple modules into a complex system.  Simple modules are easy to maintain.  You can also build complexity by combining complex modules, but complex modules are difficult to maintain.  

There is no up side to the “Get it done quick and we’ll worry about fixing bugs later” way of doing things.  “You can pay me now or you can pay me later” is how the old saying goes, and it’s as true for software as it is for horse trailer hitches. 

Targets and Estimations

We’ve all been there.  “How long will this take to get done?”.  The answer they are looking for is “by this afternoon,” but most often the real answer is longer than that, often much longer.  In fact, the real answer is “I don’t know”.  But you have to give an answer.  This is where you hear tales of people rolling dice or making something up or saying “six weeks” no matter what.  In the end, you can’t know for sure because you’ve never done that project before, and so you make your best guess and it works out somehow most of the time.

But a lot of developers and managers fail to realize that there are really two different kinds of answers you can give.  If it is Monday, you can say “I’ll have that done by Friday”.   Then you work like crazy, and just before you go home on Friday, you deliver what you promised. 

The other type of answer you can give is “That will take 40 hours.”  And so if it is Monday, and you say that, then the manager will hearI’ll have that by Friday”.  So then you go and you work like crazy, and just before you go home on Friday you deliver what you promised.   But when you’re done clocking all your time, you put in 50 hours to get the project done.  That’s a 25% overrun, and your manager wants to know what happened and why you took so long.

There are a lot of things going on here – but the point I want to make is that there is a difference between an estimate and a target.  An estimate – “How many hours is this going to take?” – is very difficult to get right.  There are always unknown unknowns that enter in to make the total number of hours that something will take.  We are notoriously bad at making estimates.  There are a lot of reasons for that, but the fact remains that we are not really capable of making accurate estimates.  But “I’ll have that by Friday” is easier to say because you have flexibility in the amount of work it takes to hit that target.

But note well that an estimate is not a target.  A target is when you say “I’ll have that by Friday”.  Saying that on Monday morning is not the same thing as saying “It will take 40 hours to do”.  In fact, it’s a very, very different thing.  Saying “I’ll have that by Friday” actually means “I’ll do whatever it takes – put it however many hours it takes – to get this done by Friday.”  It might take 20 hours.  It might take 60 hours.  But you didn’t say anything about how many hours it would take, you gave the target point when it would be delivered.

So if you are a manager, recognize the difference between a target and an estimate.  If you are asking for an estimate, understand that software estimation is still something even the most seasoned developers do very poorly.  If you are asking for a target, realize you may be asking someone to put it a lot of hours to hit that target.  Or not – maybe they say “Friday” and it only takes half an hour.  Who can say for sure?  If Friday is good enough, then you shouldn’t care how many hours it ends up taking either way.

And the one thing you shouldn’t do is ask for an estimate, take it as a target, and then get upset when the developer hits the target but runs over on the hours. 

Targets are not estimates, and estimates are not targets.  Understand the difference, and you’ll have happier developers and happier managers.