Re: [SystemSafety] Logic

From: Steve Tockey < >
Date: Fri, 21 Feb 2014 01:02:07 +0000

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_xxxxxx Date: Wednesday, February 19, 2014 5:37 PM To: Heath Raftery <hraftery_at_xxxxxx "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx 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_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx Of Heath Raftery
Sent: Wednesday, February 19, 2014 6:36 PM To: systemsafety_at_xxxxxx 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

The System Safety Mailing List

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Fri Feb 21 2014 - 02:02:17 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST