Once you release the first version of your software product and the marketing machine is starting to roll on, you might think about what to do next. You probably think about all the great features which haven’t made it into the 1.0 and are now waiting to be implemented. You can’t wait to start your editor and start hacking right away. But wait! Think twice about what you do next, because adding features to software is quite different after you released it.
Ever wondered why Microsoft is so successful? It is widely known that they had really buggy releases in the past. And it is also known that many products of their competitors are of the same or even better quality. But today they are the biggest software company in the world and this is obviously a big accomplishment.
Besides great marketing and delivering products the users want, they are known for keeping their software backward compatible. They go to great strength to guarantee that applications still work on newer versions of their operating system, even when they have to work around bugs in the original software application.
And for Microsoft, this makes sense. Imagine people cannot get their favorite game or instant messenger working on a newly released version of Windows. People simply won’t upgrade to the new version. It’s already hard enough for Microsoft to convince people to buy new versions of Windows. This wouldn’t work at all if people couldn’t use their favorite application.
And Microsoft is really good in providing stable and compatible APIs to make Windows backward compatible. When we developed SmartInspect, we mainly tested it under Windows XP during development. When the release deadline came close and we tested SmartInspect under Windows 98, ME, NT 4, 2000 and 2003, we only found one (1!) bug that was related to different behavior of the Windows API. And that bug was only there because we used the API in a wrong way.
I’m not eager to start a flame war about the best operating systems here, but the unstable and incompatible API is one of the big problems with Linux. I really like Linux and we use it a lot here at Gurock Software, but we currently cannot imagine to ship a product like SmartInspect for it. It is just too time consuming and expensive to maintain so many different versions for the different distributions. You cannot guarantee that a program developed for one distribution works on another. In my opinion that’s one of the reasons why Linux doesn’t play a big role in the desktop market. Except when using scripting languages, it’s simply not economical to maintain a software product on different Linux versions and distributions.
Translated to the normal software business, this means you should take care when designing future releases of your software product. Always try to stay compatible with older versions of your program. This is especially true for component or library vendors. When upgrading to a new release, it is normally not acceptable that existing customers need to change a lot of their code only to use your new version. It’s in your own interest that your customers upgrade your product. If they don’t upgrade, you won’t receive any additional license fees and you have to support older versions forever.
Of course, no program is perfect and it is very likely that some future change will break compatibility in some way. But if this is the case, you should at least find a way to keep the efforts to upgrade as small as possible. Think about adding an auto converter if you change the format of your configuration files or keep old methods in your library and mark them as deprecated instead of removing them completely, for example.
Listen To Your Customers
One of the great aspects when your software goes public is that you get more feedback. If something is missing or not working as expected, your customers will tell you faster than you can fix or implement it. Some feature requests or bug reports might be surprising, something you never thought of when you developed your software. Others are more expected.
Whatever customers report, keep track of it. If you have many requests for a particular feature and it seems logical to implement it, then look at it in more detail. You should also try to find similarities between the different feature requests and then choose the best way to implement it. Try to bring your software to the next level based on your customer suggestions.
But don’t take this too far. You can’t implement every feature a customer asks for. Declining certain feature requests of customers may be hard at first, but do yourself and your customers a favor and tell them if you don’t intend to implement a feature. It’s simply unfair to promise any feature and then not adding it. This might even damage your reputation as unsatisfied customers are usually more eager to publish their opinion about you than satisfied customers.
When it comes to bug reports, take them serious. You should think of fixing them first before adding new features. There’s nothing more annoying than a buggy program. Of course, some bugs are more important than others and you should obviously concentrate on the high priority ones. Really unimportant issues can surely be deferred or even be ignored.
Carefully Choose New Features
Once you have a list of features you want to add, you should look at them in more detail. In my opinion, it’s usually a good idea to look at the usability improvements first. Normally those things are easy to change or enhance and they add a great value to your product.
Try to put yourself in the position of a customer who uses your product on a regular basis. What can be done to improve the workflow? Concentrate on those little annoying things, like missing shortcuts or combo boxes which do not remember entered values and so on. It’s really annoying when a power user frequently uses a certain feature of your program and there’s no shortcut for it. And do not forget that the power users can be your evangelists if they are really enthusiastic about your product.
There are more things to pay attention to. Think about improving your documentation. A detailed and useful documentation can save you and your customers a lot of time if it’s so good that there’s no need to ask you how a specific feature works or how to use it. When it comes to bigger changes, verify if they are really worth it. They need to add real value to your program. Don’t add any features if they are not going to be used anyway.
Take Up Time to Release
You should always plan to do a comprehensive testing phase before releasing a new version. You don’t want to release a version that has more quirks and bugs than your previous one, do you? Carefully test new and old functionality. Think about possible side effects your changes might cause.
A good idea is to use automated tests. This way you can always easily ensure that old functionality still works as expected after changing your code. This is called regression testing – verifying that a previously working feature still works correctly after adding new features or fixing bugs.
There are many areas where test automation is difficult or impracticable. Think of interactive programs, like GUI applications. There are programs which can be helpful in those cases, but it is really time-consuming to develop the test cases and they are often obsolete and stop working when you change some details in your user interface. There are other areas where test automation is much simpler. You can usually create nice automated tests for software libraries and components by using one the xUnit Frameworks.
At Gurock Software, the testing phase is of special importance. SmartInspect contains a set of libraries which our customers normally deploy together with their applications. We work hard to make sure that there are no critical or show-stopping bugs in the libraries which could influence the applications of our customers. Therefore, we created lots of automated tests for the libraries which are regularly executed on all supported platforms.
The tests for the graphical viewer application of SmartInspect, also called the Console, are currently not automated. However, to ensure a reliable and robust behavior, we wrote a large test plan which we process when a release knocks on the door. Although this test plan is divided into a platform independent and platform specific part, it takes a lot of time to execute. But we think it’s worth the trouble.
I hope that I could clarify the important aspects to pay attention to when thinking about enhancements for existing software products. In my opinion, one should think twice about what to integrate in future versions as there is much more to consider once a software product is released. If you have any questions or comments, feel free to contact me at email@example.com.