On 2022-10-17 01:53, Arne Vajhøj wrote:
> On 10/16/2022 7:32 PM, kemain.nospam@gmail.com wrote:
>> Also, replacing a compiled application with an interpreted language??
>
> Python for data processing? Sure! Why not!
>
> There is a company called Google that until a few years ago
> processed all the public web pages in the world with Python.

No. They did not.
Google used/use Python for a bunch of stuff, but it was decided almost
10 years ago that no new stuff should be written in Python. And even
back then, most scraping and processing was in C++. Python was used for
other bits and pieces. But not for processing everything that Google
scraped.

The reason for stop using Python was several. Performance was one part,
but much more it was realized that large software systems become really
hard to develop in a safe way, or maintain, using Python. It's not
really suitable for any of this. It's nice for small, simple programs
you want to throw together quickly.

Johnny

On 2022-10-17 20:54, Scott Dorsey wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>> So VMS is a "mainframe" once again ? (At least in job adverts) :-)
>
> If it's not 36 bits it's no DEC mainframe.

If your computer don't have 36 bits, you're not playing with a full DEC. :-)

Johnny

On Thursday, October 13, 2022 at 1:09:34 PM UTC-4, John Dallman wrote:
> In its glory days of the 1980s, VMS got used for all sorts of technical
> computing and business IT.
>
> My employers used it as a software development system, producing
> mathematical modelling code for VMS, plus a wide range of other platforms.
> Demand for the code on VMS shrank in the 1990s, and it became expensive
> compared to doing development on Windows. We had dropped it by the year
> 2000. We'd resume support if there was significant demand for it on
> x86-64, which is why I joined this newsgroup.
>
> What do you use VMS for in the 2020s?
>
> John

Near real-time delivery of location (landline address or lat/long for mobile) to PSAPs for 911 service in at least two provinces in Canada ... at least until NG911 comes along.

Here I use a cluster with blades to bill fixed telephony services and another cluster to manage payroll system.

Regards

Eu

El viernes, 21 de octubre de 2022 a las 8:52:57 UTC-5, cbse...@gmail.com escribió:
> On Thursday, October 13, 2022 at 1:09:34 PM UTC-4, John Dallman wrote:
> > In its glory days of the 1980s, VMS got used for all sorts of technical
> > computing and business IT.
> >
> > My employers used it as a software development system, producing
> > mathematical modelling code for VMS, plus a wide range of other platforms.
> > Demand for the code on VMS shrank in the 1990s, and it became expensive
> > compared to doing development on Windows. We had dropped it by the year
> > 2000. We'd resume support if there was significant demand for it on
> > x86-64, which is why I joined this newsgroup.
> >
> > What do you use VMS for in the 2020s?
> >
> > John
>
> Near real-time delivery of location (landline address or lat/long for mobile) to PSAPs for 911 service in at least two provinces in Canada ... at least until NG911 comes along.

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: Sunday, October 16, 2022 8:54 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] What does VMS get used for, these days?
>
> On 10/16/2022 7:32 PM, kemain.nospam@gmail.com wrote:
> >> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Craig A.
> >> Berry via Info-vax
> >> Sent: Sunday, October 16, 2022 8:11 PM
> >>> As example:
> >>> <https://www.indeed.com/q-Openvms-
> jobs.html?vjk=aca6c8029c23b35e>
> >>> "The Client calculates and processes approximately $8 billion of
> >>> school
> >> funding annually. The data processing systems used are a mix of COBOL
> >> and SAS programs; running on an OpenVMS mainframe; reading from
> >> Oracle databases, SAS datasets, and flat files; and writing to SAS
> >> datasets and flat files."
> >>
> >> You also neglected to mention that the job is "replacing COBOL and
> >> SAS on OpenVMS with Python on Windows and SQL server databases."
> So
> >> it's not a VMS job and soon won't be a VMS shop.
> >
> > Define "soon" ...
> >
> > Seen many "projects" that start up based on some new CIO with Windows
> > background (likely propped up by Microsoft Sales types) try to make a
> > name for themselves and then a few years later after not delivering
> > anything close to a comparative system is off looking for a new job.
> It is their stated intention.
>
> Time will show if it happens.
>
> Experience shows that a significant number of large IT projects fail.
>
> I don't think is specific for migrations to Windows.
>

My comments were not specific to Windows, but rather the naivety of many
Senior Execs who want to appear as fashionable (read "forward thinking") for
the sake of their careers.

These types choose future strategic options which are all to often driven by
their favourite Vendor Sales person who takes them to Lunch/Dinners and/or
trips to their annual Customer events in exotic locations.

The "upgrade and integrate" strategy is usually the strategy which has the
most chance of success in large companies.

The "rip-and-replace" all to often looks only at technology and discounts
the many, many years of highly customized business logic built into the
existing Application(s).

> > I say a CIO with Windows background because any self respecting CIO
> > with UNIX background would at least try and keep the same database -
> > Oracle.
> If they needed to migrate from old Oracle DB on VMS to current Oracle on
> Linux and they did not have Oracle DB on Linux but have SQLServer on
> Windows, then it makes sense to pick the latter no matter what background
> the CIO have.
>
> > Also, replacing a compiled application with an interpreted language??
>
> Python for data processing? Sure! Why not!
>
> There is a company called Google that until a few years ago processed all
the
> public web pages in the world with Python.
>
> Arne

Well, not many real life companies have unlimited HW budgets.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 10/22/2022 10:33 AM, kemain.nospam@gmail.com wrote:
>
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
>> via Info-vax
>> Sent: Sunday, October 16, 2022 8:54 PM
>> To: info-vax@rbnsn.com
>> Cc: Arne Vajhøj <arne@vajhoej.dk>
>> Subject: Re: [Info-vax] What does VMS get used for, these days?
>>
>> On 10/16/2022 7:32 PM, kemain.nospam@gmail.com wrote:
>>>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Craig A.
>>>> Berry via Info-vax
>>>> Sent: Sunday, October 16, 2022 8:11 PM
>>>>> As example:
>>>>> <https://www.indeed.com/q-Openvms-
>> jobs.html?vjk=aca6c8029c23b35e>
>>>>> "The Client calculates and processes approximately $8 billion of
>>>>> school
>>>> funding annually. The data processing systems used are a mix of COBOL
>>>> and SAS programs; running on an OpenVMS mainframe; reading from
>>>> Oracle databases, SAS datasets, and flat files; and writing to SAS
>>>> datasets and flat files."
>>>>
>>>> You also neglected to mention that the job is "replacing COBOL and
>>>> SAS on OpenVMS with Python on Windows and SQL server databases."
>> So
>>>> it's not a VMS job and soon won't be a VMS shop.
>>>
>>> Define "soon" ...
>>>
>>> Seen many "projects" that start up based on some new CIO with Windows
>>> background (likely propped up by Microsoft Sales types) try to make a
>>> name for themselves and then a few years later after not delivering
>>> anything close to a comparative system is off looking for a new job.
>> It is their stated intention.
>>
>> Time will show if it happens.
>>
>> Experience shows that a significant number of large IT projects fail.
>>
>> I don't think is specific for migrations to Windows.
>>
>
> My comments were not specific to Windows, but rather the naivety of many
> Senior Execs who want to appear as fashionable (read "forward thinking") for
> the sake of their careers.
>
> These types choose future strategic options which are all to often driven by
> their favourite Vendor Sales person who takes them to Lunch/Dinners and/or
> trips to their annual Customer events in exotic locations.
>
> The "upgrade and integrate" strategy is usually the strategy which has the
> most chance of success in large companies.
>
> The "rip-and-replace" all to often looks only at technology and discounts
> the many, many years of highly customized business logic built into the
> existing Application(s).

I'm not saying that it can't happen, but, I have never seen any such replacement
where all that custom business logic survived the replacement.

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

On 10/22/22 16:07, Dave Froble wrote:
>
>
> I'm not saying that it can't happen, but, I have never seen any such
> replacement where all that custom business logic survived the replacement.
>

When Banner was brought in to replace the custom apps on VMS at the
University it was understood upfront that everything was going to
change the users were the one's that would have to adapt.

Compare that to where I worked in 1980 where I was tasked with
developing a microcomputer based data entry system to get the
"keypunch" people off the mainframe to free it up for production
and development work. The first requirement was that what I was
to develop had to present itself to the users exactly like what
they had been using on the Univac-1100.
How times change.

bill

On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
> When Banner was brought in to replace the custom apps on VMS at the
> University it was understood upfront that everything was going to
> change the users were the one's that would have to adapt.
>
> Compare that to where I worked in 1980 where I was tasked with
> developing a microcomputer based data entry system to get the
> "keypunch" people off the mainframe to free it up for production
> and development work.  The first requirement was that what I was
> to develop had to present itself to the users exactly like what
> they had been using on the Univac-1100.
> How times change.

Usually adapting usage to the standard packages way of doing things
is the smart approach.

The argument for buying the standard packages in the first
place is to get a lot of functionality without paying a fortune
for development.

Most standard packages can be customized as much as the customer
want (read: are willing to pay 250-350 USD per hour for).

But first paying for a standard package, then paying a fortune
for customization of the standard package and after that every
time the standard package is upgraded pay a half fortune for
migrating all those customizations is not achieving the
goal of reducing cost.

So the smart customers put customization wishes in two
buckets:

A) to do it like before, great idea but not important for
business, nice to have etc.

B) changes that reduce cost or increase revenue significantly

Bucket #A goes into trash and only bucket #B get implemented.

Arne

On 10/19/2022 12:47 PM, Johnny Billquist wrote:
> On 2022-10-17 01:53, Arne Vajhøj wrote:
>> On 10/16/2022 7:32 PM, kemain.nospam@gmail.com wrote:
>>> Also, replacing a compiled application with an interpreted language??
>>
>> Python for data processing? Sure! Why not!
>>
>> There is a company called Google that until a few years ago
>> processed all the public web pages in the world with Python.
>
> No. They did not.
> Google used/use Python for a bunch of stuff, but it was decided almost
> 10 years ago that no new stuff should be written in Python. And even
> back then, most scraping and processing was in C++. Python was used for
> other bits and pieces. But not for processing everything that Google
> scraped.
>
> The reason for stop using Python was several. Performance was one part,
> but much more it was realized that large software systems become really
> hard to develop in a safe way, or maintain, using Python. It's not
> really suitable for any of this. It's nice for small, simple programs
> you want to throw together quickly.

Google is not known for saying much about their technology, but some is
known.

Fact (source: Brin & Page): 1996 both crawler and search engine was in
Python
Fact (source: Steve Levy): 1999 both crawler and search engine was still
in Python, search engine had performance problems
Internet gossip: mid 00's crawler was still Python, search engine had
been rewritten in C++
Internet gossip: around when 00's became 10's the company generally
started switching away from Python
Internet gossip: mid 10's both crawler and search engine are now C++

It is not known if the crawler was rewritten before other Python stuff
(like 2005),
when other Python stuff was done (like 2010) or after other Python stuff
(like 2015).

But given what we know about the Python crawler and how much Google indexes:

1996 - 24 million pages
2000 - 1 billion pages
2004 - 4 billion pages
2005 - 25 billion pages
2013 - 30 trillion pages
2016 - 130 trillion pages

then that Python crawler must have indexed a lot of pages.

And several orders of magnitude larger data than the financial data ETL that
started this subthread.

And it is actually not so bad performance wise.

Interpretation is typical 10-20 times slower than compiled code.

So parsing those millions/billions of pages in Python would be 10-20
times slower
than doing it in C++. Meaning 10-20 times as many servers. Disaster.

But that is probably not relevant at all.

If Google's Python crawler is like most high performance Python, then
the model is
Python code call a Python module consisting of a Python wrapper around a
native code library.

So all the CPU intensive parsing would be done in that native code and
the Python code
would just have the logic on how to process based on the parsing output.

Python high level logic utilizing modules with native code may just be
10-20% slower
than C++.

And then it would just be 10-20% more servers. Acceptable at least until
a certain level.

Arne

On 2022-10-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>> When Banner was brought in to replace the custom apps on VMS at the
>> University it was understood upfront that everything was going to
>> change the users were the one's that would have to adapt.
>>
>> Compare that to where I worked in 1980 where I was tasked with
>> developing a microcomputer based data entry system to get the
>> "keypunch" people off the mainframe to free it up for production
>> and development work.  The first requirement was that what I was
>> to develop had to present itself to the users exactly like what
>> they had been using on the Univac-1100.
>> How times change.
>
> Usually adapting usage to the standard packages way of doing things
> is the smart approach.
>

I dare you to walk into an office of 100 people and tell them that to
their faces. :-)

Even better, tell them that you expect them to carry on doing their
normal work, at their usual workloads and without interruption,
while doing that.

Before doing that however, it might be a good idea to ask a friend if
they are willing to deliver your eulogy. :-)

Simon.

PS: The serious point is that changing to "a standard approach" is a
_lot_ harder than it appears and the userbase may only be able to hit
the current workload targets because the current system is so tightly
integrated into their workflow and meets their needs exactly.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>> When Banner was brought in to replace the custom apps on VMS at the
>> University it was understood upfront that everything was going to
>> change the users were the one's that would have to adapt.
>>
>> Compare that to where I worked in 1980 where I was tasked with
>> developing a microcomputer based data entry system to get the
>> "keypunch" people off the mainframe to free it up for production
>> and development work. The first requirement was that what I was
>> to develop had to present itself to the users exactly like what
>> they had been using on the Univac-1100.
>> How times change.
>
> Usually adapting usage to the standard packages way of doing things
> is the smart approach.

This is where Arne departs from reality ...

He seems to believe in "lowest common denominator" ...

> The argument for buying the standard packages in the first
> place is to get a lot of functionality without paying a fortune
> for development.

One gets what they pay for ...

If specific requirements do not exist, then sure, but if they do exist, there
can be a very good reason.

> Most standard packages can be customized as much as the customer
> want (read: are willing to pay 250-350 USD per hour for).

Well, sure, if one is stupid enough to drink the SAP kool-ade ...

Reality is that some people suffer with poor tools, and if a well designed
package can be found, it can be an improvement.

The other side of that is that some people are working with tools that have been
designed and refined over time to be exactly what they need, and anything else
will affect their work, sometimes quite drastically. When someone who most
likely doesn't actually understand the requirements, for example someone who
declares "we should be using WEENDOZE", things can get rather bad.

That is the reality ...

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

On 10/24/2022 10:06 AM, Dave Froble wrote:
> On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
>> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>>> When Banner was brought in to replace the custom apps on VMS at the
>>> University it was understood upfront that everything was going to
>>> change the users were the one's that would have to adapt.
>>>
>>> Compare that to where I worked in 1980 where I was tasked with
>>> developing a microcomputer based data entry system to get the
>>> "keypunch" people off the mainframe to free it up for production
>>> and development work.  The first requirement was that what I was
>>> to develop had to present itself to the users exactly like what
>>> they had been using on the Univac-1100.
>>> How times change.
>>
>> Usually adapting usage to the standard packages way of doing things
>> is the smart approach.
>
> This is where Arne departs from reality ...
>
> He seems to believe in "lowest common denominator" ...

> Reality is that some people suffer with poor tools, and if a well
> designed package can be found, it can be an improvement.
>
> The other side of that is that some people are working with tools that
> have been designed and refined over time to be exactly what they need,
> and anything else will affect their work, sometimes quite drastically.

Not really. I don't think you got the point.

It may make sense to pay for a custom solution tailored for
specific needs.

It may make sense to go for a standard solution and use it
the standard way.

What I am skeptical about is the approach of taking a standard
solution and do extreme customization.

That sort of defies the point of the standard solution.

Arne

On Monday, October 24, 2022 at 4:42:51 PM UTC-4, Arne Vajhøj wrote:
> On 10/24/2022 10:06 AM, Dave Froble wrote:
> > On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
> >> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
> >>> When Banner was brought in to replace the custom apps on VMS at the
> >>> University it was understood upfront that everything was going to
> >>> change the users were the one's that would have to adapt.
> >>>
> >>> Compare that to where I worked in 1980 where I was tasked with
> >>> developing a microcomputer based data entry system to get the
> >>> "keypunch" people off the mainframe to free it up for production
> >>> and development work. The first requirement was that what I was
> >>> to develop had to present itself to the users exactly like what
> >>> they had been using on the Univac-1100.
> >>> How times change.
> >>
> >> Usually adapting usage to the standard packages way of doing things
> >> is the smart approach.
> >
> > This is where Arne departs from reality ...
> >
> > He seems to believe in "lowest common denominator" ...
> > Reality is that some people suffer with poor tools, and if a well
> > designed package can be found, it can be an improvement.
> >
> > The other side of that is that some people are working with tools that
> > have been designed and refined over time to be exactly what they need,
> > and anything else will affect their work, sometimes quite drastically.
> Not really. I don't think you got the point.
>
> It may make sense to pay for a custom solution tailored for
> specific needs.
>
> It may make sense to go for a standard solution and use it
> the standard way.
>
> What I am skeptical about is the approach of taking a standard
> solution and do extreme customization.
>
> That sort of defies the point of the standard solution.
>
> Arne
I think that the key is how these "standard" solutions fit with the workflow of the place that adopts it. Significant changes to existing workflow can have an affect on overall productivity. This is why customization is usually a feature. Not everyone works the same way.

Dan

On 10/24/2022 4:42 PM, Arne Vajhøj wrote:
> On 10/24/2022 10:06 AM, Dave Froble wrote:
>> On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
>>> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>>>> When Banner was brought in to replace the custom apps on VMS at the
>>>> University it was understood upfront that everything was going to
>>>> change the users were the one's that would have to adapt.
>>>>
>>>> Compare that to where I worked in 1980 where I was tasked with
>>>> developing a microcomputer based data entry system to get the
>>>> "keypunch" people off the mainframe to free it up for production
>>>> and development work.  The first requirement was that what I was
>>>> to develop had to present itself to the users exactly like what
>>>> they had been using on the Univac-1100.
>>>> How times change.
>>>
>>> Usually adapting usage to the standard packages way of doing things
>>> is the smart approach.
>>
>> This is where Arne departs from reality ...
>>
>> He seems to believe in "lowest common denominator" ...
>
> > Reality is that some people suffer with poor tools, and if a well
> > designed package can be found, it can be an improvement.
> >
> > The other side of that is that some people are working with tools that
> > have been designed and refined over time to be exactly what they need,
> > and anything else will affect their work, sometimes quite drastically.
>
> Not really. I don't think you got the point.
>
> It may make sense to pay for a custom solution tailored for
> specific needs.
>
> It may make sense to go for a standard solution and use it
> the standard way.
>
> What I am skeptical about is the approach of taking a standard
> solution and do extreme customization.
>
> That sort of defies the point of the standard solution.

Let us as an example say that we have a custom application
with 1 million lines of code.

Let us say that there exist a standard solution with 5 million
lines of code which provides the same functionality plus a
lot extra (some useful - a lot irrelevant).

If the standard solution need 1% customization, then that
is only 50000 lines of code. And there may be a business
case. Obviously exact fit to requirements would need to
be evaluated, but potentially it could make sense.

If the standard solution need 40% customization, then
that is 2 millions line of code. And it seems very unlikely
that there is a business case. It would make more sense to
add to the custom application.

Arne

On 10/24/2022 4:42 PM, Arne Vajhøj wrote:
> On 10/24/2022 10:06 AM, Dave Froble wrote:
>> On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
>>> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>>>> When Banner was brought in to replace the custom apps on VMS at the
>>>> University it was understood upfront that everything was going to
>>>> change the users were the one's that would have to adapt.
>>>>
>>>> Compare that to where I worked in 1980 where I was tasked with
>>>> developing a microcomputer based data entry system to get the
>>>> "keypunch" people off the mainframe to free it up for production
>>>> and development work. The first requirement was that what I was
>>>> to develop had to present itself to the users exactly like what
>>>> they had been using on the Univac-1100.
>>>> How times change.
>>>
>>> Usually adapting usage to the standard packages way of doing things
>>> is the smart approach.
>>
>> This is where Arne departs from reality ...
>>
>> He seems to believe in "lowest common denominator" ...
>
>> Reality is that some people suffer with poor tools, and if a well
>> designed package can be found, it can be an improvement.
>>
>> The other side of that is that some people are working with tools that
>> have been designed and refined over time to be exactly what they need,
>> and anything else will affect their work, sometimes quite drastically.
>
> Not really. I don't think you got the point.
>
> It may make sense to pay for a custom solution tailored for
> specific needs.
>
> It may make sense to go for a standard solution and use it
> the standard way.
>
> What I am skeptical about is the approach of taking a standard
> solution and do extreme customization.
>
> That sort of defies the point of the standard solution.

Some apps were designed for customization, within some limits ...

For some of the above, I'd agree with you.

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

On 10/24/2022 4:54 PM, Arne Vajhøj wrote:
> On 10/24/2022 4:42 PM, Arne Vajhøj wrote:
>> On 10/24/2022 10:06 AM, Dave Froble wrote:
>>> On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
>>>> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>>>>> When Banner was brought in to replace the custom apps on VMS at the
>>>>> University it was understood upfront that everything was going to
>>>>> change the users were the one's that would have to adapt.
>>>>>
>>>>> Compare that to where I worked in 1980 where I was tasked with
>>>>> developing a microcomputer based data entry system to get the
>>>>> "keypunch" people off the mainframe to free it up for production
>>>>> and development work. The first requirement was that what I was
>>>>> to develop had to present itself to the users exactly like what
>>>>> they had been using on the Univac-1100.
>>>>> How times change.
>>>>
>>>> Usually adapting usage to the standard packages way of doing things
>>>> is the smart approach.
>>>
>>> This is where Arne departs from reality ...
>>>
>>> He seems to believe in "lowest common denominator" ...
>>
>> > Reality is that some people suffer with poor tools, and if a well
>> > designed package can be found, it can be an improvement.
>> >
>> > The other side of that is that some people are working with tools that
>> > have been designed and refined over time to be exactly what they need,
>> > and anything else will affect their work, sometimes quite drastically.
>>
>> Not really. I don't think you got the point.
>>
>> It may make sense to pay for a custom solution tailored for
>> specific needs.
>>
>> It may make sense to go for a standard solution and use it
>> the standard way.
>>
>> What I am skeptical about is the approach of taking a standard
>> solution and do extreme customization.
>>
>> That sort of defies the point of the standard solution.
>
> Let us as an example say that we have a custom application
> with 1 million lines of code.
>
> Let us say that there exist a standard solution with 5 million
> lines of code which provides the same functionality plus a
> lot extra (some useful - a lot irrelevant).
>
> If the standard solution need 1% customization, then that
> is only 50000 lines of code. And there may be a business
> case. Obviously exact fit to requirements would need to
> be evaluated, but potentially it could make sense.
>
> If the standard solution need 40% customization, then
> that is 2 millions line of code. And it seems very unlikely
> that there is a business case. It would make more sense to
> add to the custom application.

I recall an app I provided maybe 30 years ago.

The users sold wholesale sporting goods. The marketing people were quite
inventive with pricing schedules and such.

So, an invoice went out to a customer with maybe 100 lines. The customer
complained that they didn't get the proper pricing.

What the users were doing was issuing a credit, for every line on the shipment,
so another 100 lines to be entered. Of course, during the correction,
additional errors could be introduced. Then key in another invoice, 100 lines,
with the correct pricing, which could incur additional errors.

Trust me, there were keying errors, which then caused the entire process to be
repeated again, and again, and again ...

:-)

Now, before someone mentions just issuing an adjustment in A/R, consider the
company had some sophisticated sales analysis, which was used among other things
to allow marketing to plan for the next year's activity. So getting the correct
sales data was sort of critical. Imagine needing to get your order into a
factory in the orient at least 6 months ahead of time.

Anyway, I quickly realized that all the relevant data was already available. I
designed an app that would read the original invoice data, and reverse it, then
go through it again allowing the user to just correct whatever needed to be
changed. Rather simple to program, and made a huge difference in the company's
operations.

Just an example of where a tool that provided exactly what is required can be so
essential to a business. The "standard method" was all the re-keying, and
re-keying, and re-keying ...

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

On 10/24/22 16:42, Arne Vajhøj wrote:
> On 10/24/2022 10:06 AM, Dave Froble wrote:
>> On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
>>> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>>>> When Banner was brought in to replace the custom apps on VMS at the
>>>> University it was understood upfront that everything was going to
>>>> change the users were the one's that would have to adapt.
>>>>
>>>> Compare that to where I worked in 1980 where I was tasked with
>>>> developing a microcomputer based data entry system to get the
>>>> "keypunch" people off the mainframe to free it up for production
>>>> and development work.  The first requirement was that what I was
>>>> to develop had to present itself to the users exactly like what
>>>> they had been using on the Univac-1100.
>>>> How times change.
>>>
>>> Usually adapting usage to the standard packages way of doing things
>>> is the smart approach.
>>
>> This is where Arne departs from reality ...
>>
>> He seems to believe in "lowest common denominator" ...
>
> > Reality is that some people suffer with poor tools, and if a well
> > designed package can be found, it can be an improvement.
> >
> > The other side of that is that some people are working with tools that
> > have been designed and refined over time to be exactly what they need,
> > and anything else will affect their work, sometimes quite drastically.
>
> Not really. I don't think you got the point.
>
> It may make sense to pay for a custom solution tailored for
> specific needs.

Sites like the University already had this. Developed over many
years and lots of man hours.

>
> It may make sense to go for a standard solution and use it
> the standard way.

Why would that make sense if you already had (and had paid for)
the working solution your going to replace?

>
> What I am skeptical about is the approach of taking a standard
> solution and do extreme customization.

I doubt any of them allow "extreme" customization.

>
> That sort of defies the point of the standard solution.

The big question is why even consider a "standard solution" if you
already had a perfectly functioning system specific to your environment?

bill

On 10/24/2022 5:49 PM, Dave Froble wrote:
> On 10/24/2022 4:42 PM, Arne Vajhøj wrote:
>> What I am skeptical about is the approach of taking a standard
>> solution and do extreme customization.
>>
>> That sort of defies the point of the standard solution.
>
> Some apps were designed for customization, within some limits ...

Most applications are OK to customize within what was foreseen
as being customizable, but can be hell outside that.

Arne

On 10/24/2022 6:56 PM, Bill Gunshannon wrote:
> On 10/24/22 16:42, Arne Vajhøj wrote:
>> It may make sense to pay for a custom solution tailored for
>> specific needs.
>
> Sites like the University already had this.  Developed over many
> years and lots of man hours.
>
>> It may make sense to go for a standard solution and use it
>> the standard way.
>
> Why would that make sense if you already had (and had paid for)
> the working solution your going to replace?

The model where you pay X to develop an application
and you use that for decades for zero annual cost
is not a common model.

A way more common model is to pay X to develop an application
and then every year pay Y to maintain and enhance the application
to meet new requirements.

With Y being 10-30% of X. Over the life cycle of the application
the maintenance cost are way higher than the initial development.

Reducing that maintenance cost can make sense.

>> What I am skeptical about is the approach of taking a standard
>> solution and do extreme customization.
>
> I doubt any of them allow "extreme" customization.

What do you call an ERP "customization" with a price tag
of 3 digit M$?

:-)

>> That sort of defies the point of the standard solution.
>
> The big question is why even consider a "standard solution" if you
> already had a perfectly functioning system specific to your environment?

A perfectly functioning system for yesterdays requirements
not for tomorrows.

Arne

On 10/24/2022 6:56 PM, Bill Gunshannon wrote:
> On 10/24/22 16:42, Arne Vajhøj wrote:
>> On 10/24/2022 10:06 AM, Dave Froble wrote:
>>> On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
>>>> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>>>>> When Banner was brought in to replace the custom apps on VMS at the
>>>>> University it was understood upfront that everything was going to
>>>>> change the users were the one's that would have to adapt.
>>>>>
>>>>> Compare that to where I worked in 1980 where I was tasked with
>>>>> developing a microcomputer based data entry system to get the
>>>>> "keypunch" people off the mainframe to free it up for production
>>>>> and development work. The first requirement was that what I was
>>>>> to develop had to present itself to the users exactly like what
>>>>> they had been using on the Univac-1100.
>>>>> How times change.
>>>>
>>>> Usually adapting usage to the standard packages way of doing things
>>>> is the smart approach.
>>>
>>> This is where Arne departs from reality ...
>>>
>>> He seems to believe in "lowest common denominator" ...
>>
>> > Reality is that some people suffer with poor tools, and if a well
>> > designed package can be found, it can be an improvement.
>> >
>> > The other side of that is that some people are working with tools that
>> > have been designed and refined over time to be exactly what they need,
>> > and anything else will affect their work, sometimes quite drastically.
>>
>> Not really. I don't think you got the point.
>>
>> It may make sense to pay for a custom solution tailored for
>> specific needs.
>
> Sites like the University already had this. Developed over many
> years and lots of man hours.
>
>>
>> It may make sense to go for a standard solution and use it
>> the standard way.
>
> Why would that make sense if you already had (and had paid for)
> the working solution your going to replace?
>
>>
>> What I am skeptical about is the approach of taking a standard
>> solution and do extreme customization.
>
> I doubt any of them allow "extreme" customization.
>
>>
>> That sort of defies the point of the standard solution.
>
> The big question is why even consider a "standard solution" if you
> already had a perfectly functioning system specific to your environment?

Because some idiot declared "but we need to use WEENDOZE" ...

Or some other OS of the week ...

Who ever made a name for themselves by doing nothing?

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

On 10/24/2022 7:30 PM, Arne Vajhøj wrote:
> On 10/24/2022 6:56 PM, Bill Gunshannon wrote:
>> On 10/24/22 16:42, Arne Vajhøj wrote:
>>> It may make sense to pay for a custom solution tailored for
>>> specific needs.
>>
>> Sites like the University already had this. Developed over many
>> years and lots of man hours.
>>
>>> It may make sense to go for a standard solution and use it
>>> the standard way.
>>
>> Why would that make sense if you already had (and had paid for)
>> the working solution your going to replace?
>
> The model where you pay X to develop an application
> and you use that for decades for zero annual cost
> is not a common model.

I'd agree with that. Things change. The apps must reflect the changes.

> A way more common model is to pay X to develop an application
> and then every year pay Y to maintain and enhance the application
> to meet new requirements.
>
> With Y being 10-30% of X. Over the life cycle of the application
> the maintenance cost are way higher than the initial development.

Now which side of your ass did you pull those numbers? 10-30% is ridiculous.

Now, if one wants some type of maintenance agreement, that cost is outside
everything else, since you'd have that cost regardless of what you're using.

As for changes in the business, I'd guess that it might be zero to some rather
small number. Unless one was able to find a vendor wanting to fleece customers,
and one was dumb enough to select such a vendor.

> Reducing that maintenance cost can make sense.

In any reasonable situation, that never makes any sense. Any total replacement
will cost way more than anything else, and probably cause all kinds of business
problems. Just ask anyone who choose SAP.

>>> What I am skeptical about is the approach of taking a standard
>>> solution and do extreme customization.
>>
>> I doubt any of them allow "extreme" customization.
>
> What do you call an ERP "customization" with a price tag
> of 3 digit M$?

SAP

Back in the day I'd provide a lot more for a lot less.

> :-)
>
>>> That sort of defies the point of the standard solution.
>>
>> The big question is why even consider a "standard solution" if you
>> already had a perfectly functioning system specific to your environment?
>
> A perfectly functioning system for yesterdays requirements
> not for tomorrows.

NO, a perfectly functioning system for the past, today, and easily modified for
tomorrow, if that becomes necessary. Nothing stays the same, one advances or
regresses.

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

On 2022-10-24, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Now, before someone mentions just issuing an adjustment in A/R, consider the
> company had some sophisticated sales analysis, which was used among other things
> to allow marketing to plan for the next year's activity. So getting the correct
> sales data was sort of critical. Imagine needing to get your order into a
> factory in the orient at least 6 months ahead of time.
>
> Anyway, I quickly realized that all the relevant data was already available. I
> designed an app that would read the original invoice data, and reverse it, then
> go through it again allowing the user to just correct whatever needed to be
> changed. Rather simple to program, and made a huge difference in the company's
> operations.
>

I presume you checked to make sure that the invoice was for the current
open period and that you didn't allow them to reverse an invoice from
a closed prior period. :-)

Reversing an invoice should be a standard feature of any package _AND_
it should be access restricted so that you need a manager's authorisation
to do it so they know if they have a developing problem with a specific
employee or employees.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-10-24, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 10/24/22 16:42, Arne Vajhøj wrote:
>>
>> It may make sense to go for a standard solution and use it
>> the standard way.
>
> Why would that make sense if you already had (and had paid for)
> the working solution your going to replace?
>

The old system runs on VMS. The new system runs on Linux.

Manager: VMS is old and different. We are standardising on Linux instead.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/25/2022 9:04 AM, Simon Clubley wrote:
> On 2022-10-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Now, before someone mentions just issuing an adjustment in A/R, consider the
>> company had some sophisticated sales analysis, which was used among other things
>> to allow marketing to plan for the next year's activity. So getting the correct
>> sales data was sort of critical. Imagine needing to get your order into a
>> factory in the orient at least 6 months ahead of time.
>>
>> Anyway, I quickly realized that all the relevant data was already available. I
>> designed an app that would read the original invoice data, and reverse it, then
>> go through it again allowing the user to just correct whatever needed to be
>> changed. Rather simple to program, and made a huge difference in the company's
>> operations.
>>
>
> I presume you checked to make sure that the invoice was for the current
> open period and that you didn't allow them to reverse an invoice from
> a closed prior period. :-)
>
> Reversing an invoice should be a standard feature of any package _AND_
> it should be access restricted so that you need a manager's authorisation
> to do it so they know if they have a developing problem with a specific
> employee or employees.
>
> Simon.
>

Picking nits again Simon?

My message was, sometimes being restricted to what's in a "standard" app can be
a real big problem for users.

Software should fit the business, not expecting the business to fit the software.

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

On 10/25/2022 10:48 AM, Dave Froble wrote:
> My message was, sometimes being restricted to what's in a "standard" app
> can be a real big problem for users.
>
> Software should fit the business, not expecting the business to fit the
> software.

In the end it is about money.

if increase_in_revenue + reduction_in_cost > cost_customization then
customize
else
do_standard
end if

There are absolutely cases where customization make sense - when
there is a tangible business benefits from doing so.

But there is also a lot of customization done because
"the old system worked this way", "we have always done it
this way" etc.. And even though having people learn new
stuff does come at a cost (time), then it is a relative
small one time cost and usually not worth customizing too
much.

One of the most important factors to keep IT cost down
is the will to say NO.

Arne