[SystemSafety] Another question

Pekka Pihlajasaari pekka at data.co.za
Sat Sep 22 00:05:52 CEST 2018


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


More information about the systemsafety mailing list