Production quality software
Once upon a time, some twenty years ago, I wrote the article that follows.
At that time “open source” was not a buzzward. In the afterwords
section I add a few words on how much things have changed.
People have different images of
production quality software. Here is mine. Significant features
of production quality software include:
(li) The software will run by a number of people (customers) who
have paid hard cash for the software. These people will not
know the details of the software and usually will not have
access to the source. It must be possible for these people
to run the software without a knowledge of its contents and
without contact with the creators of the software.
- Pursuant to (a) the software must be substantially and
correctly documented from the prospective user’s viewpoint.
This documentation should not presume special knowledge
available to the creator of the program.
- The software should be substantially error free (ideally
it should be completely error free — however.) It should
work not only when used by the creator, but also when used
by the end users. In particular there should be no “don’t
do that because we didn’t take care of that case” loose
ends.
- The software should be rigorously tested. It is not enough
that it works in the small number of situations of immediate
interest to the creator. It must work under a wide variety
of situations. Testing and validation is a major part of
the work in preparing production software (or ought to be.)
- The software should have detailed error handling, and input
and data validation. Error recovery and proper handling
of erroneous input should comprise a significant portion
of both the code and the design.
- There should be either implicitly or explictly a quality
control process.
- There should be carefully controlled procedures for generating
the software actually shipped to the customers. All released
software should be clearly identified as to content and origin.
- Typically, production software is the product of more than
one person and may run from tens of thousands to millions
of lines of code. The entirety of the software should be
coherent in design, methodology, and style, and should be
readily maintainable as a whole. The work of individual
contributors should fit into the main body.
- The software should be well engineered. This includes
analysis of a variety of tradeoffs.
I could go on. Perhaps I should make the caveat that
much software that is commercially available is not of production
quality by the standards I have listed :-). However I wouldn’t
list fancy help screens as a criterion for production quality software.
A nicety, perhaps, but not a gut issue.
Now let us consider a typical program in an academic
setting. [That is, if there is such an animal — BSD4.x and
the beginning student’s first program don’t have much in common.]
I suggest that the following features are common:
- The program is used principally by the creator and a few
close associates.
- The program is freely modifiable by the users if it does
not work to expectations.
- Testing is principally restricted to the immediate uses
intended by the creator.
- The software is not part of a much larger body of software.
- Version control and release control are not major issues.
- Long term maintenance by people other than the creator is
not a major issue.
Note that I am not claiming that these features are always
the case, but merely that they are very common. Nor am I claiming
that programs of these kinds are shabby or somehow undesirable.
There are things that should be done in one context and are irrelevant
in another. A good Software Engineer should know what these things
are. If I am writing a program which will be used by 10,000 people
there are things that I had better do that are not important if I
am going to be the only user.
An academic instructor typically teaches his students to write
programs that are well written but are not elaborated. goes on to say
that he feels that he (and presumably his students) Instructors often that
their time and their students tims his is more profitably spent in
learning. I agree. Clearly, one should not invest more effort into a
program than is warranted by its ultimate value (as measured by the total
usage of the program.) This is the kind of engineering tradeoff decision
that one makes all of the time.
Nonetheless there are substantive differences between software production
in an academic setting and in “industry” as I hope I have made clear. And
I will say, dogmatically, that it rests on academia to understand what
those differences are and to teach something about the nature of producing
production quality software.
I would also add that there is a common fault in new
programmers, which is, essentially, they have an underdeveloped
sense of responsibility and professional obligation (sometimes
known as professional ethics). [It is not infrequent in old
programmers also.] In part, this is because we all like to
play with the machines. In part it is simply the case that
young people are often still making the transition from play to
work. The idea that one owes one’s principal loyalties and efforts
to one’s employer and that one’s activities should not impede
your fellow employees is one that has to be learned [quite
often rather rudely from your immediate supervisor.] It may
well not be legitimate to blame the universities for this state
of affairs; however I will express the wish that professional
ethics and a minimal knowledge of what will be expected of them
as employees were a part of the core curriculum.
Afterwords
In some respects there have been major changes in the software engineering
profession in the past twenty years.
This page was last updated March 21, 2008.
|