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

From: Steve Tockey < >
Date: Fri, 4 Mar 2016 00:38:51 +0000

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

-----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 12:27 PM
To: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx 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_xxxxxx

_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Fri Mar 04 2016 - 01:39:03 CET

This archive was generated by hypermail 2.3.0 : Tue Feb 19 2019 - 14:17:08 CET