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

[Steve Tockey]

Derek,

"I think how we differ is in our willingness to accept that
it is ok to trade-off faults in delivered software for the opportunity
of making money."

No, not at all. I certainly agree that trade-offs can be made. A trade-off
point is there, it's always there. It has to be.
 

Where we differ is merely in where we believe that trade-off point has to
be. The trade-off point is entirely moveable, and is entirely driven by
the approach taken in creating software in the first place. The trade-off
point doesn't NEED to be where the mainstream of software development
assumes it must be.

It is easy to deliver code with one tenth the normal defect rate, both
cheaper and quicker. If it can be done cheaper and quicker and still have
fewer defects then the trade-off point has been moved. Significantly. 10x
improvement in quality doesn't require more time and cost, for most
organizations it actually requires less. A lot less. As I said before, all
it takes is a fundamentally different approach to how the software is
being created.

As long as you remain convinced that the trade-off point can't be moved,
then you will always be stuck with it being in the same place. Only when
you are ready to reject the notion that the trade-off point is immovable
will you be able to move it.



"What about spending a few tens of millions on a project
where the same system is implemented using various techniques,
with lots of data being gathered."

If I had a spare couple of million, I would. The trouble is that I don't.
Yet. But if you happen to know someone who does, let me know. I'll
certainly be willing to participate.

And, unfortunately, even then the data could be suspect. One early project
(not described in the earlier set) was to do model-based requirements and
design in parallel with a mainstream development project. The "real"
project would develop and deliver production code, our project would
shadow the production project and build requirements & design models (but
not code). The problem was that both teams talked with the users. When our
team talked to the users, we asked all kinds of questions (as driven by
the modeling) that would never have been asked in a typical mainstream
project. The next time the production team talked with the users the users
invariably said, "When we talked with the model team they clarified X.
We're sure you aren't aware of X. Let us make sure you know all about X
because if you don't then your product will be broken". It was not
possible for the mainstream production project to not benefit from our
presence. It will be difficult (impossible?) to control for that variable.




-- 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: Tuesday, March 8, 2016 8:09 AM
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,

Sorry for the delay in replaying.  My spam filter suddenly
decided that this list is sending spam.

> "You seem to be willfully refusing to deal with a reality that does
> not conform to your ideal view of how the world should be."
>
> This is the crux of where we differ, I guess. Yes, you are entirely
> concerned with how software *is* practiced today. And I respect that.

I think how we differ is in our willingness to accept that
it is ok to trade-off faults in delivered software for the opportunity
of making money.

> "Ok.  Can I have a copy of your data please.  I would be happy to
> analyze and write about your success."
>
> Unfortunately I don't have detailed to-the-person-hour data for these
> projects. Besides, that data would almost certainly be considered
> proprietary by the organization in question. That said, however, here's

A very common problem in empirical software engineering.

> data that I can give you:
...
> Is this enough data? Or, do you need more?

This is not data anymore than a list of unsuccessful projects is data.

Software engineering researchers need to start thinking big.
NASA spends billions for a few snaps of a distant planet.
What about spending a few tens of millions on a project
where the same system is implemented using various techniques,
with lots of data being gathered.

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