[SystemSafety] Logic

[Steve Tockey]

If you can find a way to scratch your way through all of the hype, there's
actually a lot of sanity in "agile the way it's defined and is really
intended to be used". Particularly when combined with other good practices
like "velocity based iteration planning", "test driven development",
"definition of done", and so on. But note that agile-as-defined and all of
these good practices are really just "discipline" in one form or another.
I blame all those undisciplined "highly paid amateurs" (again) for
completely bastardizing the message and mis-using the "agile" banner as
just another excuse to hack.

For what it's worth, I'm not an agile zealot. In fact, people often accuse
me of being an anti-agile zealot. I'm not that either. It's simply that
agile-as-intended is a great fit in some situations and other approaches
(like waterfall) are a great fit in others. The right tool for the right
job, really. It just takes intelligence to know when to use one tool vs.
another. And it takes discipline to use the tool the way it's supposed to
be used.




-----Original Message-----
From: Tom Ferrell <tom at faaconsulting.com>
Date: Wednesday, February 19, 2014 5:37 PM
To: Heath Raftery <hraftery at restech.net.au>,
"systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Logic

This, Sir, is an excellent reflection of the reality in which we find
ourselves today.  The massive rush to embrace 'agile methods' is a great
example of formalizing such an approach.

-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf
Of Heath Raftery
Sent: Wednesday, February 19, 2014 6:36 PM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Logic

On 19/02/2014 11:28 PM, Michael J. Pont wrote:
> It may - of course - be that the organisations I have closest contact
> with are atypical: they are, after all, a self-selecting group.
> However, while I'm sure that there are many organisations that have
> mature processes in place for the development of real-time embedded
> systems, I'm equally sure that this isn't the norm.
>
> If we assume - for the moment - that my model is correct, how do we
> ensure that the situation is different in 10 years time?

Great points. I'd suggest that changes to education focus, while very
important, wont be the necessary trigger. There needs to be a market
force. The scenario that plays out in my world goes like this:

1. Customer C requests doodad D to solve problem P.
2. Engineer A says right, no problem, we just need to articulate the
requirements and capture them in an unambiguous way. Formal methods can
help, I'll show you the way.
3. Engineer B says, no problem, in fact here's a prototype I whipped up.

We're almost there.

Engineer A studied embedded development at an excellent facility and has
sound knowledge of formal methods.

Engineer B taught herself programming and has been writing code since
before she could drive.

4. A's manager asks how D is coming along and A says fine, we're working
through the requirements.
5. B's manager asks how D is coming along and B says fine, look I've got
the LEDs flashing and the relays clicking.

Guess which engineer gets rewarded?

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