Re: Towards better embedded software (long)(was: Re: Where does C++ fit in?)

From: Jim Granville (no.spam_at_designtools.co.nz)
Date: 05/02/04 

Date: Mon, 03 May 2004 09:20:04 +1200

Steve at fivetrees wrote:
> "Will" <wv9557@yahoo.com> wrote in message
> news:4a885870.0405011834.733d413a@posting.google.com...
>
>>>No, it's down to us. You can't blame bugs on managers.
>
>
>>You make it sound like a manager vs engineers issue. Getting the bugs out
>>of the software is team work.
>
>
> Re managers vs engineers: not my intention. I'm a project manager as often
> as I'm a coder. As a manager, I'm dependent on my engineers for realistic
> time estimates for their parts of the project (and I'd better be sure I've
> done a good job of parcelling them out).
>
> Re getting bugs out as team work: I'm all for team work, sure. But (as I've
> said many times here) I don't believe in debugging, period. I *do* believe
> in not having bugs in the first place. That's down to a certain attitude;
> managers play a large part in fostering and encouraging this attitude, but
> engineers are the ones who embody it.
>
> Many (too many) engineers - and managers - don't believe this is possible in
> practice. It's noticeable to me that the best engineers I've worked with
> *know* this is possible, and deliver it routinely.

'bugs' is a very widespread term, and means different things to
different people. Quite often, errors in design do not appear when the
SW-coder does the testing : They are testing what it SHOULD do, and also
travelling along known state-paths.

  I have seen many problems surface where what it should NOT do became
very important.

  Quite often, the spec simply assumes some of that knowledge, and if
someting fails do to operator miss-use, do you call that a bug, or a
'variance in specification'
- and does the end user care WHAT it is called ! :)

  As a real example, my sister has a new oven, and the clock is a good
example of poor SW state engine design. ( well, I actually HOPE it's
faulty, as it's embarassing to see just how flakey this is )

  You'll know the type of thing :
A 24 Hr clock, and a handfull of buttons :
  TimerMode
  CookTime
  StopTime
  ManualMode
  +/- buttons.

Timermode did work for maybe half a dozen tries, for the first half
hour, then it went '100% out to lunch'.
The button itself is OK, as that's needed to set the clock.
Manual mode _mostly_ overrides what is happening, and sets to manual
( but not always )
-ve button has some 'extra feature', and in some modes, will trigger
CookTimer
After a AutoCycle the BEEP halt works 100%, but the return to manual
mode works very rarely.
Mostly, starting a Mode gives you a 4 second display-grab window, in
which to start +/- defines. But not always....

The only mode that seems to be consistent is SET TIME, and maybe that's
considered a Spec Pass ?! :)

  Power-off and on, with reasonable OFF times makes little difference,
tho I suspect a really-long off time might help..

  I've asked the manufacturer if this is known behaviour, but I'm
not holding my breath.

  I did find this on the web:
http://cs.anu.edu.au/student/comp2110/resources/alarm-clock-v1.html
http://cs.anu.edu.au/student/comp2110/resources/alarm-clock-v2.html

which is a pleasing sign that some CS courses talk about specs....

-jg

Quantcast