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

Fri Mar 4 02:02:01 CET 2016

There's a neat idea called technical debt, the more you cut the corner to
get the job done the bigger that debt gets. Unless you turn around and pay
it down that debt eventually gets transferred to the customer, the next
project stage, the maintenance guys etc etc.

More broadly I see this as a particular case of the principal/agent
problem. Of course one of the solutions to that particular problem is the
imposition of professional standards via legislation or professional
bodies.

On Fri, Mar 4, 2016 at 11:38 AM, Steve Tockey <Steve.Tockey at construx.com>
wrote:

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

-- 
*Matthew Squair*
BEng (Mech) MSysEng
MIEAust CPEng

Mob: +61 488770655
Email: MattSquair at gmail.com
Website: www.criticaluncertainties.com <http://criticaluncertainties.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160304/92c48b21/attachment-0001.html>