[SystemSafety] Another question

Olwen Morgan olwen.morgan at btinternet.com
Sat Sep 22 02:30:59 CEST 2018


I go along with this. I think it is quite clear what "rework" means in a 
software engineering context. Prototyping is easily distinguished as such.

A few years ago I was asked to prototype a GUI for a tool to program a 
PLC-like device. The reason for the prototyping was that the company had 
had adverse feedback from some customers about its existing GUI. I had a 
completely free hand to do the prototype but when I had done it, it was 
thought too much of a departure from the existing GUI and the decision 
was made simply to modify the existing product. Sometimes you do have to 
try things to help people get their ideas straight about what they want 
- but this should never be confused with incremental development. A 
prototype is a prototype in whatever branch of engineering you're in. 
Even civil engineers doing megastructures still make scale experimental 
models from time to time.

Unfortunately, there is a depressing tendency, mainly among managers, to 
say that since a prototype is close to what is wanted, it can be 
re-engineered for the real development. Sometimes it can but that way 
has lain the perdition of many a failed project.


O


On 21/09/18 23:05, Pekka Pihlajasaari wrote:
> 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



More information about the systemsafety mailing list