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

Fri Mar 4 01:38:51 CET 2016

"That red door stopper is primarily customer oriented."

Sorry, I'm missing the point of that.

And, FWIW, it seems the point of my "Totally agreed. Maybe someone should
write a book on that topic? Oh, wait . . ." quip got missed on your end:

http://www.amazon.com/Return-Software-Maximizing-Your-Investment/dp/0321561
49X/ref=sr_1_1?s=books&ie=UTF8&qid=1457049439&sr=1-1&keywords=return+on+sof
tware

"You seemed to have missed the point(s) of writing software.
Or rather, are focusing on the reasons for using software."

No, I don't think I have. The point of writing software can be considered
from two levels. At one level (call it "direct"?), software is written to
automate a solution to some presumably non-trivial problem. The other
level (call it "indirect"?) is to make money by selling a product, which
in this case just happens to be software.

The reason for using software is primarily direct: I have a problem that
needs to be solved and software exists that solves the problem more
efficiently and/or effectively than some (any?) other solution.
Indirectly, sometimes to get access to that software/solution I have to
pay money.

Microeconomics 101, right?

"I think you are suffering from survivorship bias
https://en.wikipedia.org/wiki/Survivorship_bias"

Again, no, I think not.

"Code has a finite lifetime, often surprisingly short.
I think its often cheaper to fix faults in code that survives
than invest lots of code, much of which does not survive."

Of course code has a finite lifetime. But I think it's worth asking, "what
drives that lifetime to be what it is?" I see two drivers. One is product
(functional) obsolescence, the world moves on and other, presumably more
capable, software becomes available. Why use the old, limited version when
a new all-the-bells-and-whistles product is available?

The other is deterioration. Unlike hardware things that wear out because
of use, software tends to deteriorate because downstream maintainers
violate initial design principles, etc. It's the on-going accumulation of
so-called technical debt. If the software starts off with a huge amount of
technical debt from version #1, it only gets worse from there. On the
other hand, if version #1 is very clean and downstream maintainers work to
keep it that way, code lifetimes can be quite long.

A case in point is Automated Test Equipment (ATE) for the Boeing 777 in
Everett, WA. The version #1 project was done in 1993 for the 1994 roll out
and eventual ongoing production. For whatever reason (Boeing culture,
ultimately) the tradition had been that every airplane program did things
the way they wanted. Code-wise, 737 ATE was completely different than 747
ATE, which was completely different than 767 ATE (C code on MP/UX 9),
which was completely different than 777 ATE (C++ on HP/UX 10) which was
completely different than 787 ATE (C#/.net). I know, because I worked on
767 (1991), 777 (1993), and 787 (2006, as a consultant from my current
company) ATE projects.

Last I heard, Boeing management finally wised up and asked why there were
5 different ATE code bases when, really, testing one kind of airplane is
essentially the same as testing any other. The functional requirements on
all 3 code bases I worked on are remarkably similar. So they decided to
consolidate down to one ATE code base for all airplane programs. The
question is, which one did they choose? The answer is, 777 ATE. A 23 year
old code base is not only surviving, it's thriving. It's taking over
other--in some cases more recent--code bases.

Can code be developed in a way that:
*) Is cheaper to build (by about 50%) than mainstream software?
*) Gets delivered sooner (by about 50%) than mainstream software?
*) Has fewer delivered defects (by about 90%) than mainstream software?
*) Is cheaper to maintain (by between 75% and 90%) than mainstream
software?

The answer is yes in all cases.

The big issue is that it's a decidedly different approach to building and
maintaining software than people are used to:
*) Model-based requirements and design that uses common, comfortable
notation (UML) on the surface but has (admittedly, semi-) formal theoretic
foundations
*) Explicitly integrates engineering economy into technical decision making
*) Depends on frequent model review to contain defect cost growth
*) ...

Maybe someone should write a book about THAT. Oh, wait . . . Somebody is.
Let me be obvious: of the anticipated 26 chapters, about 20 of the
chapters are complete enough to share. Anyone can let me know if they want
them.

My point is that it *is* possible to write clean, reliable, low defect,
maintainable, etc. software. I've been doing it for years. You just can't
do it the way mainstream organizations do it. And the answer ain't
"Agile", either (although Agile and model-based development isn't at all
contradictory). I've been doing model-based development since 1985. For
the life of me, I can't understand why the industry pigheadedly continues
to muddle through with shitty processes that result in late, expensive,
shitty products when there IS a better way. A PROVEN better way.

But since "that's not the way we've always done it", the approach gets
marginalized. Sigh.

-- 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: Thursday, March 3, 2016 12:27 PM
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,

> Fascinating, because I argue that it's not at all difficult to write
> software that friggen' works: software that does what it's intended to
>do,

You seemed to have missed the point(s) of writing software.
Or rather, are focusing on the reasons for using software.

> do so. The research I've done into contemporary software organizations
> shows that on average, over 60% of their capacity to do work is wasted in
> going back to fix stupid mistakes that they made earlier. We seem

I think you are suffering from survivorship bias
https://en.wikipedia.org/wiki/Survivorship_bias

Code has a finite lifetime, often surprisingly short.
I think its often cheaper to fix faults in code that survives
than invest lots of code, much of which does not survive.

Of course there is a cutoff point below so little has been invested
that rewriting is cost effective.

> "There is a huge hole in the software engineering curriculum: Economics."
>
> Totally agreed. Maybe someone should write a book on that topic? Oh,
>waitŠ

That red door stopper is primarily customer oriented.

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