Secrets of Software Quality
by David Barth
originally written September 9, 1998
updated January 2008
Introduction
I was invited by the Quality Assurance Group (QIT) at Computer Data Systems, Inc. (CDSI), to provide some insights into software quality, based on my
35 years writing software. (My first program was written in machine language, octal code, in 1962, for a Univac).
How Software is Viewed
Software may be viewed from three perspectives: that of the user, that of the management, and that of the programmer.
The User's View
The user usually draws an opinion about a software product based on its ease of use and quality of interface. A product that is easy to use but does not display
well or can be seen on a screen but not printed out is an example of poor interface to the user. Although we humans have five senses, current software technology
primarily caters to sight, but sound is rapidly increasing in importance as an interface. We have all seen poorly designed web pages that have so much data on them
that they are nearly incomprehensible. An example of a web page that has too much on it and looks extremely complicated is www.godaddy.com. An example
at the other end of the spectrum is www.danriver.com.
Of course, the reverse may be true: the software may have excellent screens, output may be provided in all media that the user needs, but it may be very difficult to
learn to use. Ventura Publisher and Microsoft Web Expression come to mind as products that require a lengthy learning curve to master. It is amazing how much
software is sold by well-known houses that is difficult to use because it is so poorly designed.
Management's View
Most oftem, management views software as a black box that should be implemented quickly and at low cost. Management usually doesn't care if the software is
easy to use or how users interface with it. An exception is Margaret C. "Meg" Whitman, CEO of eBay as of January 2008. Although she does not have a software
development background (she has an MBA from Harvard), she wants to ensure that the software her company provides to clients works well. Software bugs are
often seen in eBay's operating screens that are released to the public, but these bugs are fixed within a few days. No doubt, the eBay user community
complains loudly when one crops up.
The Programmer's View
The programmer's view is of the way the software is written: primarily, whether it is easy to understand and maintain. A system may be a delight to users but a
maintenance programmer's nightmare. Most packaged software is blind from a programmer's view because the source is either not available or it is supported by
the vendor.
Learning Good Software Writing Techniques
Few schools teach good programming methods, and expertise in this area is most often the result of experience maintaining programs written by other programmers,
as well as those that have been self-authored. There is no better learning environment for a programmer than to be responsible for maintaining a program that was
poorly written. The maintenance programmer is soon looking for ways to improve the code so that it is easier to modify and keep current. He or she also tends to
use better programming methods in his or her own programs after coping with poorly written code. However, a well-written program may provide a programmer with
new ways to skin the cat and write efficiently and clearly. After a programmer has become really good, he or she usually tries to write programs that will cause future
maintenance programmers to remember them, as though he or she is leaving a legacy of brilliant programming to future programmers. It is no
secret that a programmer almost always looks at the name of the author of a program and then decides how good that programmer was based on the way the
program is written.
Objectives for a Program
A program starts with an objective. How well this objective is stated and how well it conforms to "programmability" constraints will impact the life cycle of the
program. The most desirable objective is one that can be easily translated into a program, does not contain too many objectives within itself, and is clear and
unchanging.
An example of an objective that would be difficult to translate into a program is, "I need to know the count of all meals served each day, world-wide, broken out by
main course." The input for such a program would be difficult to obtain once, let alone each day.
Too many objectives that one program must perform is another pitfall in program development. An example occurred in an OCHAMPUS program, RA670, which
was eventually broken into three separate programs after several programmers unsuccessfully attempted to make all three major objectives operate smoothly with
each other within the program. After working on this complex, 9,000 line Cobol program for awhile, I recommended it be broken into two or three separate programs.
Only after management asked for and received a go-ahead to break the program apart were all three objectives successfully met.
Clear and Unchanging Objectives
Clear and Unchanging Objectives are a programmer's dream, but after he or she wakes up, that dream fades. Often, a user who defines the objectives does not have a
clear view of what is needed, and when test output is given to a user, it triggers ideas for changes. This isn't bad in itself, but it must be understood by all that
changes to program objectives may cause the project to take longer to finish. In a sense, this environment results in "prototyping," whereby the programmer
provides test output and the user makes changes. This prototyping loop may occur many times.
The Value of Preparation
It is to the programmer's benefit to try to create a "proposal" document, sort of an informal memorandum of understanding, that states the objectives clearly. It may
even have a few technical statements (e.g.: "Extract the color and type of leather from the materials database") so there will be no question about the source of the
information to be processed and how that process will be accomplished. It may require a lot of work to do this, but it is usually worth the effort for large programs for
several reasons:
- It becomes a specification for writing the program that the programmer can use as a guide as he or she codes.
- It is a reference point for the initial concept of the program. If changes are proposed by the user (or by the programmer if it is discovered that the program
needs to be written differently to accomplish its goals), these changes illustrate the beginning of the life cycle and can point out the need for more time and money to
complete the project.
- It becomes the original documentation of the program. This is useful for maintenance programmers to gain an understanding of the program after it goes
into production, but its value will decrease as changes are made to the program. (It is probably too expensive and time-consuming to continue updating the original
documentation during the life of a program.)
The Value of Internal Program Documentation
The internal workings of a program are best put within the program itself so that they can be updated at the same time the code is changed. This enables a
programmer to quickly determine how a program module works, facilitating maintenance work. External documentation is usually not updated, and it is sometimes
lost. Internal documentation is always with the program.
Program Modularization
A program's functions should be placed into modules. Modularization reduces redundant code because modules may be executed many times, but only occur
once in the program. Modules may be independent of the program as with a library routine or a called program, or they may be blocks of code in the program itself.
Long ago I had to add a check for a new transaction type in a program. The trouble was that the program had 15 transaction read instructions sprinkled throughout
instead of one read routine. Because my orders were to accomplish the maintenance as quickly as possible, I added transaction test logic following each of the 15
read instructions. This was, obviously, a poorly written program, and my "enhancement" didn't improve it.
Walk-Throughs
A program Walk-Through is a meeting where the author of a new program (or the person who has made significant changes to an existing program) presents his
solution to the problem and is critiqued by the other meeting attendees. The other meeting members are usually programmers, also, and they provide ideas and
suggestions to the presenting programmer regarding his program. Sometimes a Walk-Through is done before the project is begun to give ideas to the
programmer.
The attitude of the attendees should be non-confrontational and non-judgmental. They should not use this venue to attack or give retribution to a programmer.
A programmer hates to be told he is doing a poor job or is a lousy programmer. The intent of a Walk-Through should be to insure that the objectives of a project
are met and that the code is well-written and maintainable. A Walk-Through is a dangerous and expensive effort. It is dangerous to the egos of people whose
work is denigrated, and the diversion of work-hours to preparing for the meeting and sitting in the meeting is costly. Although they can be excellent tools for
improving the quality of programming, Walk-Throughs must be carefully controlled. Not many companies use them today.
Informal "Walk-Throughs" have been used at CDSI whereby one programmer will ask another whom he trusts and respects to glance over his code and provide
suggestions. This is probably the best approach to Walk-Throughs because it reduces the confrontational nature of the event, allows either party to decline
involvement at any time, and requires little time to accomplish. At the same time, it can foster better coding methods and increase programmer unity between
the two parties. The results are usually confidential instead of public as are the results of a Walk-Through attended by a number of programmers: "Did you hear
about Thorstein's Walk-Through? He butchered that program so badly I hope I never have to maintain it!"
The Final Acceptance
A programmer's work, when completed, should be analyzed in a professional manner. Most projects are incredibly complex, and if something doesn't work quite
right or is behind schedule, it is human nature to blame the programmer. What kind of quality of work do you think you'll get in the next project after you tell a
programmer he has bungled the assignment? Especially if it isn't his fault! There have been instances where a programmer's project was marked down because
he or she was behind schedule, even though the delays were outside the programmer's control. Instances like this are usually rare. Those who are involved with
guiding a project must take the time and patience to assist the programmer in a positive way so that he or she will perform at a high level of efficiency and go out
of his or her way to develop a five-star, blue ribbon product.
What Makes a Programmer Tick?
Programming, by its very nature, is a precise science, and artful, at the same time. The coding must be virtually perfect or results will be questionable. The art
comes with the way the instructions are assembled. There is nothing more beautiful (well, almost nothing) to a programmer than an elegantly written program
(clear, concise, and well-put-together code) that is bullet-proof (doesn't crash by itself or from incorrect user input).
Some younger programmers tend to write in a way the makes the program difficult to modify by others, in an attempt a maintaining a sense of job
security. No one is indispensible, and this attitude usually results in the programmer being passed over when complex programs are to be written.
Programmers tend to be able to sit in front of a terminal for hours on end, and, therefore, may be slightly more introverted than the population norm. Creating a
good program is almost like creating life itself. A running program could be compared to a living, breathing life-form. Not that programmers feel God-like, but they
often have big egos and feel that they are the best at their craft. These traits may not endear them to management, but, if a programmer is properly motivated, he
or she can provide great, timely software, in accord with the CDSI motto: Advanced Technologies, Common Sense Solutions.