[SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

[Steve Tockey]

Les,
You wrote:

"It's worth reflecting on the process whereby software gets to the state of
"it sucks"."


Š

"Changes that fixed one problem would create many
more. The guy who wrote the code was a good man, very knowledgeable in the
process technology and smart. Unfortunately he did not have a professional
education."


Exactly. At the root of most problems I see in software is simply an utter
lack of PROFESSIONAL software engineering education. One of the threads
we're on here talks about Cyclomatic Complexity. Tom McCabe published the
original paper in 1972. 1972, for chrissakes!!! And yet, when I'm working
with developers in my customer organizations, before we talk about
cyclomatic complexity I ask who has ever even heard about it before (let
alone actually pay attention to it in their code). I usually have about a
10% positive response rate. 90% of so-called professional software
developers have no idea it even existes.

Now, move on to things like cohesion & coupling, TRUE encapsulation (which
is simply not possible unless one is doing Design by Contract),
Design-to-Invariants & Design-for-Change, etc. Again, utter cluelessness,
but even higher percentages than for cyclomatic complexity.

Somehow, hiring managers seem to think that being able to follow some
programming language's syntax rules is enough to make one worthy of the
salaries paid in this industry.

I wrote an article about this for IEEE Computer that went out in the
November, 2015 issue:
https://www.computer.org/csdl/mags/co/2015/11/mco2015110096-abs.html




"It saddens me that humanity takes so long to learn."

Yes, me too. But as I wrote before on a related list:

Whether you knew it or not, many of the regulations in air transport today
can be traced back to a single event: the crash of TWA Flight 599 in
Kansas on March 31, 1931. That crash killed Knute Rockne, then coach of
the Notre Dame football team. Quote
(http://en.wikipedia.org/wiki/Knute_Rockne):

"The national outcry over the air disaster that killed Rockne (and the 7
others) triggered sweeping changes to airliner design, manufacturing,
operation, inspection, maintenance, regulation and
crash-investigation--igniting a safety revolution that ultimately
transformed airline travel worldwide, from the most dangerous form of
travel to the safest form of travel."


I suppose we simply have to wait for the software equivalent of TWA 599
before we can expect to see any improvement. Sigh.



-- steve




-----Original Message-----
From: Les Chambers <les at chambers.com.au>
Date: Tuesday, March 1, 2016 3:43 PM
To: Steve Tockey <Steve.Tockey at construx.com>, 'Derek M Jones'
<derek at knosof.co.uk>, "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: RE: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"

Steve
It's worth reflecting on the process whereby software gets to the state of
"it sucks". 
Some years ago I was a member of a team of 12 working on the start-up of a
latex reactor system. We were working around the clock on 12 hour shifts.
The core reactor control algorithms were not working as planned. That is,
not complying with what we called the English language description of the
reactors stepwise operation. In those days we called requirements the
English language (as though they belonged to an alien race from another
planet who could only speak English and who should probably stay there and
leave us alone). 
Critical discussions were occurring at the shift changeover meeting when
the
code would be handed off to the incoming shift. We were all having a
problem
understanding the code. Changes that fixed one problem would create many
more. The guy who wrote the code was a good man, very knowledgeable in the
process technology and smart. Unfortunately he did not have a professional
education. He had been trained in the use of the state engine but I suspect
did not love or respect the model and chose to take some logical shortcuts
which resulted in the classical heavily nested if-then-else statements. We
had administered the state engine Kool-Aid but only by mouth. This guy's
lack of a professional background indicated that a drip would have been a
more effective, straight to the bloodstream. The other thing we failed to
do
was conduct more in-process review of his work.
As the light thickened the 12 good men and true resolved to nurture his
code
- fix it with a tweak here and a bug fix there. We were under a lot of
pressure day and night from the night's black agents (the sales guys) who
were running out of product to sell. When you do a major plant upgrade you
usually fill the storage tanks and plan on a one-month shakedown and
testing
period once all the equipment including software is in place. We were
running out of time. The feckless bug fixing went on for four shifts (48
hours non-stop). At the fourth shift change meeting we all looked at each
other and finally accepted the truth: this was a hack, what we were doing
was dangerous and unsustainable. The code would not be understood by future
maintainers and was likely to have more bugs than we had found. And as the
crows made wing to the rooky wood, under extreme pleasure (the sales guys
could care less about the beauty of our code) we resolved to rewrite
sections of the code. The thing was it only took a 12 hour shift to do. We
kicked ourselves for not making this decision on day one.

This is a microcosm of how crap code gets into production. It is not
conceived and developed against sustainable models, grows like Topsy and
it's "suckiness" is discovered too late for a major rewrite. There simply
isn't the money in the pot even if you are a large corporation. There are
several large corporations in the same position as your unnamed word
processor vendor. For example a well known purveyor of document reader
software has a committed team that would just love to rewrite the product
but is unable to assemble the funds. Right now they are flat out staving
off
attacks from Russians who have found vulnerabilities that allow them to
crash and invade PCs running the software at a high level of security.

Perhaps by now the uninitiated may appreciate how irrelevant a collegiate
debate on the ambiguity of a standard is to situations such as these. I
wonder if any standards bodies ever do a 360 review on what the profession
thinks of their standards and how they are used, or if they are used at
all.
I recently had the opportunity to review the curriculum of the University
of
Queensland's Electrical Engineering and Computer Science Department. The
curriculum guy had never heard the number 61508. In Bristol last year I
attempted to get a sneak peek of ISO standards work and asked PBL about the
process of signing up as an industry reviewer. He regarded me with horror.
I
stood by for the gush of boiling oil from the top of his silo.

It saddens me that humanity takes so long to learn. Shakespeare knew about
the ramifications of piling bad on bad in 1605 when he had Macbeth say:

Light thickens, and the crow
Makes wing to th' rooky wood.
Good things of day begin to droop and drowse;
Whiles night's black agents to their preys do rouse.
Thou marvel'st at my words: but hold thee still.
THINGS BAD BEGUN MAKE STRONG THEMSELVES BY ILL.

Cheers
Les

PS:
By the way I'm not against Fagan reviews, they can be good value when used
as designed. I wrote an essay on my first exposure to them here:
http://www.systemsengineeringblog.com/extreme-review-a-tale-of-nakedness-al
s
atians-and-fagan-inspection/

... but they are designed for inspection of completed deliverables, they
are
the end game not the arc of the story.

-----Original Message-----
From: systemsafety
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Steve Tockey
Sent: Wednesday, March 2, 2016 5:07 AM
To: Derek M Jones; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"


Derek,
An interesting position, but please consider this alternative view:

I'm using a popular word processor for writing my new book. I've seen
reports from credible people who have evaluated that code base, they all
report, "it sucks". I know people who work for that company, they freely
admit "our code sucks". No question, it's bad code.

As a user, I have already logged 93 unique defects against the product.
The most serious defect is that it can go into an infinite loop after a
Paste. When it does, I have to go to the operating system control panel to
kill the process as it is consuming 100% of one CPU and not listening to
any user input. My habit now is to Save-Cut-Paste instead of the normal
Cut-Paste to minimize lost work (it's supposed "saved" version is up to 20
minutes of editing behind). Web searching reveals that this
infinite-loop-on-Paste defect has been in the product since 2011 and has
still not been fixed. I can't think of any other way to put it, it's bad
code.

But here's the deal, I can't invest anything in that code. It's not my
code to invest in. I'm just the poor hapless user who has to deal with
their crap because that's what the publisher wants.

Your position is fine from a supplier-side perspective, but what about the
consumer-side? Shouldn't we have a say? At best, all I can do economically
is be true to my vow of never spending another penny with that vendor.
They've gotten enough of my money over the years for their schlock
software. No more.

It's not my option to invest in their code. All I can do is make it
obvious that I refuse to spend any more with those schmucks.


Regards,

-- steve




-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Derek M Jones <derek at knosof.co.uk>
Organization: Knowledge Software, Ltd
Date: Tuesday, March 1, 2016 8:13 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"

Steve,

> My point is that it's not a simple thing to precisely define "bad code",
> neither is it a simple thing to detect it or repair it.

Bad code can be precisely defined by the amount of resources you
are willing to invest in finding and fixing any problems it might
contain.

If the code might contain problems that you are not willing to invest
in doing anything about, then it is obviously good enough.

How you choose to invest the resources you have in finding/fixing
problems is a technical issue.  There is not a lot of hard data
available to help make the optimal use of resources, so people
tend to follow the herd and sprinkle in a few of their own preferences.

-- 
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE