The Perils of Software Development

I’ve been in the computer industry for more than a decade. I’ve heard all the complaints about software support, all the bug reports, and all the grumbles about the evils of the big bad software companies.  Some of it I understood – but some I did not, until we began developing our own software. It has certainly been an education, and has deepened my appreciation for those who donate their software freely to the open source community.

First of all, software development is difficult. Only a fraction of the coders who start out to create a moderately complex piece of software actually finish it. Because it is often hard to figure out the best way to accomplish complex tasks. It is usually easy to write the first part, but like publishing a novel, all the final editing, testing, bug fixing, etc, to even get it reasonably stable, is a very time consuming, tedious work. The fun wore off LONG ago!

Of those that finish an application, even fewer choose to release it to the public. See, you can write a little piece of software for yourself, and get it working in your environment pretty easily. But once you release it and let other people use it, three things happen:

1. It now has to work in THEIR environment. That means on their operating system with their browser, or with their server configuration, etc. And individual settings, other applications running alongside, etc, can change the stability of the software. This is why software goes through beta testing, multiple release candidate stages, and why version 1.0 is invariably buggy. It just takes time, and actual use, for bugs to show up under a wide variety of usage environments. Bug fixing takes a tremendous amount of resources.

2. As soon as people get their hot little hands on a simple little app that was designed to just do one simple little thing, they want it to do MORE! And MORE, and MORE! They are simply never satisfied. Feature requests POUR in. Every person who uses it wants to use it in just a little different way. So you make an attempt to meet the reasonable requests, which sends your development costs through the roof – you not only now have bug fixing going on, you also have new features to write and test, and then bug fixing on THOSE.

3. Then, you have SUPPORT. You write a manual, that explains everything, and figure people will read the manual, follow the instructions, and things will work, right? Wrong. A good many people simply won’t read. A good many people who WILL read, won’t get it. And a good many people who do follow the instructions will make simple errors as they do so – typos, mixing the up order of tasks, or other simple mistakes that cause problems. And they’ll call YOU when it doesn’t work. You HAVE to help them – because you nor they really know whether it is human error or a software bug causing the problem until AFTER you’ve helped them. Support tends to be very high with new software – it can take more time than the actual coding. You have the choice of either NOT including support (or making it a paid extra), or of pricing your software to include a reasonable amount of average support time (and hoping that reality does not exceed that average). We would love to sell our auto-installer for less, but find that we cannot, because it just requires too much support, and if we priced it lower, we’d go broke.

It is simple for a project to positively explode with new coding and troubleshooting demands, to the extent that a coder, or even a coding team, can end up overwhelmed.

We like to think of the software companies as the “bad guys” for making it so hard to get support. We like to think they don’t listen to bug reports, or feature requests. Actually they do – but in order to contain costs, they’ve simply turned a deaf ear to certain classes of complaints or requests, and they’ve put up barriers to calls from people who simply don’t want to read the manual. Support time is costly, and it shaves off the profit margins if not controlled, and can put a company in the red pretty fast.

We’ve released three pieces of software in the last year, and are in the process of improving one of them, after which we will be releasing three more pieces. It took six months after releasing the first to reach critical mass – we could no longer go forward with bug fixing, improvements, AND support on one piece, and have any time left for new development. So we took steps to contain support, we finished off some bug fixing and put a feature freeze on one major piece. Then we focused on getting to that point with the other pieces. Without doing that, we’d never have time to develop anything else.

We found that each piece of software goes through some phases that affect costs.

1. New release. The bug fix requests and feature requests pour in. You have to determine in this stage what IS a bug, and what is not, which situations you’ll support, and which you won’t. You also have to determine which feature requests are reasonable (enough people will want it), and which are not.

2. Stable. Bug fixes and feature requests decline, but support continues to slowly grow, in spite of containment, due to increasing numbers of customers.

3. Compatibility Changes. Just about the time that your software is stable and predictable, part of the operating environment changes. The computer operating system, browser, or other dependent applications will upgrade, throwing your software into another series of malfunctions, and bugs. New features in dependent applications may make new possibilities available for you, resulting in new feature possibilities. Long term, this can be a huge drain on resources, and is a primary reason why most companies charge for new versions, or offer support for only a limited time after purchase.

It is not easy. And you find that when you are trying to be the good guy, many people will be angry with you anyway. If you do your best to offer good support, people will complain anyway. If you price fairly, there are those who still want it free. If you lower the price and lower support, people will complain about the lower support. If you release a lower priced version with fewer features, they’ll complain about not getting all the features for the lower price. Most users simply never consider how much time development, support, and improvement actually cost.

I think the Open Source community has influenced some people to think that they OUGHT to be entitled to receive everything they want free. Sensible people know better, but a lot of people think that anyone who charges for software is evil. We found that with our auto-installer. And then on the forums, we saw a rash of people promising to deliver an equivalent free. They’d promise and promise, say it was just about done, then they’d disappear. They found it was much harder than they’d anticipated to even accomplish the first step in the process, let alone deliver a fully functioning, feature rich piece of software capable of doing what ours does. But the prospective users still clamor for it anyway.

I don’t regret our foray into it. Indeed, this is a large part of the future of our business, and holds the promise of providing a significant percentage of our income. But it does require that we adapt to the reality, and that we be committed to a customer base in spite of some very real difficulties.

It isn’t as easy as it looks!

Check out our new Cottage Industry Consulting and Development services at CottageIndustrialRevolution.com – Services include consulting for software development businesses.