[SystemSafety] Another question

[Steve Tockey]

Thank you, Pekka. You said it well.


— steve


-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Pekka Pihlajasaari <pekka at data.co.za>
Date: Friday, September 21, 2018 at 3:05 PM
To: DREW Rae <d.rae at griffith.edu.au>, Paul Sherwood
<paul.sherwood at codethink.co.uk>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Another question

Drew

Rework is performed to correct errors in a previous activity.
Prototyping,, or sketching a solution and intended to be thrown, away is
not rework. Admittedly, the distinction is often (deliberately) vague, but
the intent is clearly quite different.

Where Deming was interested in production losses where this distinction is
much clearer, work performed after a design gate review identifies it as
incorrect or deficient is not the same as rapidly iterating through
alternative implementations during exploratory development. Seriously, how
many developers are prepared to acknowledge that they are prototyping the
second of four possible implementations?

There is perhaps a mismatch in the understanding of waste. Where a
resource surplus is built into a project, a contingency could be claimed,
whereas in a production setting, this is clearly waste. The design nature
of software makes the distinction much more difficult to correctly
classify. Adding contingency to a project does not avoid waste. It is
simply an accepted as a cost.

Rework remains non-productive and implies an error in the process
somewhere between requirements and delivery. Denying that this implies a
failure earlier in the process prevents corrective action to reduce this
in subsequent projects.

Regards
Pekka Pihlajasaari
--
pekka at data.co.za	Data Abstraction (Pty) Ltd	+27 11 484 9664

-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
On Behalf Of DREW Rae
Sent: 21 September 2018 07:15
To: Paul Sherwood <paul.sherwood at codethink.co.uk>
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Another question

Yes, exactly as Paul said. A lot of what Deming considered "waste" wasn't
waste, just activity where the contribution to quality wasn't fully
understood. An activity that generates information isn't "waste". A
resource surplus that provides a buffer so that work can happen safely and
effectively even when there are input delays isn't "waste". A gap in
production for a worker to catch their breath and plan ahead isn't
"waste". 

Work is complex, and simple models of work often hide how success is
achieved. For better or worse, one of the ways people write software is to
write it quickly, see whether it does what it is meant to do, and then
write it again. Feel free to disagree with this way of doing things, but
you need better evidence that it is "waste" than simply that it involves
rework. 

Drew

On 21/9/18, 7:04 am, "systemsafety on behalf of Paul Sherwood"
<systemsafety-bounces at lists.techfak.uni-bielefeld.de on behalf of
paul.sherwood at codethink.co.uk> wrote:

    On 2018-09-20 21:42, Steve Tockey wrote:
    > ³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.
    
    Not necessarily. As much as I think the Agile folks are/were snake-oil
    salesmen, we can't expect to "get it right first time" for most
serious 
    human endeavours. In fact not even for tiny endeavours... try turning
on 
    a key logger and then replaying your own keystrokes to see how many
    errors you make.
    
    Our initial understanding of the requirements ** will be wrong **.
    
    > Rework, in the Deming sense, is waste. It does not add value to the
    > product being built or maintained.
    
    Tough. Better add contingency then :)
    
    > 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.
    
    This 'alternative' has never been clear on any real-scale project I've
    encountered in my whole career.
    
    > 60% non-value-added work cannot be the cheapest and fast way to
    > anything.
    
    Possibly true, but maybe not. We are short of evidence, as has been
    expressed in other emails.
    _______________________________________________
    The System Safety Mailing List
    systemsafety at TechFak.Uni-Bielefeld.DE
    

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE