[Info-vax] OpenVMS developmen integration with Azure DevOps.

[Dave Froble]

On 9/4/2021 11:10 AM, kemain.nospam at gmail.com wrote:
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj via
>> Info-vax
>> Sent: September-04-21 10:58 AM
>> To: info-vax at rbnsn.com
>> Cc: Arne Vajhøj <arne at vajhoej.dk>
>> Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
>> DevOps.
>>
>> On 9/3/2021 4:05 PM, kemain.nospam at gmail.com wrote:
>>>> -----Original Message-----
>>>> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj
>>>> via Info-vax
>>>> Sent: September-02-21 3:34 PM
>>>> To: info-vax at rbnsn.com
>>>> Cc: Arne Vajhøj <arne at vajhoej.dk>
>>>> Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
>>>> DevOps.
>>>>
>>>> On 9/1/2021 8:25 PM, kemain.nospam at gmail.com wrote:
>>>>> This type of conversation is where I like to trot out this 2014
>>>>> timeless
>>>> OpenVMS article:
>>>>> <https://thedailywtf.com/articles/Jurassic-Programmers->
>>>>
>>>> You have posted it before.
>>>>
>>>> And it is very funny.
>>>>
>>>> And such things happen.
>>>>
>>>> But most likely this particular story is made up.
>>>
>>> No idea, but You could always contact the author for details on where
>>> and/or what the story was based on.
>>> <https://thedailywtf.com/authors/alex-papadimoulis>
>>>
>>>> <quote>
>>>> SQL Server had been abandoned for indexed files stored on VMS.
>>>> ...
>>>> The rock stars had created a monstrosity of a database, consisting of
>>>> hundreds of undocumented tables </quote>
>>>>
>>>> So the dropped the relational database for VMS index-sequential
>>>> files, but when they needed to convert back they had a relational
>> database.
>>>> That does not add up.
>>>>
>>> Not sure where article stated what the repository was when they
>>> converted back.
>>
>> See second part of quote above.
>
> Its just an article, but I read it as " but. when they needed to convert back they had a relational database to convert back to RMS files".
>
>>
>>>      I would have assumed they left the files in RMS indexed files.
>>
>> They said they did in first part of quote above.
>>
>>>> <quote>
>>>> Multi-tier programming was also abandoned, leaving business
>>>> calculations everywhere from within DIBOL code on VMS to the paint
>>>> routine of a Windows cont </quote>
>>>>
>>>> So they dropped multi-tier but have business logic in multiple tiers.
>>>> That does not add up.
>>>>
>>>
>>> They likely had the Dibol business code running on the same server as
>>> the RMS indexed files. As I know you know, placing the App and DB tier
>>> on the same OS instance (even Web) is very common in the OpenVMS
>>> world. Placing the App/DB on the same OS instance is not something
>>> typically done in the Windows/Linux culture (even on VMware, they are
>> separate OS instances).
>>
>> Yes.
>>
>> But the quote explicitly say code on Windows and VMS - that makes two tiers.
>>
>>>> <quote>
>>>> hundreds of undocumented tables tied together with hundreds of
>>>> undocumented relations, all glued together with copious amounts of
>>>> XML </quote>
>>>>
>>>> Database tables are not glued together by XML.
>>>>
>>>
>>> Not sure, but perhaps its possible (likely?) the article was modified
>>> by a non-technical editor?
>>
>> That is certainly possible.
>>
>> But then it may be more of "fiction based on true events" than
>> "documentary".
>
> You could say the same about any article if you analyzed every sentence that had technology in it.
>
> My point is that while there may have been some editing by a non-technical editor (when does that ever happen?), that does not mean the parts of the article is "fiction".
>
>>>> <quote>
>>>> new team of sharp-minded programmers to completely rewrite the
>>>> software as a Windows application using VisualBasic.NET ...
>>>> version 2's data structure was built by programmers fresh out of
>>>> college </quote>
>>>>
>>>> Some Colleges teach C# but practically none teach VB.NET. New
>>>> graduates and VB.NET is just a non-existing combination.
>>>>
>>>
>>> Let's not forget the article was from 2008 - 13 years ago.
>>
>> Same back then.
>>
>> VB.NET was never a thing in education. Pascal, C++, Java, C#, Python, maybe
>> some OCAML or Haskell - not VB.NET. VB.NET existed for the millions and
>> millions of VB6 and ASP/VBS programmers that existed late 90's/early 00's.
>>
>>> Having stated this, the article drives home the point that many, many
>>> companies in the last number of years have been bamboozled into
>>> converting to the next big shiny technology only to find that the
>>> grass is not always greener on the other side. They often learn a very
>>> painful and very expensive lesson. Experienced programmers that
>>> understand the company culture and business logic used in these Apps
>>> are critical resources to a companies future success.
>>>
>>> Its why many Med-Large Customers with battle proven applications that
>>> run the business now (albeit on older technologies) now typically
>>> choose a strategy of "upgrade and integrate" v.s. the strategy that
>>> vendors all to often push of "rip and replace".
>>
>> It is a fact that many big IT projects fail. Going over time, over budget and
>> below expected functionality is common. Being cancelled after spending lots
>> of money is not unheard of.
>>
>> Add unrealistic expectations, poor project management and inexperienced
>> developers and failure changes from potential risk to almost certainty.
>>
>> Having developers with domain/company experience is critical for
>> maintenance, enhancements and small system migrations. But for large
>> system migrations then I would prioritize experience with large system
>> migrations over domain/company experience.
>>
>> Arne
>>
>
> While good SW/HW architecture planning is certainly important, one of the toughest parts of large system migrations is not so much the technical bits and bytes, but rather understanding and unravelling the unique business, legal, culture and regulatory requirements that went into all the highly custom application code that supports and/or runs the company critical applications.
>
> In many large migrations, these are often not fully understood because the original programmers are either not there anymore, or perhaps the Apps do not have good documentation (bad docs is also not all on the programmers as they sometimes are way overworked and forced to make trade-offs to meet deadlines).
>
> When large migrations fail, it is usually not for technical reasons only, but rather a failure to integrate the technology with the business requirements.
>
> Hence, why many Customers today prefer "upgrade and integrate" and not "rip and replace".
>
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>
>
>
>

Kerry, there are some who will never agree with your logic.  Why? 
Because their future prospects depend on their being employed to "rip 
and replace", and then attempt to fix all the "oops" that happen.

Are there implementations that are a wreck?  Sure.  Such need to be 
addressed.

But when an application is successfully doing it's job, those who wish 
to sup at the hog trouth are sure not doing the company any good.

The real problem is management that doesn't have a clue ...

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486