[Tutor] How (not!) lengthy should functions be?

[boB Stepp]

On Sat, Apr 18, 2015 at 5:46 PM, Dave Angel <davea at davea.name> wrote:

> I'd still point out that eventually people will presumably get to believing
> in your program.  They'll subconsciously assume that if they mess up, the
> program will notice, so they don't have to be as careful as they otherwise
> would.

Well understood! I have observed this in other things I have done that
are being used, including the ancestor of this current project. I do
not believe I have spoken much of it. It had been in use for
approximately one year when I first discovered python and this mailing
list. It is similarly a plan evaluation program, except it is used for
the evaluation of our SBRT (stereotactic body radiation therapy)
plans, whereas this  project in development will be used -- at least
initially-- to evaluate *normal* treatment plans. I think it has been
in continuous use for going on four years now. It has never given an
incorrect result. It has never failed its monthly constancy checks. It
has rarely had a bug arise.  When it has happened, it has been for
something a user tried to do that I never imagined happening. But in
each such instance (Keep fingers crossed, etc.) it has either crashed
or displayed an error message describing the error, stopped program
execution, and to contact me. The problem with this program is at the
time of creating it, I knew its design was bad, but I did not have any
options at the time. I needed the ability to display a graphical
display of the plan analysis, but the only option our castrated work
stations provided was to use the planning system's ability to create
and display GUI elements. All of our workstations had Perl installed,
but were missing dependencies (Which I was not allowed to correct.) to
allow for GUI generation. I could have investigated the early versions
of Java installed, but I wasn't prepared to go that route then. I
tentatively looked into C/C++, but initial investigations revealed
missing libraries, etc. there as well. So in the end I developed this
hybrid of Perl code and planning system scripting language. You would
not like the structure of the scripting language! I could go on quite
a while, but I'll just mention that ALL variables are essentially both
global and persistent. The variables and what they store do not go
away until you exit the plan or purposefully destroy them. If I run
one script, finish it and run a totally unrelated script it will have
access to all variables and their last contents from the previous
script unless the programmer explicitly destroyed those variables
prior to that script's termination. Talk about potentially clashing
namespaces!

Because of these and other limitations that I had to work with, I was
forced to have some program logic and substantial portions of the
constraint data integrated with the GUI generation code. This led to
maintenance hell the one time the constraint data had changed almost a
couple of years ago. Steven's analogy of hammering nails with a paint
brush comes to mind! But I got it to work and to work well. And this
is much better than planners repeatedly doing by-hand calculations
over and over and ... and over while they are trying to develop a
viable plan. Which process is more likely to develop a patient
critical error? Especially as the planner becomes fatigued under
potentially heavy patient loads, where he must develop plans under
time pressures? So I provided a solution that works. The planner uses
it as a tool while developing his plans, undoubtedly *not* checking
*any* of the calculations he used to do by hand. SUBSTANTIAL amounts
of human labor are saved. When the planner feels he has a good plan,
THEN he checks all of the program's calculations. If this is
satisfactory, then he proceeds to getting the physician, etc.

I believe that I come across on this list as much more ignorant and
perhaps even much stupider than I actually am. This is because I am
the sort of person who is unafraid to ask questions, no matter how
trivial or how stupid I might make myself look by doing the asking.  I
would rather be absolutely certain that I understand what I am trying
to do and the implications of what I am trying to do, then not ask due
to potential embarrassment. At the very least, I want to identify the
boundaries of my ignorance and incompetence. And after further
pondering, if I feel I am still missing the boat on something, I'll
have a go at asking again until I am satisfied with my comprehension.
That is why I am so grateful to have access to your willing help and
expertise!

Anyway, back to the current project: The moment that they upgraded our
systems, so that not only did I have full access to Python, no matter
how old, but also that Tkinter was fully installed, was the moment I
started designing a complete rewrite of the above-mentioned program.
No matter how well working the program currently is, I *must* correct
its major design flaws now that I have the tools available to do so.
And I much prefer editing data files to editing programs into which
data is embedded!! And my intent is to make everything even safer by
interacting with the underlying planning software as minimally as
possible. I want this new program to be as close to a strict reader of
planning system output as I can make it and do ALL processing and
display of the data external to the planning system. Especially as
every time the planning system software is upgraded it seems to come
with a new set of its own bugs.

And if it comforts anyone, if anyone asked me to write software that
would directly control, interact with or potentially alter a patient's
*actual* treatment, I would refuse point blank--even if it cost me my
job-- because I know that my current knowledge and skill sets could
not safely accomplish such a project.

I do not know if I actually needed to say any of the above, but I feel
better for having said it! ~(:>))

> There's nothing you can do about this; it's human nature.  So I claim that
> making sure the advice your program offers has
>   1) few bugs.  And what it has should be crashes, not just getting the
> wrong result.
>   2) Careful wording of the messages to indicate the confidence level of the
> conclusion it's relating.

Trying to do my very, very best!


-- 
boB