>> On Sun, 2 Apr 2006 09:52:52 +0200, Jurjen Oskam <jurjen AT STUPENDOUS DOT
>> ORG> said:
> On Sat, Apr 01, 2006 at 09:46:00PM -0500, Allen S. Rout wrote:
>> Speaking as someone buried in my own PERL up to my nose:
> [snip: quite a good argument]
>> I don't think I could be as effective with a third-party product as I
>> am with my own stuff. I do think that the person who gets my job
>> after I get hit by a truck will curse me for years.
> Thanks, those are good points. But it does beg the question: how bad
> is your current situation? :)
I'll allude to a bit of logical pedantry by suggesting a google of
'beg the question' :) In any case, the question is an excellent one.
> I mean, is it such a spaghetti that nobody, except you as the
> developer, can *really* get it? Isn't *that* something you could
> change, so that your successor can as effective as you are?
The philosophical / design / practical problem here is very complex.
I'd guess the average TSM clue of those admins writing their own
automation code is at least a standard deviation higher than that of
the larger TSM-admin population. How much of that clue may be
implicit in the code, and how much must be explicit, accessible to a
newcomer?
Designing your code for maintainability is one thing, and we mostly
think we're trying to do that. Designing your code so that a domain
novice (or domain much-less-clued) can debug it is a totally different
question. It may simply be an impossible task.
Unfortunately, that's the problem we're talking about. I mean, issues
of arrogance and modesty aside, I've been working with TSM since 1998,
and with PERL since before 1992. The person hired after I get hit by
a truck is in all probability going to be less experienced in both of
these areas, perhaps profoundly so.
But it gets worse: our automation code reflects a somewhat smeary
snapshot of our TSM operations philosophy, including aspects we might
not have been able to state when we coded them.
Much of my migration automation is still kicked off by manipulations
of HIGHMIG and LOWMIG; I am gradually changing to use MIGRATE STGPOOL.
When I wrote the existing code, MIGRATE STGPOOL didn't exist, there
was no reason to discuss its' use. But it's the obvious tactic today,
and my use of the archaic method would be confusing to an observer.
So even an expert in TSM and PERL who comes in behind me might be
short on critical context to understand why SERVER-A is migrating
fine, but SERVER-B is having problems.
So at every turn, you weigh improved effectiveness, maintainability,
fidelity to your architecture, the forthcoming changes in your
architecture... For your successor to be "as effective", or even
close, they need most of that context.
> (Implementing and migrating to a third party product costs time and
> money, wouldn't that better be spent cleaning up the custom code?)
Oh, I'm in complete agreement: I think that local code is a superior
solution all around, once you've paid the overhead to get the novice
sufficiently clued. The best would be something -like- a Servergraph
or a TSMManager, but open-source (duck from the third-party vendor
slings and arrows) so we would -all- (most) be familiar with the
-same- codebase.
> Third-party programs are indeed spread more widely, but this also
> means they must be more complex because they must support
> configurations which you don't even use. Homegrown code has only the
> complexity you need.
I have to disagree with you there. There's stuff I need, which I
haven't written yet. There's stuff I have (which represents time
spent), which is no longer relevant. Worst of all, there's stuff I'm
too dense or nearsighted to have figured out I need. When I
eventually learn I need it, it's going to be painful.
And -that- is the function folks hope to get out of the third-party
tool, for which they're willing to sustain complexity and render up
many dollars.
- Allen S. Rout
|
