8 Feb
2022
8 Feb
'22
6:22 a.m.
And that reminds me of the old "Three Envelopes" joke:
A new CEO takes his seat at the helm of a large corporation
He finds three envelopes on his desk, numbered 1 to 3, and a note.
"Dear successor,
On this desk you find 3 envelopes that will help you in times of a
crisis. Open them only in the order they are numbered, and only when
you face a crisis that you cannot manage.
Best of luck".
He stores them in his safe and goes to work. But the economy isn't
picking up, the corporation isn't doing too well and the board wants
an explanation. He decides it's time for the first envelope. He rips
it open and reads:
"Blame your predecessor".
And he does. He steps up at the press conference and blames everything
on the shortcomings and nearsightedness of his predecessor and how he
just needs a bit more time to turn things around. Everyone is pleased
and he remains CEO.
But after a while, the displeasure isn't waning and the corporation
isn't doing any better. Another press conference is held and he rips
open the next envelope:
"Call for reorganizations".
And he does. He presents a great reorganization project with no stone
remaining unturned, this will surely improve productivity and move the
corporation into the future. Everyone's so busy reorganizing that
nobody can even notice how the corporation is running worse and worse,
until there's really no way to cover it up anymore. He reaches for the
third and last envelope, hoping for the great reveal that will save
him once and for all. He rips it open and reads:
"Prepare 3 envelopes and a note".
On 2/6/22, Brad Spencer <brad(a)anduin.eldar.org> wrote:
Will Senn <will.senn(a)gmail.com> writes:
[snip]
This would appear to be a Not Unix conversation... but...
So... the idea that code would run that long was not at all valued at
my last job. The management found it simpler and better (for some
definition of better) to just reinvent everything every 3 to 6 years.
In the mean time, the languages used would change. The idea that one
would "have to waste time" figuring out how to use malloc() and free()
properly was not looked upon well when the development time would be
better spend solving the needed higher level problems. In other words
there literally was no interest in creating code that was going to be
maintained for more than about 6 years and in a lot of cases would not
be maintained more than 3 or even 1 year.
To bring this back to Unix somewhat... When I started there, everything
was a Solaris based private cloud (SmartOS by Joyent) running Java apps.
In the 5 years I was there, the move was from Java to Go, due to the
licensing changes that Oracle made to Java and then a move to
containers. SmartOS has a container technology that is sort of like
Docker, but since the majority of the containers in the world that
people know about are fully Docker in some form with Linux it wasn't as
compatible as required so SmartOS was dumped and everything was redone
in Azure public cloud with Linux and as much of the native Azure stuff
as they could stand to use. Make everything "green field" all of the
time, or something....
I didn't really agree with much of this, but I became pretty mercenary
as I got old and the place paid well.
--
Brad Spencer - brad(a)anduin.eldar.org - KC8VKS - http://anduin.eldar.org
I've
done this and I've employed people who have done this. We're
a dieing breed, the focus seems to be on programming languages and
tools for idiots. People don't want to learn the discipline it takes
to work with malloc()/free(). It's sad.
I completely agree. This is ridiculous. Do modern programmer's seriously
think that the old code wasn't complex or robust? Sheesh, there's code
out there that has run through more millions of transactions an hour for
more years than most of these folks have been alive. There's also code
that's been running without any updates, for decades. Most code written
by the newbreed won't run for a month without surfacing dozens of bugs.
Margaret Hamilton would prolly have some choice words for these folks.