Professional Software Consulting

"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."

- William A. Foster

How should one judge the quality of a software application? Are ones of high quality those that stay up and do not fail? Or are they those with the most visually impressive screens? Perhaps they're the ones that are the easiest to use, the quickest to learn, or provide the best error handling when the inevitable mistakes occur. Maybe high quality software is simply that which makes your job easier and less stressful. In truth, there are almost as many ways to judge software as there are people.

While everyone wishes that their application exhibited all of these qualities and more, the fact of the matter is that oftentimes they don't. This is largely because the development process tends to be a collection of compromises involving a variety of factors such as resources, expertise, scheduling, and cost.

From a purely technical perspective, several factors prevent an application from being "perfect". Creating software with no bugs becomes more and more difficult the larger the application; it has been estimated that the time required to find and eliminate the last bug is approximately equal to the time spent to fix all of the previous bugs combined. The software industry is trying to create the best combination of tools and architecture to enable bug-free development, but as these new tools and techniques evolve, the best we seem to be able to do is replace old bugs with new ones. Lastly, the expectation that hardware will work forever conflicts with the second law of thermodynamics, which, in this context, means that everything breaks eventually. Simply put, software has bugs, architectures have flaws, and hardware fails.

So what is one to do? What approach should be used to ensure that the highest possible quality is attained given all of this? Here are some of the primary factors involved in creating a high quality product.

  • Defining the problem thoroughly by understanding the business needs
  • Reasonable expectations set at the beginning of the project
  • Simplicity in design, which leads to less coding
  • Less code means less chance of bugs, faster development, and easier maintenance
  • Proper tool selection can make the difference between one hour of work and one month of work
  • Expect errors and guide the users by providing useful messages
  • Disaster recovery plans where appropriate, with secondary, tertiary, or even quaternary sites for highly available systems
  • Document the project so new people can come up to speed more quickly
  • Training for anyone who is willing to take ownership
  • Return On Investment will indicate where the line between good and good enough should be drawn
  • Communication is paramount, from requirement gathering through post-production maintenance

There is a depicting different views of the same project from various perspectives throughout the project's lifecycle that you may have seen before (click here to see it). The first time I saw this was during a college intern job where I was working in an office, and it was old even then. It says something about human nature that this struck a chord in people decades ago, prior to the advent of computers, and that it is still just as humorous today.

I've used some of these frames to further clarify my thoughts on how products should be made, how services should be delivered, and how people should work together. Click on the options under the Philosophy button towards the top of this screen to read more.

     Contact Us     

Something wrong with this page or this site? Let the webmaster know by clicking HERE
This website designed, implemented, and maintained by Corey Dulecki
© 2009-2012, Corey's Consulting LLC