in reply to Perl Elitist Code vs Functional Code

There is, of course, the practical necessity for making a business-case for change of any sort.   Change itself is always de-stabilizing.   Depending on the importance and the visibility of the system, you must design and plan the change process very carefully.

Replies are listed 'Best First'.
Re^2: Perl Elitist Code vs Functional Code
by Your Mother (Archbishop) on Feb 01, 2018 at 00:07 UTC
    Change itself is always de-stabilizing.

    RFC:MUST it be always?

    Here you are then: Bug fixes are always destabilizing. They change the code and all change is destabilizing and, as the Great White Shadow teaches, change is to be feared. Therefore the practical necessity, lest one tread on the serpents of chaos, for making a valid business case in this market of synergistic tendencies toward the supreme bounds of workaday entropy hemmed by the ubiquitous market demands for profit realization within paradigm changing certainties of all battle-tested stripes. Waterfall! Sea change!!! {Cough} {Cough} Beware… You didn't know to be careful with important and visible systems before this moment—change management is a completely alien concept to absolutely all naïve elitists—but now you do!!!!11!!!11

[reply]

In Section Seekers of Perl Wisdom