Modern debuggers cause bad code quality

On 12/2/2014 4:26 PM, glen herrmannsfeldt wrote:
> Don Y <this@is.not.me.com> wrote:
>
> (snip)
>
>> Most embedded devices (until recently with the abundance of RELATIVELY
>> inexpensive graphical displays) have tightly constrained hardware.  And,
>> a design mentality ("from above") that discourages adding any recurring
>> costs that don't have direct ($$) benefits.
>
>> E.g., our washer/dryer still relies on 7 segment displays -- and a few
>> "indicators".  As a result, you get silly "messages" like "nF", "dO",
>> etc. instead of something more informative and HELPFUL like "No Fill.
>> Are you sure the water valves have been opened?"
>
>> This is *so* 1970's....
>
> and designers of appliances should test actual users to see how
> they respond?

YES!  We would smuggle a prototype game out to an arcade and
discretely sit back and watch how players (using THEIR REAL money)
reacted to it.  Is it too difficult?  Too easy?  How quickly do
they pick up the proper strategies to win?  How easily are they
distracted?  What "wows" them?  etc.

> I was just noting in another newsgroup about a CSE seminar:
>
> https://www.cs.washington.edu/events/colloquia/details?id=2594
>
> "The Programming Language Wars" on how little testing is done to
> see how users use programming language features.
>
> One test he did was to compare an existing language, using actual
> people to do the test, with a similar language using random ASCII
> characters in place of keywords.   See:
>
> http://dl.acm.org/authorize?6968137
>
> (It should work, even without an ACM subscription.)
>
> If that doesn't work, or you want to see other papers:
>
> http://web.cs.unlv.edu/stefika/Papers.php

Thanks, I'll have a look!

If you don't understand your users, you don't understand the *problem*.
So, why are you trying to solve "it" *instead* of understanding it?
Or, are you hoping your users' complaints will help you understand it??

<frown>

>> C'mon... how many millions of these things (different models, etc.) are
>> they selling WORLDWIDE?  Yet, couldn't afford even a set of 10 segment
>> displays?  Or, just *two* "digits"-worth?
>
>> Or, indicators for each of these conditions?
>
> Well, I might think that when no water comes out people figure to
> check the valves, but you never know.

If you sit there and *watch*/wait, you can figure this out.
But, walking up to it after it has started beeping at you means
you have to effectively unload it to see if anything is damp.

Why put a fuel gauge in a car?  When you're out of fuel, you'll
(eventually) figure it out!  :>

Door Open?

Imbalance?

"system error"?

Why display "dO" or "nF" at all?  Just put a big red light that
says "user screwed up"!

> But for cost-sensitive items, every cent counts.

Yup.  If the alternative is to replace existing product, then
its awful easy to rationalize a "kludge" approach:

"We'll let the user enter a *time* (of day) of 99:99:99 to access this
special feature..."

We had a $2K product many years ago and someone ventured the idea of
adding a "button to do...".  The laughter was intense:  "Good luck
with THAT!  What's it gonna cost... 25c??"

>> I've encountered two "camps" regarding how users are considered
>> in the design process.
>
>> One essentially ignores them and concentrates on trying to make the product
>> work.  I.e., as if just getting ANYTHING out the door will be a major
>> accomplishment -- "worry about the details (users), later"
>
> I have thought before about how many products come out before the
> theory is well enough understood. So, yes, in the beginning it is
> often true that getting anything out is a major accomplishment.

It's often a reflection of the folks pushing for the product not
understanding their market, either!

I saw a statistic (that I won't quote out of fear of misremembering the
specifics) that some *huge* number (percentage) of products are returned
because the user couldn't figure out how to use them (comfortably).

How large would that number have to be if it was "in-warranty repairs"
before it would raise some alarms??

>> "Power Level, 9; Time, 1 0 0; START"
>
> I still have a microwave with knobs. I always forget which order to
> put the power and time when using digital versions. I can change
> the power level while it is running, just turn a knob.

Exactly.  When shopping for a microwave oven for my in-laws many years
ago, I gravitated towards digital keypad; wife said, "No, this big
knob is something they can understand!"

There is no way to "soak" in our current washing machine.  Salesman
argues that "soak" doesn't make sense for a front-loader.  I counter,
"So, you're letting the technology determine what features the user
requires?  Why can't 'soak' simply be:  fill, agitate, pause, repeat?"

Once a cycle is started, the wash/rinse temperatures can't be changed.
Nor the soil level, spin speed, etc.

"How about a CLEAR button if you can't be clever enough to let me
change the rinse temperature ANY TIME PRIOR TO THE RINSE CYCLE?
Oh!  The POWER button acts as a clear button!  Great!  I should
shut my TV off each time I want to change channels..."

Can't have a hot rinse.  And, rinse temperature can not exceed
wash temperature.  Can't open the door except when *it* decides
you should.

Etc.

>> For the past several projects, I've pursued a different approach:  try to
>> let the user do what he wants and *infer* what he *intends*.  I.e., encode
>> *minimal* prerequisites that allow the application to guide the user along.
>> E.g., let earlier actions refine the constraints on later ones...
>
> The above link also has a paper comparing static typing vs. dynamic
> typing for programming languages. The latter might correspond to
> your *infer* case.  It seems that users do better with static typing.

*If* you can address all of the user's needs, great!  But, when you
can't, then you leave him/her trying to figure out how to do something
that they *should* be able to do.

E.g., turn off the cold water supply to force a "Hot wash/Warm rinse" to
be "Hot/Hot"...  Or, spin the (mechanical) dial around to "Rinse"
skipping over the wash portion of the cycle...  Or, open the lid to pull
out a few items *before* the spin cycle... or...

Note, none of the things that the washer is "doing for me" are really
making my laundry experience any more pleasant or quicker.  So anything
it is doing poorly or NOT allowing me to do is just making that experience
*worse*!

I don't mean to single out washer/dryers.  As Clifford said, damn
near every THING that interacts with people has some questionable
concept of what that relationship should be -- The Accountant
Mentality ("just do it THIS way...")

The gas pump at our local Costco failed to read the mag stripe on
my credit card the other day.  Message appears saying "try again"
(or thereabouts).  Put credit card in, again.   Ah!  No, it
wants me to restart the entire transaction!  Beginning with my
*membership* card (it produces the same "try again" message
if your membership card isn't read correctly.

Gee, a fully graphic COLOR display and you couldn't spare a couple
of extra characters??  "Please start over"  (acknowledging that
there *may* be some merit in NOT leaving the transaction "pending")

Tim Wescott wrote:
> On Tue, 02 Dec 2014 16:31:52 +0100, Oliver Betz wrote:
>
>> Hi All,
>>
>> of course, the subject is just a rant to make you read and comment this.
>>
>> Did developers two decades ago think better before they started coding?
>>
>> In the early days of embedded computing, most embedded developers could
>> use a TTY interface at best and instrumented the code with some print
>> statements if something went wrong.
>>
>> A build and test cycle took several minutes because erasing and
>> programming EPROMs took so long.
>>
>> ICEs were extremly expensive and didn't even provide the capabilities of
>> modern tools.
>>
>> Today, you can get some kind of "background debug interface" nearly for
>> free, and build and upload new code in seconds.
>>
>> On the ESE Kongress in Sindelfingen, Jack Ganssle lamented today in his
>> keynote about developers spending 50% of their time on debugging.
>>
>> Could it be that today's sophisticated tools lead to more "try and
>> error", less thinking before doing?
>
> Are you thumping your cane on the floor as you complain about kids these
> days, and how the world is degenerating into crap because of them?
>
> I think if you look, you'll probably find similar complaints in the Bible,
> or perhaps written in hieroglyphics on stelae in Egypt someplace.
>
> Times change.  The details of the screwups change.  The nature of the
> thinking leading to the screwups doesn't change, nor does the basic
> solutions.
>
> On a related note, I've been taking more and more to test driven
> development over the last decade, because it seems to help my development
> a lot.  In the last two years I've gotten much more strict about doing
> everything I possibly can under TDD, even if I have to add hardware
> abstraction layers to do it.
>
> My code has gotten better as a consequence.  Not because so much more of
> my code is -- perforce -- unit tested, but because the level of detail of
> testing that TDD calls upon you to do forces you to think about what
> you're doing in much greater detail, and to verify that your head is
> screwed on straight as you did the thinking.
>


The Big Thing is keeping a comprehensive set of test vectors. Putting
thought into how to apply test vectors to an embedded device is time 
well spent.

Most stuff has an Ethernet NIC these days; even if the PHY is a depop
on the production version, being able to use Ethernet is a really big 
game changer.

If you don't have a NIC, you'll probably have a serial port, and
RasPi class computers will act as the "Ethernet port".

-- 
Les Cargill

On 12/2/2014 10:31 AM, Oliver Betz wrote:
> Hi All,
>
> of course, the subject is just a rant to make you read and comment
> this.

:P


> Did developers two decades ago think better before they started
> coding?
>
> In the early days of embedded computing, most embedded developers
> could use a TTY interface at best and instrumented the code with some
> print statements if something went wrong.

What do you mean "early days"?  That still works for me.


> A build and test cycle took several minutes because erasing and
> programming EPROMs took so long.

Lol, now you *are* dating yourself.


> ICEs were extremly expensive and didn't even provide the capabilities
> of modern tools.
>
> Today, you can get some kind of "background debug interface" nearly
> for free, and build and upload new code in seconds.
>
> On the ESE Kongress in Sindelfingen, Jack Ganssle lamented today in
> his keynote about developers spending 50% of their time on debugging.
>
> Could it be that today's sophisticated tools lead to more "try and
> error", less thinking before doing?

That's what I do, but I "try" in simulators rather than on the hardware. 
  Simulators have much more powerful debugging features than most 
debuggers, at least the ones I use.

-- 

Rick

On Tue, 02 Dec 2014 17:17:36 -0700, Don Y <this@is.not.me.com> wrote:

>On 12/2/2014 4:26 PM, glen herrmannsfeldt wrote:
>> Don Y <this@is.not.me.com> wrote:
>>
>> (snip)
>>
>>> Most embedded devices (until recently with the abundance of RELATIVELY
>>> inexpensive graphical displays) have tightly constrained hardware.  And,
>>> a design mentality ("from above") that discourages adding any recurring
>>> costs that don't have direct ($$) benefits.
>>
>>> E.g., our washer/dryer still relies on 7 segment displays -- and a few
>>> "indicators".  As a result, you get silly "messages" like "nF", "dO",
>>> etc. instead of something more informative and HELPFUL like "No Fill.
>>> Are you sure the water valves have been opened?"
>>
>>> This is *so* 1970's....
>>
>> and designers of appliances should test actual users to see how
>> they respond?
>
>YES!  We would smuggle a prototype game out to an arcade and
>discretely sit back and watch how players (using THEIR REAL money)
>reacted to it.  Is it too difficult?  Too easy?  How quickly do
>they pick up the proper strategies to win?  How easily are they
>distracted?  What "wows" them?  etc.
>
>> I was just noting in another newsgroup about a CSE seminar:
>>
>> https://www.cs.washington.edu/events/colloquia/details?id=2594
>>
>> "The Programming Language Wars" on how little testing is done to
>> see how users use programming language features.
>>
>> One test he did was to compare an existing language, using actual
>> people to do the test, with a similar language using random ASCII
>> characters in place of keywords.   See:
>>
>> http://dl.acm.org/authorize?6968137
>>
>> (It should work, even without an ACM subscription.)
>>
>> If that doesn't work, or you want to see other papers:
>>
>> http://web.cs.unlv.edu/stefika/Papers.php
>
>Thanks, I'll have a look!
>
>If you don't understand your users, you don't understand the *problem*.
>So, why are you trying to solve "it" *instead* of understanding it?
>Or, are you hoping your users' complaints will help you understand it??
>
><frown>
>
>>> C'mon... how many millions of these things (different models, etc.) are
>>> they selling WORLDWIDE?  Yet, couldn't afford even a set of 10 segment
>>> displays?  Or, just *two* "digits"-worth?
>>
>>> Or, indicators for each of these conditions?
>>
>> Well, I might think that when no water comes out people figure to
>> check the valves, but you never know.


Even that can be tricky these days.  My dad and his wife had their
washer replaced a few years ago, and they ended up with the
"anti-flood" hoses (I don't think those are a good idea, and neither
apparently do most washing machine manufacturers, but a lot of them
get installed).

If you've never encountered one, these have a built in safety valve
that detects a sudden pressure drop and closes.  The idea is that if
the hose bursts or becomes disconnected at the washing machine end,
it'll shut off to prevent a flood.  At least in theory a potentially
useful innovation, but I've never seen that particular problem.

Anyway, one thing that you need to be very careful of on these is that
when you're turning on the valve, you have to turn it on slowly, or
the sudden pressure change will trigger the safety valve.  You can
even cause the problem if you shut of the whole house system, and
don't reopen the main valve with the taps in the utility basin open.
And there's (of course) no indication that the safety valve has
triggered.  Resetting the value is easy, although totally unintuitive
if you don't know the secret (you have to unscrew the hose connection
at the plumbing end to drop the pressure on that side of the valve, at
which point in releases).

So someone managed to trigger the safety valve, and the washer just
sat there blinking an obscure two character code.  And my dad (who's
far from mechanically inept), was ready to call a plumber or service
for the washer or...

Fortunately he called me first.


>If you sit there and *watch*/wait, you can figure this out.
>But, walking up to it after it has started beeping at you means
>you have to effectively unload it to see if anything is damp.
>
>Why put a fuel gauge in a car?  When you're out of fuel, you'll
>(eventually) figure it out!  :>
>
>Door Open?
>
>Imbalance?
>
>"system error"?
>
>Why display "dO" or "nF" at all?  Just put a big red light that
>says "user screwed up"!


Yeah, just a few more LEDs would allow a scrolling error message.  Or
heck, print the damn error codes someplace - underside of the lid,
perhaps.


>> But for cost-sensitive items, every cent counts.
>
>Yup.  If the alternative is to replace existing product, then
>its awful easy to rationalize a "kludge" approach:
>
>"We'll let the user enter a *time* (of day) of 99:99:99 to access this
>special feature..."
>
>We had a $2K product many years ago and someone ventured the idea of
>adding a "button to do...".  The laughter was intense:  "Good luck
>with THAT!  What's it gonna cost... 25c??"


There are pressures on the manufacturer that are different from the
consumer.  My washer has a whole modem (OK, half a modem), so that it
can send diagnostic data to the service center (you hit a magic
sequence of buttons when the tech tells you to, then hold your phone
over the indicated spot, and you listen to modem noises for 10-20
seconds).  Obviously they felt that was a worthwhile feature to
install.


>There is no way to "soak" in our current washing machine.  Salesman
>argues that "soak" doesn't make sense for a front-loader.  I counter,
>"So, you're letting the technology determine what features the user
>requires?  Why can't 'soak' simply be:  fill, agitate, pause, repeat?"


Perhaps it's only with front loaders.  Many HE top loaders do have a
soak cycle.


>Once a cycle is started, the wash/rinse temperatures can't be changed.
>Nor the soil level, spin speed, etc.
>
>"How about a CLEAR button if you can't be clever enough to let me
>change the rinse temperature ANY TIME PRIOR TO THE RINSE CYCLE?
>Oh!  The POWER button acts as a clear button!  Great!  I should
>shut my TV off each time I want to change channels..."
>
>Can't have a hot rinse.  And, rinse temperature can not exceed
>wash temperature.  Can't open the door except when *it* decides
>you should.


I haven't seen a hot rinse cycle on a washer in decades.  Not even
warm. This may be an energy conservation thing.

As to the doors, that's tougher.  Certainly HE washers (both front and
top loaders) have dangerously fast spin cycles, I can certainly see
not wanting to allow access while that's going on.  Front loaders have
the additional problem of needing to be drained in many cases before
opening the door.  The top-loading HEs seem to be a lot less picky
about that.  I know mine will unlock in a few seconds (~15 if it's in
the middle of a spin, considerably less at other times) after hitting
"pause".


>Etc.
>
>>> For the past several projects, I've pursued a different approach:  try to
>>> let the user do what he wants and *infer* what he *intends*.  I.e., encode
>>> *minimal* prerequisites that allow the application to guide the user along.
>>> E.g., let earlier actions refine the constraints on later ones...
>>
>> The above link also has a paper comparing static typing vs. dynamic
>> typing for programming languages. The latter might correspond to
>> your *infer* case.  It seems that users do better with static typing.
>
>*If* you can address all of the user's needs, great!  But, when you
>can't, then you leave him/her trying to figure out how to do something
>that they *should* be able to do.
>
>E.g., turn off the cold water supply to force a "Hot wash/Warm rinse" to
>be "Hot/Hot"...  Or, spin the (mechanical) dial around to "Rinse"
>skipping over the wash portion of the cycle...  Or, open the lid to pull
>out a few items *before* the spin cycle... or...
>
>Note, none of the things that the washer is "doing for me" are really
>making my laundry experience any more pleasant or quicker.  So anything
>it is doing poorly or NOT allowing me to do is just making that experience
>*worse*!
>
>I don't mean to single out washer/dryers.  As Clifford said, damn
>near every THING that interacts with people has some questionable
>concept of what that relationship should be -- The Accountant
>Mentality ("just do it THIS way...")


And yet you then run the risk of a seriously complicating the user
interface.  As you mentioned, tons of products get returned because
they're too hard to use.  Even ones that really aren't.  It's little
wonder the manufacturers *don't* want to give you extra flexibility.

And some of these things have safety implications (the door lock, for
example).  The manufacturers are going to be loathe to give you any
way of fiddling with that.  On the flip side some of these problems
are because of the required (safety, or otherwise) features.

OTOH, if you now add an Internet interface to your washer, you could
provide a way to program your custom cycle.  And then the next stuxnet
virus will come along and destroy your washer (just after separating
the isotopes in your clothes).  I'm pretty sure we can't win here.

Robert Wessel <robertwessel2@yahoo.com> writes:
> the hose bursts or becomes disconnected at the washing machine end,
> it'll shut off to prevent a flood.  At least in theory a potentially
> useful innovation, but I've never seen that particular problem.

I've seen that happen, causing a fair amount of water damage in an
apartment.  The safety valve sounds like a good idea and I doubt they'd
have accepted the additional cost if flooding wasn't a problem.

On Tue, 02 Dec 2014 18:53:18 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>> the hose bursts or becomes disconnected at the washing machine end,
>> it'll shut off to prevent a flood.  At least in theory a potentially
>> useful innovation, but I've never seen that particular problem.
>
>I've seen that happen, causing a fair amount of water damage in an
>apartment.  The safety valve sounds like a good idea and I doubt they'd
>have accepted the additional cost if flooding wasn't a problem.


Still, building it into the hose seems like a mistake.  And having no
indication that it's tripped *and* having it be easy to trip by
accident, is just a recipe for confusion.

On 12/2/2014 7:45 PM, Robert Wessel wrote:

["safety hoses"]

The smarter way of doing this is to put (electrically operated) valves
*at* the supply and remove the pressure from the flexible hoses when
not needed.  E.g., even if open-loop based on *time*.

How many folks forget to turn the valves off after each use?  How
*inconvenient* is that (i.e., why not *fix* it?!)

We had a fill line rupture to one of the toilets one evening.
Thankfully, the sound of rushing water was enough to wake me and
I was able to catch it before the bathroom floor was even
"completely wet" -- let alone FLOODED!

The armored hoses for the washer failed within the first day of
use.  How much of this was due to crappy quality vs. the "too
high" municipal water pressure (that this event led me to
discover)...

>> Door Open?
>>
>> Imbalance?
>>
>> "system error"?
>>
>> Why display "dO" or "nF" at all?  Just put a big red light that
>> says "user screwed up"!
>
> Yeah, just a few more LEDs would allow a scrolling error message.  Or
> heck, print the damn error codes someplace - underside of the lid,
> perhaps.

Exactly.  Not in the *manual* -- which gets FILED AWAY with the warranty
stuff, etc.  (how often do you need to consult a manual to use a washing
machine -- discounting ERROR CODES??).

And, if you're going to print up a cheat sheet, then error *numbers*
are probably more intuitive than crude "7 segment LETTERS"

(e.g., why "dO" and not "do"?)

They've got icons for "door locked", "add clothes", wash, rinse,
spin, finish, childproof, etc.

One of the best advances in photocopiers was the use of graphic
icons to indicate *where* the jam/problem was detected.  Instead
of a code that says "fuser", etc. (how many John Doe's know what
a fuser is, where it's located, etc.)?

>>> But for cost-sensitive items, every cent counts.
>>
>> Yup.  If the alternative is to replace existing product, then
>> its awful easy to rationalize a "kludge" approach:
>>
>> "We'll let the user enter a *time* (of day) of 99:99:99 to access this
>> special feature..."
>>
>> We had a $2K product many years ago and someone ventured the idea of
>> adding a "button to do...".  The laughter was intense:  "Good luck
>> with THAT!  What's it gonna cost... 25c??"
>
> There are pressures on the manufacturer that are different from the
> consumer.

Exactly -- but if the user experience suffers, then it eventually
comes back as a cost to the manufacturer.

E.g., the door latch in the washer broke after ~18 months (light use...
just two of us, here).  Flimsy piece of snap-together plastic that
gets beaten on (even by the gentlest of users!) by this hefty door
slapping into it.

Service call was comp'ed (out of warranty).  How much "extra plastic"
could they have put into EVERY door latch for the price of the
comp'd service calls nationwide?  Worse, yet... what of the cost in
lost sales as folks see this as a sign of poor quality and opt to
replace with something from another manufacturer??

> My washer has a whole modem (OK, half a modem), so that it
> can send diagnostic data to the service center (you hit a magic
> sequence of buttons when the tech tells you to, then hold your phone
> over the indicated spot, and you listen to modem noises for 10-20
> seconds).  Obviously they felt that was a worthwhile feature to
> install.

Ours has a diagnostic mode that you can invoke and view results
on the front panel.  Most are meaningless to Joe Average User
(issues relating to the VFD drive, calibration values for water
level sense, etc.).  Undoubtedly intended for a technician
(you can also coax the machine through it's cycle in an accelerated
fashion by driving it with the front panel buttons).

It *was* helpful in being able to cite the exact number of wash
cycles the machine had undergone prior to the door failure for
my complaint letter!  :>

>> There is no way to "soak" in our current washing machine.  Salesman
>> argues that "soak" doesn't make sense for a front-loader.  I counter,
>> "So, you're letting the technology determine what features the user
>> requires?  Why can't 'soak' simply be:  fill, agitate, pause, repeat?"
>
> Perhaps it's only with front loaders.  Many HE top loaders do have a
> soak cycle.

Front vs. top shouldn't alter what a user may need to do with
regard to laundry!  :>  Granted, you can't "fill a tub" with water
and let clothes just *sit* there when you have a front loader.
But, you can probably achieve something comparable with the
fill/agitate/pause/repeat algorithm I cited above.  Just do it for
longer than you would for a regular wash cycle.

And, since the machine knows the current orientation of the drum,
it can strive to keep "flipping" the contents to ensure they all
are uniformly exposed to the water at the bottom!

>> Can't have a hot rinse.  And, rinse temperature can not exceed
>> wash temperature.  Can't open the door except when *it* decides
>> you should.
>
> I haven't seen a hot rinse cycle on a washer in decades.  Not even
> warm. This may be an energy conservation thing.

You can't even *trick* it into giving you a hot rinse (by turning
off the cold water).  It complains (with the same "nF" error that
it would have given you *initially* had you failed to turn on the
HOT water supply (because it now wants COLD -- to make WARM -- and
can't get it!)

If you don't hear it's little bleet, it will gladly let your wash sit
there, mid-cycle, because it hasn't got what it thinks it *needs*
(and, why didn't it test this BEFORE it started the wash cycle so
it could tell you when it KNEW you were present?)

> As to the doors, that's tougher.  Certainly HE washers (both front and
> top loaders) have dangerously fast spin cycles, I can certainly see
> not wanting to allow access while that's going on.

Old top loaders had similar problems.  They addressed them with clutches
and brakes -- open lid and tub (fully loaded) would stop spinning almost
before you could get it fully raised!

> Front loaders have
> the additional problem of needing to be drained in many cases before
> opening the door.  The top-loading HEs seem to be a lot less picky
> about that.  I know mine will unlock in a few seconds (~15 if it's in
> the middle of a spin, considerably less at other times) after hitting
> "pause".

I can't recall ever seeing the water level "on" the window.  (the drum
isn't perfectly horizontal but, rather, slopes downward towards the back)
I.e., as long as any clothes that happened to have climbed up the
sides (while in motion) have had a chance to settle back down, I can't see
any water getting out.

OTOH, cleaning the *filter* located *at* floor level ALWAYS results in
water on the floor -- even if you slide a plate or cookie sheet
under the washer, first!

>>>> For the past several projects, I've pursued a different approach:  try to
>>>> let the user do what he wants and *infer* what he *intends*.  I.e., encode
>>>> *minimal* prerequisites that allow the application to guide the user along.
>>>> E.g., let earlier actions refine the constraints on later ones...
>>>
>>> The above link also has a paper comparing static typing vs. dynamic
>>> typing for programming languages. The latter might correspond to
>>> your *infer* case.  It seems that users do better with static typing.
>>
>> *If* you can address all of the user's needs, great!  But, when you
>> can't, then you leave him/her trying to figure out how to do something
>> that they *should* be able to do.
>>
>> E.g., turn off the cold water supply to force a "Hot wash/Warm rinse" to
>> be "Hot/Hot"...  Or, spin the (mechanical) dial around to "Rinse"
>> skipping over the wash portion of the cycle...  Or, open the lid to pull
>> out a few items *before* the spin cycle... or...
>>
>> Note, none of the things that the washer is "doing for me" are really
>> making my laundry experience any more pleasant or quicker.  So anything
>> it is doing poorly or NOT allowing me to do is just making that experience
>> *worse*!
>>
>> I don't mean to single out washer/dryers.  As Clifford said, damn
>> near every THING that interacts with people has some questionable
>> concept of what that relationship should be -- The Accountant
>> Mentality ("just do it THIS way...")
>
> And yet you then run the risk of a seriously complicating the user
> interface.  As you mentioned, tons of products get returned because
> they're too hard to use.  Even ones that really aren't.  It's little
> wonder the manufacturers *don't* want to give you extra flexibility.
>
> And some of these things have safety implications (the door lock, for
> example).  The manufacturers are going to be loathe to give you any
> way of fiddling with that.  On the flip side some of these problems
> are because of the required (safety, or otherwise) features.

Give me the same interface that was common previously.  A *dial*
to select cycles AND *where* to begin *in* the cycle!  So, if
I want to skip directly to the rinse portion of the gentle cycle,
I *can*.  I don't need to read a manual if the controls all
look REALLY SIMILAR to what manufacturers have been cranking out
for decades!

[This is the "big knob" vs. "keypad" argument on microwave ovens.]

Instead, they've all got a big knob that's little more than a
12-way selector switch to pick *a* cycle -- and *it* decides what
to do from there.  I guess they figured the OLD knob was way too
complicated to use and wanted to make things easier on us all!  :>

> OTOH, if you now add an Internet interface to your washer, you could
> provide a way to program your custom cycle.  And then the next stuxnet
> virus will come along and destroy your washer (just after separating
> the isotopes in your clothes).  I'm pretty sure we can't win here.

I don't think you have to "expose" automation in order to benefit from
it.  Eventually, I plan on cannabilizing the washer *and* dryer and
moving the control algorithm "outside the box".  I can't see any other
way of getting information *out* of the appliance.  And, no way am
I capable of producing that mechanism in "quantity one" for anything
approaching what I can buy it!  :>

On 12/2/2014 2:49 PM, tim..... wrote:

>> In the early days of embedded computing, most embedded developers
>> could use a TTY interface at best and instrumented the code with some
>> print statements if something went wrong.
>>
>> A build and test cycle took several minutes because erasing and
>> programming EPROMs took so long.
>
> OMG what did you work on
>
> back in 87, which is not even the early days of embedded, a build cycle could
> take hours

And your "TTY" was actually a pin -- "somewhere" -- that you *hoped*
you (and only you!) could tickle and monitor on a 'scope (hence:
"scope loops"):

     "Yay!  It blipped!  I know my code has executed up to THIS line!"

Hi Paul,

On 12/2/2014 4:56 PM, Paul E Bennett wrote:
> Oliver Betz wrote:

> Like Jack, some of us have learnt the right way to approach any project and
> do, indeed, do a lot of up-front thinking. It is a trait I have tried to
> instil in all the apprentices and graduate student intake at the companies I
> have been involved in over the years.

Note that this is contrary to the current "iterative" approaches.

> Noting that Don budgets 40% of his time to up-front specification resolution
> and project approach planning, I consider this to be on the light side. My
> own figure is closer to 60% of the total project time is getting the spec
> right (including testing and debugging the spec). During this period the
> spec can change quite dramatically as problems are highlighted, identifying
> requirements that could lead to potentially unsafe operations (I am after
> all in the High Integrity Systems market).

 From your comments, below, you appear to include some amount of "research"
in your up-front costs.  I won't start on a spec/design until I already
know what the technology will be, etc.

E.g., I've got roughed out, working prototypes of my gesture recognizer,
speech synthesizers, distributed time infrastructure, network speakers,
etc.  Yet, haven't begun many of their formal specifications.

"Make one to throw away"  Learn from it.  Then, use that knowledge to
come up with the "right" specification and design.

E.g., I can't formalize the timing infrastructure because there are no
real "existing" standards and metrics that I can simply adopt.  How
do I specify how well the DPLL's will perform -- in absolute and
relative terms?  How do I specify how quickly a given client will
nominate a new master clock -- and then come into synchronization
with it?  How do I specify the criteria by which a swarm of clients
decide to mark a chosen master as "malfunctioning"?

I can tell you how *my* implementation behaves.  But, deciding that
*it* is the Gold Standard would be presumptuous.  OTOH, if there are no
other documented implementations to contrast with, then...?

> The benefit of all this up-front work is that the design task becomes much
> more straight forward and I can then produce decent certifiable electronics
> hardware and software.

Exactly.  How can you write code (design hardware) if you don't know what
the code is SUPPOSED to do?  (you're, perhaps, hoping to figure that out as
you write the PRODUCTION CODE??  :> )  How can you challenge the design
(i.e., create a test suite) if you don't know the extent of the "legal limits"
of your challenge?   ("Ah-ha!  When I poured fuming nitric acid on the
device, the output was NOT correct!!")

> Within the resolution of the requirements
> specification I will have invested in some significant portion of "play-
> time". This "play-time" is the exploration of small aspects of the
> requirements with the aim of improving the requirements specification. Any
> prototype code or design produced at this stage is milked for information
> only for the purpose of requirement specification improvement. It is then
> scrapped.

In my case, this all happens before I start on the formal spec/design.

I simply can't estimate things with which I've no prior experience
(and, the things that I've already *done* are nowhere near as interesting
as things I've never *tried*!).

So, either *I* invest in the research (for my own curiosity or in the
hope of folding those costs into a subsequent contract) *or* you (client)
pay me to do that research (T&M) knowing that you can back out if it
looks like its getting too expensive.

Or, find someone who claims to already "have all the answers" (and deal
with the estimate *he* gives you -- but certainly don't expect ME to
use his numbers in MY estimate!  :> )

> Of the remaining 40% of the project time-table, we test as we build as much
> as is practicable. The tests specifications will have come out of 60% block
> and satisfying those tests completely means your design is fulfilling the
> specifications. In this latter period we might see a few (usually minor)
> gotcha's but then, no development process will be absolutely perfect.

With a spec "up front", someone else can start work on test scaffolding
and building test cases.  In doing so, they can also uncover issues that
you may not have considered.

[When a client tells me they "don't care" about a behavior in a particular
set of circumstances, I remind them that I am free to let the device catch fire
and BURN if those circumstances exist... especially if that will save me
effort!  :>  Folks tend to re-evaluate their opinions about those circumstances
when faced with such obvious alternatives!]

> Errors that creep into projects are quite language and technology agnostic.
> 44% of the projects errors will be inserted within the specification stage
> (See "Out of Control by the UK Health and Safety Executive). This is why it
> makes sense to remove those errors before you start the design effort.

This actually isn't *hard* to do.  But, takes a different mindset.  You
have to continually ask:  "What am I ASSUMING, here?  Is that a valid
assumption?  What could *invalidate* that??"

["Can't Happen" *does*!]

> Of course, in order to remain in control of the project effort and ensure
> that the team are moving to the same overall plan, you need to have a
> decently robust Development Process in place. CMMI level 3 is the bare
> minimum your process should support. Higher, though is better. Correct by
> Construction is the best (and is improvement beyond CMMI level 5).

Time for cookies.  35 dozens tonight if I plan to stay on schedule!  :-/

On Tue, 02 Dec 2014 19:40:05 -0600, Les Cargill wrote:

> Tim Wescott wrote:
>> On Tue, 02 Dec 2014 16:31:52 +0100, Oliver Betz wrote:
>>
>>> Hi All,
>>>
>>> of course, the subject is just a rant to make you read and comment
>>> this.
>>>
>>> Did developers two decades ago think better before they started
>>> coding?
>>>
>>> In the early days of embedded computing, most embedded developers
>>> could use a TTY interface at best and instrumented the code with some
>>> print statements if something went wrong.
>>>
>>> A build and test cycle took several minutes because erasing and
>>> programming EPROMs took so long.
>>>
>>> ICEs were extremly expensive and didn't even provide the capabilities
>>> of modern tools.
>>>
>>> Today, you can get some kind of "background debug interface" nearly
>>> for free, and build and upload new code in seconds.
>>>
>>> On the ESE Kongress in Sindelfingen, Jack Ganssle lamented today in
>>> his keynote about developers spending 50% of their time on debugging.
>>>
>>> Could it be that today's sophisticated tools lead to more "try and
>>> error", less thinking before doing?
>>
>> Are you thumping your cane on the floor as you complain about kids
>> these days, and how the world is degenerating into crap because of
>> them?
>>
>> I think if you look, you'll probably find similar complaints in the
>> Bible,
>> or perhaps written in hieroglyphics on stelae in Egypt someplace.
>>
>> Times change.  The details of the screwups change.  The nature of the
>> thinking leading to the screwups doesn't change, nor does the basic
>> solutions.
>>
>> On a related note, I've been taking more and more to test driven
>> development over the last decade, because it seems to help my
>> development a lot.  In the last two years I've gotten much more strict
>> about doing everything I possibly can under TDD, even if I have to add
>> hardware abstraction layers to do it.
>>
>> My code has gotten better as a consequence.  Not because so much more
>> of my code is -- perforce -- unit tested, but because the level of
>> detail of testing that TDD calls upon you to do forces you to think
>> about what you're doing in much greater detail, and to verify that your
>> head is screwed on straight as you did the thinking.
>>
>>
> 
> The Big Thing is keeping a comprehensive set of test vectors. Putting
> thought into how to apply test vectors to an embedded device is time
> well spent.
> 
> Most stuff has an Ethernet NIC these days; even if the PHY is a depop on
> the production version, being able to use Ethernet is a really big game
> changer.
> 
> If you don't have a NIC, you'll probably have a serial port, and RasPi
> class computers will act as the "Ethernet port".

Maybe most stuff you work on.  The board in front of me right now is about 
1.25 square inches.  It has two chips, a transistor, a diode, a button, 
and some discretes.  Rev 2 will have vastly enhanced I/O -- it'll have an 
LED.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com