[trustable-software] We've got this all wrong !

MacIntosh, JP j.macintosh at ucl.ac.uk
Mon Apr 16 11:11:12 BST 2018


Dear all,

The stark headlines today might actually provide a good opportunity to ask why so much irresilience has been sown so wide & deep into our systems. There's a lot of blame to go around. 

University computer science that refused to actually address what good Software Engineers would need competencies for as individuals, teams & networks is a major point but profiteering short termism has left "agile" with a lot to answer for. 

I'd not want to throw baby out with bath water though. We need to be clear about how the composability challenges would be addressed differently in an evolutionary system running at a pace we cannot bring to a juddering deceleration. 

The Wannacry issue is much wider than blaming sloppy code & mismanagement of agile's consequences. Nonetheless, a well crafted message about how to boast our digital or cyber resilience on the back of such headlines today, would indeed be timely.

There's the potential to blamed for crying wolf & ambulance chasing but a well calibrated statement could cut through. I'd suggest it includes the inability of cyber insurance to price the risks being run.

Regards
Jamie

Professor JP MacIntosh
Leadership Professorial Research Fellow, OVPR &
Director of the Institute for Strategy, Resilience & Security

+44 (0)20 3108 5068 (D1)
+44 (0)20 3108 5074 (D2)



-----Original Message-----
From: trustable-software <trustable-software-bounces at lists.trustable.io> On Behalf Of Paul Sherwood
Sent: 16 April 2018 10:33
To: Trustable software engineering discussion <trustable-software at lists.trustable.io>
Subject: Re: [trustable-software] We've got this all wrong !

Hi Edmund,

this seems like a bit of an overreaction to me, but I may be wrong. 
Please see my comments inline...

On 2018-04-16 04:38, trustable at panic.fluff.org wrote:
> Having returned from yet another project where the developers yet 
> again drive behaviour where the cost of doing requirements are too 
> much overhead and the decry how it prevents their ability to 'delivery 
> on schedule'

So a typical agile-style project, then? Was there no spec at all?

> It's lead to re-reading about the 5 paragraph briefing style
>       https://en.wikipedia.org/wiki/Five_paragraph_order
> It is particularly interesting to look at the way 'Intent' is 
> addressed here.
>       https://en.wikipedia.org/wiki/Intent_(military)

While I agree it's interesting, this is (yet) another way to cause decomposition/definition of requirements. AFAICT from what you've said above, the problem you're highlighting is that $project or $team ploughs ahead without establishing requirements at all.

> It has been my experience that particularly with the DevOPS community 
> they are given some 'Intent' and some 'Scene Setting' There is rarely 
> agreement until something is finally delivered and even only then 
> value is assigned to the effort expended.

Quite.

> In fact during this period what occurs is a decompision of the Intents 
> into actions which can be task tracked. This task tracking in turn 
> being adapted to by an approach like
>       https://en.wikipedia.org/wiki/Pomodoro_Technique
> to minimise waste.

I've never experienced or seen evidence of this technique on any project, anywhere. Again, it's interesting but maybe off-topic?

> Testing in these examples often come as an after thought again.

Clearly if folks have rushed past requirements, they'll have rushed past tests also - unless they've gone for TDD/BDD.

> It appear that it is mostly in place to prevent regression in the 
> software deployed within itself.

I think you're applying specific experience to the general, with no justification for doing so. Some projects have tests without requirements. That doesn't mean that the purpose of all tests is to prevent regression.

> So perhaps we need to look again at what we are trying to achieve here.
> The original hypothesis stated that for software to be trustable
>     * we know where it comes from
>     * we know how to build it
>     * we can reproduce it
>     * we know what it does
>     * it does what it is supposed to do
>     * we can update it and be confident it will not break or regress
> 
> None of this states that we need requirements to build software.

True.

I think there are two potential implications of that:

1) we change "t.software MUST have t.requirements" to "t.software MAY have t.requirements"

and/or

2) we allow that t.requirements can be defined after construction (which is already the case)

> None of this states that we need to have the entire source code of a 
> project

True. But if we don't have source code, and we don't have requirements, what exactly are we hoping to have trust in?

> If a tests only purpose is to confirm behaviour and prevent regression 
> in that behaviour, then tests being an after through isn't a problem.

I disagree with the first half of the sentence, as I already said. But even so the second half seems true :)

> There issue here might be confirmation bias but little else.

I don't understand this point.

> I'm suggesting that the defintions of software raised in
>    
> https://gitlab.com/trustable/workflow/blob/master/markdown/basics.md
> are in fact flawed because the begin with an assumption that we have 
> requirements and that tests confirm requirements.

As suggested above, we could relax MUST to MAY.

But IMO if we can't/won't define any t.requirements at all that we expect t.software to satisfy, it seems rather careless (and maybe
meaningless) to trust it.

> I'm going to suggest that in fact test are simply confirmation of 
> behaviour and that in fact we NEVER have requirements all we have is

Not true, I think. It's just that we rarely have (all of) them in advance of construction. And note that requirements may be carried over (implicitly or explicitly) from previous implementations.

> very 'hand wavy' intents which decomposition in the form of actions 
> performed in fairly unstructured manner with good luck delivery a 
> piece of software.

I'm rejecting your suggestion, based on the above.

I do accept that requirements are often retrofitted, but that doesn't mean they aren't requirements.

> At best we know we got there because someone pays the bill.

Possibly :-)

br
Paul

_______________________________________________
trustable-software mailing list
trustable-software at lists.trustable.io
https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software


More information about the trustable-software mailing list