Flotsam and Jetsam #102

  • Wallace and Gromit run on Delphi.
  •  I of course want you to buy my book, but I have been doing research for my next book and am thus reading sections of Delphi XE2 Foundations.  I can’t recommend this book enough.  It’s a tour de force for Delphi and the RTL.  I know how hard it is to write a book, and I can’t imagine how much work this one took.  It’s excellent, and I highly recommend it (after you buy my book, of course….).  Don’t be put off by “XE2” in the title, this is a great book for all Delphi developers.  Kudos to Chris Rolliston.
  • I’ve never really gotten into Quora, but it seems like a pretty cool site which has somehow managed to produce quality questions and answers without all the spam and other nonsense that often attends such a site.  Here’s a Quora question about Delphi that many of you might like to answer and/or read about.
  • Yesterday, I tweeted the following:  “Of all the types of reviews out there, the  ‘I couldn’t understand it so it must really suck, 1 star’ reviews are my favorite.” In researching my book, I’ve been re-reading Dependency Injection in .NET
    by Mark Seemann.  I looked up the book on Amazon, and was astonished to find that someone had given this amazing and enlightening book a 1-star review.  Some people, I swear.  This review is more along the lines of what the book deserves.
  • Correction:  Apparently, it was Borland C++ 3.0 that was the big box with the handle.  Thanks for the correction from Jeroen Pluimers, who also found a picture. (You have to scroll down a bit, but it’s there…)
  • A Clarification:  Two points to make on my last post about subscriptions.  First, it wasn’t about EMBT, but rather the software industry in general. Second, the point wasn’t “Software subscriptions are great!”, but rather “The industry is moving to subscriptions, and here’s why”.  Many folks seemed to believe I was arguing the former.  Perhaps I was just inarticulate.  Sorry for any confusion.

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?

Fun Code of the Day #1

 

Flotsam and Jetsam #101

Flotsam and Jetsam #100

  • Well, here we are; one hundred Flotsam and Jetsam’s.  I started this series just after I left Embarcadero. Here’s a link to the very first one on July 17, 2010.  Short and sweet it was.  Took almost five years to get here to one hundred.  Thanks for hanging with me.  Here’s to another 100, eh?
  • Delphi XE8 is out. The main feature appears to be the Apple-mandated 64-bit iOS support.  It has Castalia integration as well as an interesting new tool called “GetIt” that will install a various – and presumably expanding – list of third party component sets and frameworks.  That’s pretty nice.  The Data Sheet can be found here and the Feature Matrix is here.  Give it a look.  “Support and Maintenance” is now called “Update Subscription”  which has the following interesting text in it:  “…on-going maintenance on previous versions for up to 2 years from release..”   That sounds intriguing. There is also a tool to migrate your settings  from previous versions.  I know I’ll be using that. Here’s the list of new things in XE8 – it’s pretty long.
  • SD Tmes has a review of RAD Studio XE8.  Lots of talk about IoT – “The Internet of Things’”.  And here’s the article from The Register.  My favorite quote from that article: “I ran up the RAD Studio XE8 IDE and one obvious benefit is the speed and responsiveness of the IDE compared to Visual Studio.
  • For some reason, VCL developers always seem to feel slighted by recent releases.  No reason to feel that way, though:  Marco has a nice list of things for VCL developers in XE8. I especially like the improved TField performance.

Flotsam and Jetsam #99

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.