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

[Bakul Shah]

> On Sep 16, 2017, at 12:12 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> I would claim that the issues of maintainability, guilds or other standards
> for programmers, etc. is really a management issue.
...
> 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.

I think we can do a lot without requiring a PhD. Programming
may be a commodity but there is a need for introducing more
professionalism. Or "good habits" if not "good taste".

It is clear by now that in many cases software quality is no
less critical than the quality of work needed in building
critical physical infrastructure (which in turn is also now
affected by s/w quality!). Software has become quite pervasive
& pretty much everything seems hackable (in the break-in sense).
While security is a separate issue, at least we can try to not
make breaking in easy via buggy software.

I don't know what the solution is. I am leery of any
"professional programmer" kind of certification as being
sufficient. I don't think we even know what that should
entail. Schools already teach software but these graduates
don't seem prepared enough for the real world.

One thing that does help is mentoring. But we can't rely on
managers for that. Managers are like general contractors,
responsible for coordination and project delivery on time.
But while time to deliver is measurable, measuring quality is    
far more nebulous and in my experience this delivery on time 
goal almost always trumps delivering quality. Second, even a
good manager is simply not going to have time to train people
+ his bonus doesn't depend on that.

> 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 did this for 13 years. I enjoyed some aspects like solving
problems others failed at but overall fixing problems that
shouldn't have been created in the first place was rather
unsatisfying. I much preferred jobs where I had the freedom
to build things from scratch.

> 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.

Reminds me of the an Intel processor I ran into once. They
wouldn't even admit the chip had a fault but after staring at
my client's code for a month that was the only thing that
made sense. The bug manifested only in a running system
involving a PC, client's hardware IO board, an IBM mainframe
and a phone system. So we flew down to client's customer
side, hooked up a logic analyzer on the PC bus, and within
15 minutes we had the trace proving the chip bug. Intel then
said, oh yeah, that problem is known and is on the errata list.