HomePractices Page 2 - Writing Quality Software: A Primer
Some General Quality Issues - Practices
Okay, so you have a respectable handle on syntax, and you are proud of yourself for getting that far. And, truth be told, you should be. But, knowing syntax is not the same as mastering syntax in such a way that builds quick, efficient web software. This article takes a look at not just writing software, but writing quality software.
Before we explore these issues, let's take a real broad gander at what quality software is. First and foremost, quality software is correct; that is, it provides the functionality to satisfy requirements. In addition, a quality piece of software exhibits robustness. Can it withstand unusual and unexpected demands? Can it process incorrect data and display appropriate error messages on demand?
Quality software is also accurate. What is the difference between 'correct' and 'accurate'? Accurate describes how error-free the software is. Does the for loop iterate 9 times instead of 10? If so, the code is not completely accurate. Another issue is platform compatibility. A quality piece of web software, for example, runs successfully on a variety of operating systems and under a diverse set of browsers.
From the programmer's perspective, quality software is easy to maintain. That means the code is well documented and effortlessly understood. Correcting code errors or adding modules is an easy task under quality software. Further, code reuse creates quality software. Are your modules portable to other applications and can they function properly under a multitude of environments?
Quality software is accomplished through insidious code inspection, often in the form of code reviews by other programmers. Unit and system testing ensures the application's correctness, and audits, for those organizations with appropriate resources, bring in outside perspectives to perfect code.
Goal setting is imperative to quality software. Is correctness your goal? If so, you may need to forgo other aspects, like robustness. If robustness is paramount, it is possible the application may become slightly less correct, to the 'T'. Trade-offs need to be finalized before software construction; these can then be used to form a development consensus.
/ 24 
