When creating software, the top priority is that it works.
Sometimes, this may be the only priority. For example, suppose you are creating a process that automates TPS reports for your employer – a local widget manufacturer. This process will save 100 employees about an hour a month. If these employees cost an average of $30/hour, then this program will save your company $36,000 per year. Nobody cares that you wrote the program using a really, really cool data structure. Nobody cares whether you wrote it in C# or C++. They only care that you have justified your existence for the moment by saving the company $36,000.
But if you are creating software that you want to sell to a third party, that third party is going to judge you – rightly or wrongly – on how polished it looks. Well-polished software says to the person evaluating it that you have a commitment to maintaining it and that it is a reliable and mature product.
So here are some of the things you should do to polish off your software before releasing it:
- Test the software. It never ceases to amaze me the number of times I run supposedly ready to release software and there is an obvious bug that if anyone – even the engineer who developed it – had clicked the button, they would have found it. Software bugs are understandable – they will happen, no matter how hard you try. But finding obvious bugs is a big turn off.
- Spell check. Engineers are notoriously bad spellers. Spell checking a website is reasonably easy (there are a gracious plenty online services that will spell check your website for you). Spell checking a thick-client application is a bit more difficult – but if you are using string resources for your message boxes, that gives you a nice XML file that you can spell check.
- Use progress bars for processes that are expected to take more than a few seconds. We live in an instant gratification society – dinner cooks in four minutes (rotating once midway through cooking time) – and we easily become impatient with processes that take longer than we expect. You can buy yourself double the processing or loading time if you add a progress bar.
- One of the simplest ways to give your thick-client application the appearance of maturity is to use custom icons. Few things scream amateur hour like seeing the standard Visual Studio icon on a form. If you don’t have the resources to create your own high quality icons, you can contact JASE for help with your identity management. If you are not ready to make that investment, there are plenty of free/cheap resources out there. The Open Clip Art Library consists of almost entirely public domain artwork. Wikipedia has a collection of icons. If you are using Visual Studio, they give you a library of icons in the “Common7” folder under your installation directory.
- Don’t release your software before you are ready. When that 0.7 alpha release crashes every five minutes, you will have formed a lasting impression on your potential user base – you never get a second chance at a first impression.
image credit: Sanja Gjenero