Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
From: Erik Naggum <erik@naggum.net>
Date: Sat, 29 Dec 2001 22:48:07 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3218654884764918@naggum.net>
* Erik Naggum
> Fourth, someone who can deal with upgrades just as effortlessly and does
> not remember things past after they have changed.
* Paolo Amoroso
| Can you elaborate on this? While I understand the literal meaning of the
| last sentence, I'm not sure whether I also get its complete meaning. Do
| you mean that, after a system upgrade, the programmer should no longer
| worry about problems that have been fixed by the upgrade?
Many people learn through painful experiences and pain avoidance is a
very fundamental property of human behavior -- "once bitten, twice shy"
has an equivalent and very old idiom in every language. Failure to trust
a function because it once was buggy is very common among programmers who
learn through trial and error instead of through reading specifications.
Even those who do relate primarily to specifications get bitten by the
lack of conformance to those specifications by the vendors they trusted
to implement them. So instead of shying away from them, a production
quality programmer relearns and conditionalizes code on the specific
broken versions.
This is the hardest part of dealing with non-conforming systems that
evolve slowly towards full conformance. Some vendors also think that
their non-conforming behavior has made customers depend on it, so have a
hard time correcting conformance problems because they think their past
customers are unable to accept the painful experience of having to update
their code because they did not program according to the specification,
either, but according to "whatever works", discovered precisely through a
painful process of trial and error. This is one reason conformance to a
specification is so important.
To your direct question, a properly handled dependency chain for software
upgrades should in fact mean that once a dependent system has been
upgraded, the problems exhibited by prior versions should no longer be
the subject of worries. Absent properly handled dependency chains, there
is no hope of controlling any behavior at all, anyway.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.