[SystemSafety] Another question

Steve Tockey Steve.Tockey at construx.com
Tue Sep 25 19:21:45 CEST 2018


Les,

“This is true for some projects but not all.”

Could you please give me an example or two of where this is not true?


“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.”

It is not rework per my definition. It is research. Rework is defined in
terms of “someone claimed it was right but it wasn’t”. There is learning
in research (which is, by definition, value-added). There is no useful
learning in rework. You learned that the old implementation is broken, but
that—in and of itself—is not really useful.

So my point is twofold:

One) iterative development is necessary in these research-type projects.
But that research / iteration is NOT rework. It is the necessary learning.

Two) whether any attempt at delivering functionality is research-type or
not is irrelevant. The semantic of the code delivered must match the
semantic of the desired functionality. If the two don’t
match—precisely—then it is a defect. And to correct that defect is
necessarily rework. So regardless of research-style or (what I call)
production-style project, a precise, concise, validated definition of the
desired semantic is not only useful, it is mandatory.

Most people call it a bug. I call it a defect. It is really only a
difference between the desired / agreed-to policy & process semantics and
the as-implemented semantics. Removing that difference is rework.



Cheers,

— steve




-----Original Message-----
From: Les Chambers <les at chambers.com.au>
Date: Monday, September 24, 2018 at 3:41 PM
To: Steve Tockey <Steve.Tockey at construx.com>, 'Derek M Jones'
<derek at knosof.co.uk>, "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: RE: [SystemSafety] Another question

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




More information about the systemsafety mailing list