We have some code written by a pretty smart guy in 2017 on RHEL7. But he
knew MySQL RLIKE wasn't working properly, didn't document it, and coded
around it. When we upgraded to RHEL8, RLIKE worked differently. So I
feel your pain about OS upgrades.
That same smart guy left us with "perfect code," which I now have a
running list of 12 known defects, some have been remediated, some won't
be as it introduces more risk than it resolves, and some were never
documented - just fixed with snarky comments in the code.
My employer embraces CI/CD with 6 week sprints for the app developers.
This tells me they can plug in a new set of devs for the next sprint
with minimum ramp-up time. My team, on the other hand, does everything
the old way. We're not application developers - we maintain a
configuration and write utilities to assist the 3rd party product's
operation.
We're also getting a taste of what it takes to replace the two senior
people. It took me 3 years to really get the hang of this role and I've
been training my replacement for 5 years. He could probably take over,
but it would hurt the team, as we found out when I had Long COVID, with
amnesia, twice, which took me out of action for 2-3 months each time.
I'm not feeling too bad - I delivered my 10 year notice in 2017. They
can't ask me how old I am, but they can tell I'm getting up there. Yeah,
I'll go past that because I'm a money-grubbing bastard and I like my job.
Regards,
George Toft
On 7/4/2025 2:30 PM, David Schwartz via PLUG-discuss wrote:
Here’s one way to think of the impact that AI will have on the overall
programming process.
A while back I worked at a place that proudly liked to remind everybody that
they had attained “CMMI Level 2 Certification” and they were working hard on
Level 3. I’d never heard of that before, so I did some digging. If you’ve never
heard of it, here’s a link to their main site:
https://cmmiinstitute.com/
Reading over the various requirements, it seemed to me that the goal of this
was to make programmers (people) as fungible (replaceable) as possible.
Virtually every job involving software development and most IT jobs require
some time to become familiar with the project’s history, leading up to and
including its current state, before you start poking around making changes.
Since turnover of personnel is always a big issue for companies, one of their
biggest challenges is having sufficient documentation of past activities as
well as current state of things.
Reproducibility of work is a key concept, and my interpretation of CMMI goals
was to minimize the amount of time needed to integrate a new worker into a team
to the point where they can become productive.
The last job I had told me they figured it would take me 6 months of learning
to get to the point where I could start working on their main (legacy)
software. Over that time, I was just supposed to study the code and investigate
possible issue and repairs.
At one point after a few months I found what I believed was a bug. I documented
it and was able to duplicate it most of the time. But I was told flat out,
“THERE ARE NO BUGS IN THAT SOFTWARE!”
Well, yes there were. Because it had recently been migrated from Win 7 to Win
server 2012 (effectively Win 10) and this had to do with how the OS seemed to
be queueing up internal message requests. I did some research and found a very
subtle change had been made to Win 10, and no matter what I said, these guys
ignored me. Of course, nobody could explain the test data I had and even
accused me of rigging up a fake problem.
Anyway, this organizatin wasn’t interested in CMMI, but if they were, this
would have posed a big problem for them. Because part of the purpose behind
CMMI is to ensure that issues like this don’t come up.
But the place I worked earlier that was aboard the CMMI train was going all-in
to reach Level 3. That meant they put out policies like this: “Every line of
code you change needs to tie back to a specific change request. Any that don’t
will not be allowed to be pushed into a release.”
The implication being, refactoring can get you fired. And finding bugs in the
code yourself ... well, trying to fix some I found got me fired anyway.
The refactoring part really pissed-off a lot of devs there because the code was
already over a decade old and was written by people who weren’t very
well-versed with OOD/OOP and was quite gnarly. So the common practice there was
to fix up bits of code while you were fixing related code. This “no
refactoring” rule didn’t fit the aesthetics of most of their developers.
The VP of Engineering had been overheard saying something like, “I don’t trust
software developers to do refactoring any farther than I can throw them,
because it always leads to more errors!” He also didn’t trust us to write test
suites, and refused to fully staff a QA team to do it. Go figure.
Would you be surprised if I said this was the guy behind their CMMI initiatives?
Anyway, I’m guessing these guys will be jumping onto the use of AI to help do
their work, because it tends to write code that often looks like templates —
IOW, it will write the same code to solve the same problem pretty much every
time. (Just be sure you set the “temperature” setting to zero so it doesn’t
start hallucinating.)
It all gets back to “reproducibility”. AI can be relied upon to be highly
reproducible in terms of the code it writes (quirks and all) far more of the
time than human programmers. At the end of the day, I’m guessing that AI is
going to help far more companies be appraised at CMMI Level 5 than has been
possible in the past.
And those that replace most of their human programmers with AI will probably
have far fewer problems because nobody will be arguing about whether changes in
the environment can cause bugs to arise or not, because AI will refactor the
code, build tests to verify all of it, and fix it, while documenting the entire
process fully, clearly, and unambiguously — far better than 90% of most
developer can or do.
-David Schwartz
---------------------------------------------------
PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
