[Info-vax] Greg Kroah-Hartman on backwards compatibility

[Arne Vajhøj]

On 12/1/2020 12:59 PM, Dave Froble wrote:
> On 12/1/2020 10:50 AM, Arne Vajhøj wrote:
>> On 12/1/2020 10:11 AM, geze... at rlgsc.com wrote:
>>> On Tuesday, December 1, 2020 at 10:03:18 AM UTC-5, Stephen Hoffman
>>> wrote:
>>>> Put differently, BASIC and C and such could be staggeringly better
>>>> than now, and OpenVMS itself much easier to work with, and so much
>>>> more than what inflexible APIs including $qio will permit. But if
>>>> you'll excuse me, I have to deal with Yet Another Itemlist,
>>>> wrestling with yet another old API scheme which makes fixing
>>>> under-sized app buffer allocations utterly impossible. q.v. the
>>>> parallel discussion of 16-bit fields in the mailbox API. And no, I
>>>> really don't want to have to code an API call to size the buffer to
>>>> then allocate the buffer to then call the API, but here I am.
>>>
>>> I do not disagree that the mechanics of QIO are dated. However,
>>> focusing on the mechanics of itemlists, etc. is missing the primary
>>> point of my comment. Syntax changes are indeed vexing, but they are
>>> just that, syntax.
>>>
>>> When I referred to QIO, I was referring to the semantic definition.
>>> Generally speaking, syntax issues are local. Semantic changes are far
>>> more global and have a larger impact. IMO.
>>
>> Changes that require real redesign of data structure and/or
>> logic are obviously much more intrusive.
>>
>> But even trivial changes like changing the size of
>> something can be a problem.
>>
>> Not for code that are being very actively developed.
>> Then the change can just be rolled into next batch
>> and everything is fine.
>>
>> But for the code that nobody touches. The formal "maintainer"
>> of the code knows that he can go to a certain directory and
>> do @BUILD, because that was what he was told many years ago when
>> he took over the responsibility. Nobody that has actually worked
>> on the code are around any longer.
>>
>> Code like that is a really a business risk.
>>
>> But such code exist.

> Tell me why it is harder to get into existing code for modifications, 
> maintenance, fixes, and such, then it is to explore the original design, 
> re-write the code in your language of the week, and then test it to 
> insure that you didn't screw things up royally?

 > The only "business risk" that I can see is the risk that some programmer
 > won't get the opportunity to earn big bucks to re-do something that was
 > never broken.

I am not quite sure that I understand your point.

The point is that having a large important code base that
nobody knows is a risk.

It will take a long time to fix if an upgrade break it. And
it will take a long time to implement changes to business rules.
Simply because whoever get the task will have to spend significant
time figuring out how the code works.

The discussion whether the solution is to have somebody learn
the existing code base or do a major update in technology is
something that follows if management realize the risk and
decide to do something about it.

Factors that will influence the decision include: is it
easy to hire or train people in the current technology,
is the current technology still supported, could a technology
change reduce code base dramatically by switching from
custom code to standard library, could a technology
switch enable new features that business want.

Complex evaluation. But the companies I was talking
about are not there (yet).

Arne