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

From: Steve Tockey < >
Date: Fri, 4 Mar 2016 20:28:54 +0000

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/

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.

-----Original Message-----
From: systemsafety <systemsafety-bounces_at_xxxxxx on behalf of Derek M Jones <derek_at_xxxxxx Organization: Knowledge Software, Ltd
Date: Thursday, March 3, 2016 6:03 PM
To: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx 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_xxxxxx

_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Fri Mar 04 2016 - 21:29:05 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:08 CEST