|
||
| 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.
