On 6/8/2024 2:46 PM, avi.e.gr...@gmail.com wrote:
Agreed, Thomas.
As someone who has spent lots of time writing code OR requirements of various
levels or having to deal with the bugs afterwards, there can be a huge
disconnect between the people trying to decide what to do and the people having
to do it. It is not necessarily easy to come back later and ask for changes
that wewre not anticipated in the design or implementation.
And typical contract vehicles aren't often flexible to allow for this
kind of thing. I've always tried to persuade my management to allow
built-in phases where re-evaluation can take place based on what's been
learned. To have a hope of that working, though, there needs to be a lot
of trust between client and development folks. Can be hard to come by.
I recently wrote a program where the original specifications seemed reasonable.
In one part, I was asked to make a graph with some random number (or all) of
the data shown as a series of connected line segments showing values for the
same entity at different measurement periods and then superimpose the mean for
all the original data, not just the subsample shown. This needed to be done on
multiple subsamples of the original/calculated data so I made it into a
function.
One of the datasets contained a column that was either A or B and the function
was called multiple times to show what a random sample of A+B, just A and just
B graphed like along with the mean of the specific data it was drawn from. But
then, I got an innocuously simple request.
Could we graph A+B and overlay not only the means for A+B as was now done, but
also the mean for A and the mean for B. Ideally, this would mean three bolder
jaged lines superimposed above the plot and seemed simple enough.
But was it? To graph the means in the first place, I made a more complex data
structure needed so when graphed, it aligned well with what was below it. But
that was hard coded in my function, but in one implementation, I now needed it
three times. Extracting it into a new function was not trivial as it depended
initially on other things within the body of the function. But, it was doable
and might have been done that way had I known such a need might arise. It often
is like that when there seems no need to write a function for just one use. The
main function now needed to be modified to allow optionally adding one or two
more datasets and if available, call the new function on each and add layers to
the graph with the additional means (dashed and dotted) if they are called
while otherwise, the function worked as before.
I feel your pain. In the generalized X-Y graphing program I've evolved
over several generations, I have graphing methods that can plot points
and curves, optionally overlaying them. Any function that wants to plot
something has to generate a dataset object of the type that the plotter
knows how to plot. No exceptions. Nothing else ever plots to the
screen. It's simple and works very well ... but I only designed it to
have axis labels and the title of the plot. They are all three
interactive, editable by the user. That's good, but for anything else
it's hack time. Witness lines, legends, point labels, etc., etc. don't
have a natural home.
But did I do it right? Well, if next time I am asked to have the data extended to
have more measurements in more columns at more times, I might have to rewrite quite
a bit of the code. My localized change allowed one or two additional means to be
plotted. Adding an arbitrary number takes a different approach and, frankly, there
are limits on how many kinds of 'line" segments can be used to differentiate
among them.
This is the kind of situation where it needs to be implemented three
times before it gets good. One always thinks that the second time
around will work well because all the lessons were learned the first
time around. But no, it's not the second but the third implementation
that can start to be really good.
Enough of the example except to make a point. In some projects, it is not
enough to tell a programmer what you want NOW. You may get what you want fairly
quickly but if you have ideas of possible extensions or future upgrades, it
would be wiser to make clear some of the goals so the programmer creates an
implementation that can be more easily adjusted to do more. Such code can take
longer and be more complex so it may not pay off immediately.
But, having said that, plenty of software may benefit from looking at what is
happening and adjusting on the fly. Clearly my client cannot know what feedback
they may get when showing an actual result to others who then suggest changes
or enhancements. The results may not be anticipated so well in advance and
especially not when the client has no idea what is doable and so on.
A related example was a request for how to modify a sort of Venn Diagram chart
to change the font size. Why? Because some of the labels were long and the
relative sizes of the pie slices were not known till an analysis of the data
produced the appropriate numbers and ratios. This was a case where the
documentation of the function used by them did not suggest how to do many
things as it called a function that called others to quite some depth. A few
simple experiments and some guesses and exploration showed me ways to pass
arguments along that were not documented but that were passed properly down the
chain and I could now change the text size and quite a few other things. But I
asked myself if this was really the right solution the client needed. I then
made a guess on how I could get the long text wrapped into multiple lines that
fit into the sections of the Venn Diagram without shrinking the text at all, or
as much. The client had not considered that as an option, but it was better for
their display than required. But until people see such output, unless they have
lots of experience, it cannot be expected they can tell you up-front what they
want.
One danger of languages like Python is that often people get the code you
supply and modify it themselves or reuse it on some project they consider
similar. That can be a good thing but often a mess as you wrote the code to do
things in a specific way for a specific purpose ...
-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On
Behalf Of Thomas Passin via Python-list
Sent: Saturday, June 8, 2024 1:10 PM
To: python-list@python.org
Subject: Re: From JoyceUlysses.txt -- words occurring exactly once
On 6/8/2024 11:54 AM, Larry Martell via Python-list wrote:
On Sat, Jun 8, 2024 at 10:39 AM Mats Wichmann via Python-list <
python-list@python.org> wrote:
On 6/5/24 05:10, Thomas Passin via Python-list wrote:
Of course, we see this lack of clarity all the time in questions to the
list. I often wonder how these askers can possibly come up with
acceptable code if they don't realize they don't truly know what it's
supposed to do.
Fortunately, having to explain to someone else why something is giving
you trouble can help shed light on the fact the problem statement isn't
clear, or isn't clearly understood. Sometimes (sadly, many times it
doesn't).
The original question struck me as homework or an interview question for a
junior position. But having no clear requirements or specifications is good
training for the real world where that is often the case. When you question
that, you are told to just do something, and then you’re told it’s not what
is wanted. That frustrates people but it’s often part of the process.
People need to see something to help them know what they really want.
At the extremes, there are two kinds of approaches you are alluding to.
One is what I learned to call "rock management": "Bring me a rock ...
no, that's not the right one, bring me another ... no that's not what
I'm looking for, bring me another...". If this is your situation, so,
so sorry!
At the other end, there is a mutual evolution of the requirements
because you and your client could not have known what they should be
until you have spent effort and time feeling your way along. With the
right client and management, this kind of project can be a joy to work
on. I've been lucky enough to have worked on several projects of this kind.
In truth, there always are requirements. Often (usually?) they are not
thought out, not consistent, not articulated clearly, and not
communicated well. They may live only in the mind of one person.
--
https://mail.python.org/mailman/listinfo/python-list
