[TUHS] Maintainability, Guilds, RMS, etc. all lumped into one

[Jon Steinhart]

Well, here I go trying to be the voice of reason.  Not my natural state :-)

Can't see any good coming out of RMS bashing.  I'm one of those who thinks
that GNU/Linux is absurd; RMS had nothing to do with Linux.  I can imagine
that, like many of our peers, he has ego issues may feel slighted that Linus
gets more media attention than he does.  Maybe he would be happy if anything
built with GNU tools would append a tag line equivalent to the bandwidth-
wasting "sent from my iPhone" stuff on emails.  All that aside, he has had a
huge and positive influence with the GPL and by making many of the tools that
we all depend on available for free.  I remember that when I switched from
SunOS to Solaris that Sun started charging for the C compiler and I was very
happy to have gcc available.

I would claim that the issues of maintainability, guilds or other standards
for programmers, etc. is really a management issue.  And it's exacerbated by
what I have observed about management which is that it's not about managing
any more.  Since managers are theoretically responsible for programmers
sensible things don't happen when the managers are not competent.  Nothing
says it more than the Chief Security Officer at Equifax being a music major
with no relevant skills.  What could possibly go wrong?

Managers don't care about maintainability today, and I'm not sure that it
would matter if they did.  When I started working there was an expectation
that one would look after one's employer's interests and the employer would
look after yours.  That's pretty much gone for a number of reasons.  Few
programmers are going to worry about maintainability when they expect to
change jobs frequently.

As an aside, one of the reasons why I chose to work for myself is that I got
spoiled by having awesome management on my first job.  I remember Hank Macdonald
who I think was co-director of whatever branch of area 10 in which I was working
at BTL pulling up a chair next to me at 3AM one late night/early morning and
asking me how it was going.  I told him great except for some problems with
display flicker at which I was staring.  He thought about it for about 30 seconds
and said "I'll bet your delay constants are too big."  He was right.  I realized
that he was a director because he had mastered everything that everyone under him
was doing, not because he couldn't.  All other managers that I've had since were
Peter Principled.  Oh, and under Hank I had Joe Condon as a supervisor which was
another amazing experience.

When I went to work at Tektronix I had an expectation that I'd spend my entire
career there.  Of course, shortly after I started the technical founder was
replaced by an uneducated bean counter who looted the company.

But, I remember a day when someone who sat near me celebrated ER (engineering
release), which meant that his product went to manufacturing.  A day or two
later someone from manufacturing was sitting in the chair by his desk asking
questions.  This happened for a week or so and then that engineer's desk got
moved down into manufacturing.  I observed this and told myself that I would
never let that happen to me.

Another thing from Tek was that we supported products for ten years after ship.
That made maintainability and reliability important.  When someone makes a web
page component that's going to be around for a few months at best it's hard to
justify spending dollars on maintainability.

Final thing on this thread: get used to it.  As with any field, programming is
a commodity item now.  It's not a field populated primarily by people with PhDs.
Think about the number of baristas who were hired as programmers during the
.com boom.  And the "everybody must learn to code in high school" movement
is not about making more programmers like the ones on this list.  It's about
calling people programmers who don't even have the prerequisite skill of knowing
how to coffee drinks.  It's still a management problem because these people are
being hired to do jobs for which they really don't have the skill.  It's part
of the hollowing out of America; we still have great sounding names for a lot
of things that no longer really exist.

Fortunately for people like me, companies often get in serious trouble and need
someone who knows about bits and cycles and interrupts and propagation delay and
so on.  Good for the toy budget.

I'll illustrate this with an emergency job that I did a few years ago.  I was
hired to get something working with a hard 3 week deadline where the person who
had done the original work claimed that everything worked but it only worked
for him; nobody else could get it to work.  One of the things that I noticed
was that the absolute maximum electrical values on one of the parts was being
exceeded.  Mentioned it to the CTO who looked at it and told me that she had
looked at the circuit diagrams of the chips and wasn't worried.  I responded
with "I guess you've never worked at a company where you were responsible for
warranty repairs."  Turns out that she hadn't.  On the software side, I replaced
around 8,000 lines of undocumented code with about 300 lines including comments
and whitespace that did the job.  Probably less than 100 lines of actual code.
I see this over and over with the "we'll just import packages and make library
calls and call it programming" mentality.

BTW, it's not just software.  On this same project there was a problem internal
to the Atmel SOC.  Turns out that Atmel had just purchased a bunch of IP and
glued it together on the chip and even they didn't know the particular detail
that I needed.  Took several months of escalation to finally get it resolved.

Jon