[SystemSafety] Another question

[Les Chambers]

Steve 
You wrote:
The key is to realize that the reason the code exist in the first place is
to automate enforcement of some collection of “policies” and executing of
some collection of processes. 

My response:
This is true for some projects but not all. 
This raises a philosophical dimension not yet explored by this conversation.
Your statement applies to what I'd call "stable" environments where you're
churning out systems that are like many you've turned out before. It falls
down when you're doing something completely new - example: joint strike
fighter (there is one in the Smithsonian Air and Space Museum, I was looking
at it more than 10 years ago - the policy that spawned the F35 was simple:
to defend the USA - implementation turned out to be a bit more complex). 
Further - I cite Henry Ford. "If I'd have asked them what they wanted, they
would have said, 'faster horses'." Where is the policy in that Steve?
Here's the thing, the more novel a system becomes the less likely you are to
have a definition of "right". So getting it "right" the first time is often
a bridge too far. 
In lunatic fringe environments "right" can only be defined looking back
after deployment. 
So then you get to rework it.
What do you call that? Non-value-added work? Defect correction?
I call it the value-added work. The real toil of creating something new and
useful.
We only really advance the cause of humanity when we are faced with a
situation where we have no idea what to do. So we do something. Then we try
again, and over time we make it right. Rework metrics are typically ugly in
these environments. They should be pretty in well understood "stable"
environments. For this reason metrics should not be compared between the
every-day and the lunatic fringe. All metrics should be qualified by the
stability of the environment in which they are gathered.

Les

PS. I am with you on the UML. It's just a container for all the modelling
techniques we've developed over the past 50 years. No developer has to
consume all the Kool-Aid. You just take a sip and use what's useful in your
own special context. Why anyone would take a dislike to it is a mystery to
me.

-----Original Message-----
From: systemsafety
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Steve Tockey
Sent: Friday, September 21, 2018 6:43 AM
To: Derek M Jones; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Another question


Derek,

³You cannot claim that just because some factor contributed the largest
amount, that this was somehow bad.  What were the alternatives?²

When that one largest factor is rework, yes I can.

Rework, in the Deming sense, is waste. It does not add value to the
product being built or maintained. Requirements, design, construction‹and
to an extent‹testing work had better add value. The clear alternative is
to replace non-value-added work with value-added work.

60% non-value-added work cannot be the cheapest and fast way to anything.


‹ 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, September 20, 2018 at 6:57 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Another question

Steve,

> In my own work with software organizations I look at ³Rework Percentage²
>(R%): the percent of project labor hours that are spent later fixing
>things that were earlier claimed to be correct but found to be deficient.
>Estimates of rework normally average around 50%. I¹ve actually measured
>R% in five different software organizations:
> 
...
> All for a weighted average of about 62%.
> 
> This means that rework is the single largest contributor to project cost
>and schedule, and it is bigger than all other contributors combined.

So what, it may be the cheapest option.

Perhaps releasing an initial version was the cheapest and fastest
way of flushing out the unknowns.

You cannot claim that just because some factor contributed the
largest amount, that this was somehow bad.  What were the
alternatives?

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