-57-

Error Free Code. Is It Attainable?

by Salvatore Mamone
Pace University Pleasantiville N.Y.

~<uch has been written about error free code; what it is,and bo~¢ tc ~ttain
it. Given that error free code is desirable and worth striving for,can it ever
be realized in the majority ef our code? I believe that the 8~swer
regrettab!y,Js no. If one were to disregard the every day simple applications~
like o~r 30th update program,or simple reports,error free code in larFe systems
is not attainable. There are a number of reasons for that pessimistic
statement,s~ch as the following: multiplicity of design methodologies ,non use
of reusable code,time constraints,user misunderat~r~JDp,aed testing. The
followi~g is an e:~amination of each of the previous reasons.

_Methodolosy.

There are any number of r~ethodeJ~ies which are in use t,-MeTz and which can
be used when developing large systems or programs. Eome of these methodologies
include: structured ~ e s J ~ , t o p down design and coding,code ~eviews,progranmning
teams (13,16),and chief progran~:er (2),to name a few. All of them are ~cod and
have merit,and have proved ,sefu! in developing large systems. Hot.ever,the very
fact that there ere so many methodologies a progr~m,mer can use in developing a
project or system is one reason why error free torte is dlff!cuJt to obtain.
Many programmers c h 2 ~ e jobs frequently and with each change invariably new
methods and procedures have to be learned. Bec~:u~e meat companies have their
own standards and procedures,and Job turnove:: for programmers is common place
(Bartol (3) claims that "half of a staff turns over every two
yesrs"),programmers are constsrt!y !ear:ling new design and coding procedures.
How can programmers be expected to. cede error free systems when they are always
searching for new jobs,or learning the methods ard standards of their present
employer? Employcrs r,~ed to learn how to motivate ~zheir programmers and
analysts,so that they ui]! be more inclined to rem~Jr vJth them. Bartoi (3)
suggests one xoav that companies can help reduce the turnover rate is by
rewarding the higher ploduct~ve computer professionals,and to encourage
professicna!]y oriented employees to pursue p~ofessional interests and to
re~.lard them for their professionalism. Le Duc (i0) seems to imply the same when
he says management must encourage all opportunities for growth,and that the
~rewth can be by informal or formal lear~ing, l.e D,c ~]so suggests that
program~ners should ~e encouraged to learn about interfa~zing j o b s ~ . e .
user,operations,etc.. This suggestion mlght have a dual benefit. For
one,programmers may become better at their profession becaumc they would become
familiar with what otPcr people will do with their programs a~nd systems after
they are created, in addition,they may be happier,because they are increasing
their know!edge,and thus more inclined te remain with their present empioyeer.

Reusable Code.

Reusable code is code which can be used in more than one system oK
program. This means that after a system is put into production and the bugs are
removed over time,sections of the system could be reused to create other
systems. ~,~ny systems have code which can be reused many times. Examples ef
this are update programs and systems,billing systems ,payro ~
....etc, • Often all

SIGPLAN Notices, Vi9 #3, March 1984

 -58-

that is necess<~rv~ for code to be reused is for the input ~ ~rture~ to be

. . . . .... . . . .

~odifJ+~@, ~r; a~<~txon,data structures or file~z,~.....ch are used in many

systems,can be ........
f~]e~~ in libraries and included in manv~ ~o~.er~,~-
,~ = by the use of
the 'include' or 'copy ~ statement. The use of code that has been ~ = = + ~ c a n ~,~ ~ ~

result i~ a reduction in coding,testing time a~,(~ . ccs+s

. . U~fertunst]y~msny
. . . .
compsnies ere nc:t ava~:~ of the many benefits oi reuseable code.
Ads (9) is sn attempt to address this problem° By the use cf ~e~erJcs snd
packages,Ads svpF,c,,rts the use of reuseable code° U~fortunately Ada is used
mainly bv the DOle,or companies which write .jstcx,~,~v~
:-~ for vbe Fcvernment. Because
of vhe prohibitive cost of aenv,~rting systems from Cobol to Ads,this author
Jets not believe that Ada will have a ma3c,r ~ F ~ c t o~ commercial devel~plncnt°

Time Constraints.

All projects start off with e~thusiasm,but inevitably when dead1~i~es

become tY~xt,as they usually do,good i n t e ~ t i o r ~ a n d coding techniques snd
methodologies quickly gi~e w~y in the rush to get the systcn cut the @eor. This
is confirms@ by P:aker (2),w~:~o, when refering to the New York Times project,
says that most errors in the code were found in the functJonel co@e thst had
been added te t ~ ~ st-stem last. Better estimate tools may help in this
regsrd,but one of the main reasons why deadlines sllp is because specifications
for s system usually cb~ege ~any times after the design of the system has
started.There are two main reasons whli specif~r~tions change after the design
has begun. For one,after sbowJl~p the ~scl; the first version of the system
he/she requested,we ususlly fir~ tl~et what we thought the user wanted was not
what they wanted. This is usu~J]v cs~sed by either poor design or
misunderstanding on the analyst sir vsers part. The second reason for
specification changes is that users ~o~'t really know what they want when they
ask for a system to be des~g~:~,~, ~P~s ~s Mamone's 6th law (note ~).
° 6] . . . . 8 , ~.

One possible method to improve rr the deadline problem is to use cutoff

dates on specification changes. Any c h ~ F e s ~eeded after the cutoff dates will
be implemente@,if possible,or will be incoreorated in the next version of the
code. A method of irapreviny e~ user-analyst misunderstanding is the use of
prototype systems, l,rooks (6) :;~id it best when he saJ@~"~e prepared to throw
one away bec<<,~se you will anyway." A system designed and coded and containing
rye errors,is useless il it isn=t what the user wanted. Protctyping is a
proccd,:r~ ~v which a subset of the system is designed and coded. This is then
reviewed by the user to see if tbe EDP concept of the system a~rees with the
u~:rs concept of the system. Or if the concepts agree,is the system "~'eal!y
workable to the user. If ~ou design and code the shell of a system ~nd
have the ~;ser examine it,you wJ]! very quickly lind out: i. if the design
meets the users specifications; 2. if the design is feasible; 3.that the user

Note ! Mamone's L~w

I. If it worked before it prohabTy won't now.

2. if it hasn't worked before it won't work now.
3. Anytl:ir~g cc=mr!eted is probably not do1~.e.
4. When you tbJvk vc,r~ did it ~:ight you probably did it wrong.
5. When you think you did it wrong you're probably right.
6. Users don't know what they want,but they want it right away.
never ~:s~ted that system in the first place. Then you can code what they w~.~ted
or needed ~

Testing_ L

Testing itself is a reason why error free cede is difficult to obtain.

Often~in commercial environments,the coder is dle person responsible for
testing the system. This may not be the ~est epproach for the following reason.
The coder is usua]ly trying to validate the ebsenc~: of errors in the system. A
system should be tested net to prove the absence of errors but to find the
errors Jn the system. This means that ~e~ides testing for normal
conditions~stress and unusual co~dltions should be tested. Examples oi stress
conditions can be:testing for high and Icy" rat:go values in numeric
fields;invalid data;etc..
Additionally the system should be tested to see how it p e r f o r m ~ t h a t is
~bet is the actual or turnaround time vs the ea~imated time. If a system Js ~
interactive system,are the menus and prompts clear and are the error ~esseges
unambigous? ~ t is the stress effect when multiple users are using the system
at the some time? The system should be ~esued in as close to e real world
environment es possible. Finding out after a interactive system has been
installed that the system performance is poor when mn]~ip]e users are accessing
it,is too ]a~e for both the programming stall and the user°

In conclusion,the computer industry is experieuein Z a severe problem.

Engineerers are prod~cJng faster and smaller computers,and more applications
for software design and coding are opening up each d~y. The computer industry
has a huge backlog of new systems to be designed,coded and tested and a
shortage of programmers and analysts tc d e ~ r ~nd code them. We need
productivity tools not to get thc~ code ~u~t faster,but to get it cut better. It
has been estimated that 40% Eo 50% of a programmers time is spent in
maintenance (4,10). If o~r cote was (Jot:root and company standards existed for
reusing code;maintenance time could be reduced,and new systems could be
implemented sooner.

References

I. Adler,Mike and Gray,Michael A. A Formalization of MeNers Cause-Effect Graphs

For Unit Testing. ACM Software Enginerring Notes Oct 1983
2. Baker,F.T. Chief Programm~el ~eam. IBM Systems Journa] vcl !! #1 ]~72
3. B~rtol,Kathryn M. Turnover Among D~ Personnel: A Causal Analysis.
Communication of the ACM vo! 26 #i0 Oct 1983
4. Beck,Lelamd L. and Perkins,Thomas E. A Survey of Software Engineering
Practice:Tools,hetbod~,~d Results IEEE Transactions on Software Engineering
vo! SE-9 #5 Sop 1983
5. Benson,Jeoff. A Preliminary Experiment In Automated Softw~re
Testing. Software Engineering Notes vol 6 #3 July 1981
6. Brooks,FredrJck P. Jr. The Mythical Man Month. Addison-Wesley Publishing Co.
1978
7. Compton,Michael T. Easing Fault Location In Large Systems. Com~urJcstion Of
The ACM vo! 23 #8 Aug 1980
 -60-

8. C-arman, John R, The "Bug t~ Heard vPc~md The World, ACM Software Engineering
Notes voi 6 #5 Oct 1981
9. Coos~C. Prod Hartmanis,J, The P r o g r a ~ i n g Language ADA Reference M anua]~
Springer-Ver~g~ Der]in Heide!ber~,N,Yo 19~!
I0 Le Duc,L. A. Jr, }~otJ.~:'~!JoPof Programmers~ Data Base vol ]l ~t4 Summer
1980
ii. Lientz,Be~1~et P~ 8 ~ Swanson,E, Burton. Problen~s in Application Software
Maintenance. ¢~o~imication Of The ACM vo] 2& #] ! ~]ov 198!
12. Mangel,Kenr~eth 7° Theory Of Small Program Com p!e~:!ty ACI< Sigplan Notes vol
'- ~3 ~i~:~-ch 1982
!3, Y~rteJ,Mari!yn The Effect Of Program~,ing Team Structures On 7rogr~mmJ~g
Tasks Communication Of The ACM vol 24 #3 March 1981
14. Neumann,Feter G. Psychosocial Implications Of Computer Software Development
~r.~ TT~c:Zen ~ d The Art Of Computing. AC~ Soft~are Engeneeri~g NOtes ve] 7 #2
~vr~] 1982
]5. Newste@,Pe+er P. and Leong,Wing-Keen and Yeung,Jca~e. Tbe Impact On
Programming Styles Oe Deg~,gg!ng Efficiency. ACM Software Engineering Notes vol
~_ Oct. 1981
16. Prentice,Dan. An Analysis: Of Software Development Environments. ACM
Software EnFJ~eer!ng Notes vol 6 #5 Oct 1981.
!7, Speetor~D. Language ~'eatures To Support lle~cab!]jtv, ACM Sjgplan Notices
vol 18 #9 Sept:. ].983,