|
Software that deliberately kills the servers it is monitoring is
an interesting idea. A story I read recently told of a situation
where the programmer and/or engineer involved wasn't able to fix
the real, underlying problem, so an overlay solution was devised
that (a) worked, and (b) was feasible.
This post is not about that story. This post is about a comment
made by one of the readers in the forum where I saw it.
"You should just fix the real problem:
the software is garbage."
|
I've met this before, both the situation of having software we
can see is not up to current standards, and the attitude of those
who look at it with the benefit not only of hindsight, but of 20
years of advances in software, toolkits, libraries, and hardware.
Related:
Although it's also seen and quoted in other contexts, there's a
saying in software circles. People often come across code that
looks overly complicated for the task it's doing, or the effect
it's trying to achieve. But sometimes there's a reason for it
to be that complex. Sometimes there are unexpected edge-cases
and the code needs to be able to deal with it.
So the saying is:
"Don't ever take a fence down until you know the
reason why it was put up," -- John F Kennedy,
paraphrasing G.K.Chesterton.
This isn't a reason to leave things alone, and it should never
be a thought-terminating cliché. It's a call to put in the time
to understand something properly.
Sometimes there genuinely is no longer a reason for something,
and sometimes there never was. What's important is understanding.
|
But I try to be slow to jump to that conclusion, that the software
is garbage. So often there are reasons for things to be the way
they are. The software tools and the hardware capabilities were
very, very different in the aughties, and many people currently
writing software don't really seem to appreciate by just how much.
Additionally, there might be time pressures, political pressures,
engineering constraints, access problems, and more.
It may be the case that things could have been done differently,
perhaps better, but then again, once you know the full story and
the full context, maybe not.
Some time ago I wrote up a war story from the mid-nineties and had
some current software people crap all over it. When I started to
explain about the machine limitations of the time, the bluster
increased, and among the replies I got was "The software was crap".
Ever since then I've been interested in the contexts for these
stories. So often I hear "Well you shouldn't have done it like
that!" rather than an enquiring:
|
|
|
"OK, let's assume some clever
people wrote this. I wonder
what the pressures were that
made them come out with that
solution."
|
|
|
I've learned a lot by approaching things that way, instead of
assuming the people involved were ignorant, unskilled, idiots,
or otherwise incompetent, and simply declaring:
The software was garbage.
You might be right, but equally, it may be that you haven't put
in enough time to understand the realities.
Send us a comment ...
| 
Suggest a change ( <--
What does this mean?) /
Send me email
Subscribe!
