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

Fri Mar 4 21:28:54 CET 2016

Derek,

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

Haha, yes, you got me. Good one. Touche'.

"A lot of the material discusses software/hardware/system economics
from the customer perspective."

It is supposed to describe economics from the decision-maker's
perspective. Assuming there's an eventual 2nd edition, I'll keep that in
mind. Thanks for pointing that out.

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

That's interesting data, yes. But remember, that data is limited by how
software development is being practiced today (by largely "highly paid
amateurs"), and not how software development SHOULD be practiced.

"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 of the software that gets built is intended to be single-use or is of
intentionally short lifetime. My experience is that's a very small subset.
I argue that what determines survivability of the vast majority of
software is, essentially, quality. High quality (I.e., well-structured,
clean, etc.) code that reliably automates a solution is far, far more
likely to survive than code that's crap (e.g., high technical debt) and is
riddled with defects so it is dubious in terms of getting the user to the
right solution.

Again, my core point is that mainstream software development is heavily
biased toward delivering defect-ridden, dubious solutions and with crap
code. Approaches exist that are heavily biased toward delivering code that
is not only reliable, but clean, well-structured, etc. Further, there's
essentially no net investment in these alternative approaches: the
dominant cost and schedule driver in mainstream development and
maintenance is rework of low-quality, defect-ridden code. That rework rate
has been measured at between 57% and 67% in four separate organizations of
between 100 and 350 developers each. It's not difficult technically
(culturally, that's a whole different story) to drive rework under 10%.
This is where my stated 50% reduction in development cost and schedule
come from: simply eliminating the majority of rework seen on typical
projects.

As well, the observed maintenance load reduction is between 75% and 90%.

Using your terminology from
http://shape-of-code.coding-guidelines.com/2012/10/23/break-even-ratios-for
-development-investment-decisions/

--- begin cut ---
Let d be the original development cost and m the yearly maintenance costs,
we start by keeping things simple and assume  is the same for every year
of maintenance; the total cost of the system over y years is:

d + y * m
--- end cut ---

I'm saying that I can make d1 and m1 such that:

d1 = 0.5 * d
m1 <= 0.75 * m

Therefore, clearly, for any y >= 0

d1 + y * m1 << d + y * m

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

Absolutely true, but irrelevant. You seem to be missing what I'm saying.
The benefits of a more systematic, disciplined approach apply in
essentially ALL software projects, not just safety critical ones. If I can
get your software developed--safety critical or not--in half the time, at
half the cost, with 0.1x delivered defects, with a minimum of 75%
reduction in long-term maintenance costs then why aren't you interested?
The answer seems to be, sadly, "Because I'm having too much fun doing it
the mainstream way and I'm simply unwilling to change".

I guess I'll just have to wait for the software equivalent of TWA 599.

-- 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 6:03 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,

> "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
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE