[SystemSafety] Qualifying SW as "proven in use" [Measuring Software]

[Martyn Thomas]

In http://sites.nationalacademies.org/cstb/CompletedProjects/CSTB_042247
we argued that if the essential complexity of a system was so high that
it could not be developed and assured to the required dependability and
confidence, then the system should not be developed. That still seems
self-evident.

Martyn



On 01/07/2013 17:46, Steve Tockey wrote:
> Les,
>
> "I am intrigued at how long this conversation has endured. It seems to
> ignore
> the elephant in the room: the massively complex, fragmented and error prone
> environment in which modern software products run."
>
> I (personally) haven't been ignoring it, I'm just trying to take things
> one issue at a time.
>
> "This is the real world that software lives in these days. I encourage the
> brains trust on this list to engage with the aggressive ugliness that is
> the
> real world and consider how we might deal with it."
>
> Actually, there are some very effective strategies for dealing with the
> ugliness you're referring to.
>
> Ultimately, complexity is the enemy. The complexity isn't ever going to
> simply go away, but there are ways to manage it. First is to realize that
> (software) complexity comes in two fundamental types, "essential" and
> "accidental".
>
> "Essential complexity" is the complexity that's inherent in the problem
> being solved--like how to navigate a commercial airliner. "Accidental
> complexity" is the complexity that appears in the solution space:
> multi-threaded code, stored procedures, database denormalization, etc.
> Further, the accidental complexity comes in two flavors, "necessary" and
> "unnecessary". "Necessary accidental complexity is the accidental
> complexity that must be present in order to meet the (non-functional)
> requirements. "Unnecessary accidental complexity" is there because someone
> did something stupid, essentially.
>
> The first step is to simply go in with an attitude of, "Eliminate
> unnecessary accidental complexity and manage the rest"
>
> So my questions back to you on your web application example are:
>
> "How much of that complexity is essential to the problem being solved?" My
> feeling is that--having seen a lot of the web applications out there--not
> much of the complexity is truly essential.
>
> "How much of that complexity is necessary accidental complexity?" Clearly
> some of it.
>
> "How much of that complexity is unnecessary accidental complexity?" I
> might propose that a non-zero amount of the complexities you are talking
> about could be unnecessary. The programmer did it that way because it was
> hip, trendy, sexy, or it looked really cool on their resume/CV.
>
>
> Second, there are a set of very effective management tools that software
> professionals can use to manage the essential and necessary accidental
> complexities:
> 	Abstraction
> 	Encapsulation
> 	Cohesion
> 	Coupling
> 	Design-to-invariants & Design-for-change
> Properly applied by professionals who know what they are doing, what would
> otherwise be massively complex software systems become not that big of a
> deal after all. I assert that much of the apparent complexity in software
> systems was put there by "highly paid amateur programmers" who really
> shouldn't have been doing software development in the first place.
>
> "Our ability to control anything rests on the accuracy of our mental model
> of
> its behaviour."
>
> Agreed.
>
> "Right now large systems projects in complex environments defy
> our feeble attempts at modelling."
>
> Here is where I disagree. There are, actually, reasonable approaches to
> modeling software in some very complex systems.
>
> "Hopefully this will not always be the
> case."
>
> It doesn't need to be, the problem was largely solved 20+ years ago IMHO.
>
>
> Cheers,
>
> -- steve
>
>