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

[Derek M Jones]

Steve,

> "That red door stopper is primarily customer oriented."
>
> Sorry, I'm missing the point of that.

I thought you were making an oblique reference to your book (rather than
missing out a link to amazon) and "red door stopper" was my oblique 
reference to it (well, the spine on my copy is red and it is printed
on a heavy stock).
A lot of the material discusses software/hardware/system economics
from the customer perspective.

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

Making money is the indirect reason for writing software?
 From a developers point of view probably, yes.
 From any other point of view?  I suspect 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

A very important question.  I'm not sure I have the answer, but I
data data showing it happening at multiple levels.

Functions gets rewritten, or deleted because they are not needed.
Libraries get reworked or replaced by other libraries.
Programs get replaced by other programs.

The amount of code that makes it through to active maintenance is
often a relatively small percentage of what got written.

The benefits of any upfront investment to make savings maintaining
what survives to be maintained has to be compared against the
costs for all the code that got written, not just what remains.

Some analysis based on a product lifetime dataset:
http://shape-of-code.coding-guidelines.com/2012/10/23/break-even-ratios-for-development-investment-decisions/

> The big issue is that it's a decidedly different approach to building and
> maintaining software than people are used to:

The difference between safety critical software and most commercial
software is the cost of a fault and who pays the cost.

The company that sold you the book production software you referred to
earlier are not contributing towards the cost of your failures.
Sellers of systems containing safety critical software are likely to be
in the firing line and the costs are probably high to sky high.

-- 
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com