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

From: Steve Tockey < >
Date: Tue, 8 Mar 2016 17:28:21 +0000

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.

-----Original Message-----
From: systemsafety <systemsafety-bounces_at_xxxxxx on behalf of Derek M Jones <derek_at_xxxxxx Organization: Knowledge Software, Ltd
Date: Tuesday, March 8, 2016 8:09 AM
To: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx 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_xxxxxx

_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Tue Mar 08 2016 - 18:28:33 CET

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