[SystemSafety] Putting Agile into a longer perspective

[paul_e.bennett at topmail.co.uk]

On 23/10/2019 at 1:10 PM, "Olwen Morgan" <olwen at phaedsys.com> wrote:
>
>On 21/10/2019 20:41, Derek M Jones wrote:
>>
>> Lots of people have proposed theories, it's a shame that none 
>are based
>> on evidence (not that there is much evidence around).
>>
>The difficulty of obtaining hard reproducible evidence of the 
>effectiveness of development practices is a perennial curse of 
>software 
>engineering. On the other hand, there are cases where what theory 
>predicts should work actually turns out to do just that when it is 
>tried. The accomplishments of SPARK Ada are a case in point.
>
>While, if we are trying to be strict scientists, we should prefer 
>evidence-based evaluations over all others, we find ourselves at a 
>stage 
>where we have to try things that are theoretically reasonable 
>simply to 
>generate the evidence we wish we had at the start.
>
>On occasion, I find myself thinking Derek an insufferable Jonah 
>when he 
>bangs on about evidence. That's not because he isn't on rock-solid 
>ground but simply because the circumstances in which software 
>engineering is done are simply not able - at least yet - to yield 
>robustly reproducible data. We are not, I think, even at the stage 
>when 
>competent meta-analysis of diverse studies will actually give the 
>robustness of evidence we would really like. (Sadly, in this 
>respect, 
>software engineering resembles the dismal science of economics.)
>
>Yes we should always have in mind the need for evidence - but this 
>should not prevent us from trying out things that look promising 
>and 
>then, if necessary, suspending judgement for long enough for clear 
>evidence to emerge. Nor, should we, get too hung up on whether 
>evidence 
>is robustly reproducible in circumstances where confounding 
>factors 
>virtually preclude that possibility. We have to improve software 
>engineering starting from where we are. If evidence is currently 
>lacking, we simply have to content ourselves with the long haul of 
>amassing it painfully slowly in adverse circumstances.

Having a penchant for reading about failure, one of the books in my
collection is 'Software Failure: Management Failure – Amazing
Stories and Cautionary Tales' by Stephen Flowers ISBN 0-471-95113-7.

A little more anecdotal is 'If I only Changed the Software, Why is the
Phone on Fire?: Embedded Debugging Methods Revealed: Technical
Mysteries for Engineers' by Lisa Simone ISBN 0-7506-8218-3.

Both are good reads and have lessons for the software engineer, and
perhaps the management that are meant to guide them.

Technical Review is, in my opinion, the strongest tool to avoid the
introduction of bugs and fopars. That coupled with strong Change
Management will ensure you know what it is you produced. Its
correctness is still up to you though.

Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************