Modern debuggers cause bad code quality

Don Y <this@is.not.me.com> wrote:

(snip, I wrote)

>> 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.
 
(snip, I also wrote)
>> http://dl.acm.org/authorize?6968137

(snip)

> 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??

In the CS case, it might be that the theorists expect that theory
is good enough to solve the problem.  No need to test on actual people.
 

(snip, someone wrote)
>>> "Power Level, 9; Time, 1 0 0; START"

(and I wrote)
>> 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!"

With the microwave, I can watch what is cooking and adjust the knob
accordingly.  I think with the digital ones you can press POWER and
a number while cooking, but it isn't quite as easy as a knob.

It is suppose to be that when blenders first came out, different
companies were making ones with more and more speeds (buttons),
and finally someone came out with one with a continuous knob.

The knob (infinite speed) didn't sell at all. People wanted the
six or eight buttons. 

> 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?"

The (non digital) washer we have has a delicate mode that runs the
agitator a few seconds every 30 seconds. For front loaders, you
could do something like that, so that everything had a chance 
to soak.

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

Yes, again analog is easier. I can turn the switch and change
the incoming water temperature while it fills.

> "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.

As I understand it, cold rinse does as well as warm, but many
still allow warm rinse.  But even my non-digital model doesn't
allow for hot rinse, and not for warm rinse with cold wash.

(snip, I wrote)

>> 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.

Yes, but sometimes too many choices also makes it hard. 
Harder for people to understand and remember how to use them.
 
> 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...

My washer won't spin with the lid open, but will fill and agitate.
Many won't do anything with the lid open, though.  I can open the
lid, and it will stop before draining.
 
> 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")

-- glen

Robert Wessel <robertwessel2@yahoo.com> wrote:
 
(snip)

> 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).

As I understand it, leaking hoses are a big problem.  The usual
ones are designed to last 5 years, and should be replaced.
The ones I have are about 15 years old, though I plan to replace
them soon. 
 
> 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.

I haven't either, but it doesn't take many to add up. Especially
if you are away.  How many people turn off the valves when they
go on vacation? 
 
> 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.

I haven't seen them either, and I suppose I could even be
fooled by one.

-- glen

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.

Oh, yes, much worse than in the basement of a house, near a drain.

I know someone in a condominium who is supposed to replace the 
water heater when the warranty is out.  (Which is usually based
on the lifetime of the anode that keeps it from corroding through.)

If it leaks, it can easily cause a lot of damage to other units,
and insurance might not cover it.

I believe that the stainless steel mesh covered hoses are supposed
to last, as the rubber doesn't have to support the pressure alone.

-- glen

On 12/3/2014 12:20 AM, glen herrmannsfeldt wrote:
> Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>> 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).
>
> As I understand it, leaking hoses are a big problem.  The usual
> ones are designed to last 5 years, and should be replaced.
> The ones I have are about 15 years old, though I plan to replace
> them soon.
>
>> 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.
>
> I haven't either, but it doesn't take many to add up. Especially
> if you are away.  How many people turn off the valves when they
> go on vacation?

Huh?  We turn off the valves after EACH wash!  A common type of shutoff
consists of a single lever that operates BOTh hot and cold water supply
valves.  So, you can just "throw a lever" and turn off the hot *and* cold
water supplies with that ONE lever.  As such, it's only forgetfulness that
keeps you from doing this all the time!

Even individual valves are typically located in such a way that you
can easily turn off both at the end of your "laundry chores".

On 12/3/2014 12:11 AM, glen herrmannsfeldt wrote:
> Don Y <this@is.not.me.com> wrote:
>
>> 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??
>
> In the CS case, it might be that the theorists expect that theory
> is good enough to solve the problem.  No need to test on actual people.

Alternatively, "programmers aren't actual people"!  :>

>>>> "Power Level, 9; Time, 1 0 0; START"
>
> (and I wrote)
>>> 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!"
>
> With the microwave, I can watch what is cooking and adjust the knob
> accordingly.  I think with the digital ones you can press POWER and
> a number while cooking, but it isn't quite as easy as a knob.

AFAICT, "all" digital units have very limited capabilities when it
comes to making "midstream corrections".

E.g., I can't adjust the power level once the START button has been
pressed.  I have to *CLEAR* the cycle (which can also be accomplished by
opening the door) and pick a new level.

I can only adjust the time remaining (regardless of the type of "cycle"
that may be in effect -- cook, defrost, etc.) by pressing the "add
30 seconds" button.  This is often a good number -- even if you need
to press it many times!

E.g., there are many things that I might chose to cook for 2:00 and
I find it easier to press this button 4 times than to type TIME 2 0 0
(or, press the "2" button as a "2 minute" shortcut)

> It is suppose to be that when blenders first came out, different
> companies were making ones with more and more speeds (buttons),
> and finally someone came out with one with a continuous knob.
>
> The knob (infinite speed) didn't sell at all. People wanted the
> six or eight buttons.

Ha!  Interesting!  OTOH, I wouldn't want an infinitely variable
speed on a *mixer*, either!

>> 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?"
>
> The (non digital) washer we have has a delicate mode that runs the
> agitator a few seconds every 30 seconds. For front loaders, you
> could do something like that, so that everything had a chance
> to soak.

Exactly.  Our dryer will periodically tumble clothes that are known
to be dry -- but, not yet retrieved -- indefinitely.

Old top loaded tubs you could just STOP the cycle after the tub had
filled and "let things soak".  There is no way to do that with the
current HE front-loaders (AFAICT).  Yet, had someone considered this
as a REQUIREMENT, there are obvious ways to implement it.  And, that
cost a lot less than ADDING a "steam" capability!

>> Once a cycle is started, the wash/rinse temperatures can't be
>> changed.   Nor the soil level, spin speed, etc.
>
> Yes, again analog is easier. I can turn the switch and change
> the incoming water temperature while it fills.

Older machines had two switches:  wash temp, rinse temp.
Picking a wash temp didn't restrict your choice of rinse temp.

If "HOT" wasn't a valid choice for a rinse -- but WARM was -- you
could simply leave the cold water supply turned off and just
wait a bit longer for the ALL HOT water to fill the tub in preparation
for the rinse cycle (obviously HOT+COLD=WARM would have filled it
quicker -- but the water level sensor is the deciding factor, not
*time*!)

Our washer will complain if the cold water isn't on when you select
a warm or cold rinse -- though it will wait until the rinse cycle to
do that complaining!

>> "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.
>
> As I understand it, cold rinse does as well as warm, but many
> still allow warm rinse.  But even my non-digital model doesn't
> allow for hot rinse, and not for warm rinse with cold wash.

Colder rinse is better/required to get the soap out.  But,
*enforcing* that (even if I attempt to work-around that "rule")
is unnecessary.  Why not prevent me from mixing whites and colors??
Or, washing colors in hot water?  etc.

The Accountant Mentality:  "Do it *this* way..."

>>> 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.
>
> Yes, but sometimes too many choices also makes it hard.
> Harder for people to understand and remember how to use them.

Users can always fall back on habits.  They don't *have* to avail
themselves of every capability that you afford them.

Our washer has all sorts of "special" cycles.  Yet, I treat things as
"whites/linens" and "everything else".  Washer still manages to do what
*I* want it to do!  When SWMBO wants to deal with the bedding, then
she opts for *that* specific cycle.  Does she actually *know* what
it does that my scheme for handling "whites" doesn't do??  <shrug>

Machines should always try to anticipate what the user TYPICALLY
wants to do -- but, always defer to the user's specific requests.
E.g., if I want to wash whites with COLD water, I should be allowed
to do so and not forced to accept HOT as the only choice.

I.e., each of the 11 or 12 cycle choices not only comes up with
predefined presets for the various "other settings" (wash/rinse/etc.)
*but* also restricts our choices in each of those!  E.g., "sanitize"
locks the wash temperature at HOT -- but "bedding" will only let me
choose between cold and warm washes, etc.

What are the *rules* for each of these cycle types??  <shrug>  Turn
the dial to pick one, then play with the other buttons to see what it
will *let* you change!  :-/

>> 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...
>
> My washer won't spin with the lid open, but will fill and agitate.
> Many won't do anything with the lid open, though.  I can open the
> lid, and it will stop before draining.

That's how our older washers operated.  Actually, I think it would
stop *after* fill if the lid was up.  Yet, if it had already progressed
into the wash (agitate) cycle, opening the lid wouldn't interrupt that
action.  Spin was always inhibitted/halted regardless.

But, you can understand these from a safety/usability perspective:
spin is dangerous when lid up; wash shouldn't stop just because you
want to throw in another pair of socks, etc.

I'd love to see an explanation of why I SHOULD NOT, EVER, wash bedding
with hot water.  Or, the problems that "sanitize" with anything other
than HOT might cause!  :-/

>> 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*!

Don Y wrote:

> 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.

I still have plenty of iteration, but dealing with some of the projects I am 
involved in, the cost of failure is so huge we iterate through our written 
assumptions and begin constructing tests to see if they are valid in the 
light of the stated goals. Task Analysis, HAZOP, Risk Evaluation, Human 
Factors Evaluation and, if none of that is fully acceptable, re-iterate 
through it all again until we have a workable Requirements Spec that will be 
implementable. With the appropriate expertise around to assist in validating 
the assumptions you have made (and written down) you can eliminate better 
than 90% of the errors in these early stages. The remaining 0% are much 
ahrder work though. In our Requirements Spec resolution phase we are also 
looking at maintenance and de-commissioning procedures as well as normal and 
emergency operational procedures.
 
>> 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.

Absolutely. However, the big budget projects do tend to need this sort of 
approach as the cost for failure are massive in more than money terms.
 
[%X]

>> 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!!")

The specifications from which production design and code will emerge will 
have been reviewed very thoroughly by the time we get to that point. Even 
so, we keep the production designs and code under the same stringent review 
cycle throughout.
 
>> 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.

We have several levels of formal spec. The initial level is more like a 
statement of goals to be achieved. Over the past 12 yars I have worked with 
a number of Physicists. They state what they would like to do, I come up 
with a few ways it can be achieved, they do some (usually quite complex) 
mathematical modelling and select which method works for them. We then 
explore adding more detail and look at the way in which we can make the 
system easy to manage. Sometimes, we get the added detail and realise that 
it is a dead-end approach and then it is back to looking at the other ways. 
So, yes, I do include the "play-time" within the resolution of the formal 
Requirements Specification. I rather liked Wernher Von Braun's quote "Basic 
Research is what I am doing when I don't know what I am doing". It seems to 
sum up such early exploration nicely.

> 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*!).

Which is why we have the feasibility studies aspect early on.
 
> 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.

The last is more like the way I have been able to work on some projects. 
There are still some projects for which I will already know a good way to go 
at the outset because I will have seen a similar problem before.
 
> 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!  :> )

Wise council.
 
>> 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.

I am not saying that emerging issues after the spec is complete are fully 
eradicated, but they are certainly very reduced. By the time e get into real 
design we have organised the system structural framework such that it will 
hold up to dealing with such late issues (usually fairly minor). The Task 
Analysis, HAZOP and Risk Assessment stages do the majority of the (sometimes 
quite wild) "what if" scenario assessments such that we can, by selection, 
eradicate the major gotcha's.
 
> [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!]

The legislation that usually applies to my systems do not allow it to catch 
fire so is never an option to allow it. Which is why the up-front effort 
looks into ways and means of avoiding such (even under fault conditions).
 
>> 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??"

We not only ask "What am I ASSUMING, here?" but we document the assumptions, 
test them thoroughly and even record the reason why it is valid or invalid.
 
> ["Can't Happen" *does*!]

Well, we all know that the law according to Professor Aloysius Sod Murphy is 
immutable.
 
>> 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!  :-/

I am only permitted 5 per day (orders) and drink way more green tea than I 
do coffee. Have to look after your health to keep doing this enjoyable work 
for many more years to come.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Tim Wescott wrote:
> 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.
>

In that case, the thing better be sufficiently constrained to allow
for reasoning about operation at the source code level.

I hope you have some way to at least pull error counters without
stopping the CPU.

-- 
Les Cargill

Hi Paul,

On 12/3/2014 4:24 AM, Paul E Bennett wrote:

>>> 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.
>
> Absolutely. However, the big budget projects do tend to need this sort of
> approach as the cost for failure are massive in more than money terms.

Historically, if this "research" (learning phase) is something that I have
a considerable personal interest in (e.g., can benefit me towards some other
goal I have in mind), I will "eat" the cost -- if the client can afford the
associated calendar time.  I find it far more satisfying and thorough to
learn with a *real* example -- like a genuine project -- and not some
"contrived" example (like a homework assignment, app note, etc.).

If there's no direct benefit to me that I can foresee from the research,
then it's more of a "job" and I expect to be paid for that time.  Client
can always decide to chase down someone who already has that expertise
(*if* he can find same).

If I have no *interest*, then it's "no bid" regardless of the monies
involved.

This *seems* to work good for all involved.  The more interest/ownership
I show for a project, the better the outcome.  So, you really don't
want me doing something I'm not going to enjoy (this probably explains
many of the "quality" problems in the workplace in general).

Of course, always chasing a new applications means the complexity of those
new projects tends to escalate.  After several decades, all the "low hanging
fruit" has been picked clean -- leaving the more substantial projects with
far steeper learning curves.

>>> 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!!")
>
> The specifications from which production design and code will emerge will
> have been reviewed very thoroughly by the time we get to that point. Even
> so, we keep the production designs and code under the same stringent review
> cycle throughout.

By contrast, I think many/most projects have nothing "on paper" and very
little formal investment in *that*!

Having stuff on paper gives all parties something CONCRETE to challenge.
"*Why* don't we have to worry about fuming nitric acid?  What about
aqua regia?"  etc.  You don't, instead, have one person ASSUMING one
set of ideas while another ASSUMES something else.

>> 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*!).
>
> Which is why we have the feasibility studies aspect early on.

Yes.  In my case, it's more of an argument to a prospective client:
"How can you expect estimates of any quality if I have no experience
on which to base them?"

I've seen some impressive "feasability studies" considering the
smallness of the firms involved!  E.g., dropping a megabuck into something
that you never plan on *building* takes a lot of confidence in your overall
business plan (when you're just a $10M company!)

>> 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.
>
> The last is more like the way I have been able to work on some projects.
> There are still some projects for which I will already know a good way to go
> at the outset because I will have seen a similar problem before.

I'm fortunate (now) in that almost everything on which I am working is
"on my own dime".  So, I don't have to worry about someone watching
weekly invoices and keeping a running total of what it's cost so far.
Everyone always EXPECTS things to take less time, and cost less, than
they inevitably do.  And, tend to forget this is how the last project
ALSO played out -- despite how wildly successful *it* turned out to be!

<shrug>

>> 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!  :> )
>
> Wise council.

It always amazed me how clients wouldn't see the folly of this attitude.
"You want *me* to use *his* numbers?  Why don't you sell *your* products
for the prices that your (other) competitors sell theirs??"

Which, of course, is met by a lengthy explanation of why their product
is so much better/different/etc.  But, they never actually seem to
listen to what they are offering as justification.  (sigh)  Perhaps
I am too subtle...

>> [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!]
>
> The legislation that usually applies to my systems do not allow it to catch
> fire so is never an option to allow it. Which is why the up-front effort
> looks into ways and means of avoiding such (even under fault conditions).

Of course!  My comment is intended to make the client realize that he
*does* care -- he just hasn't put the required thought into it!  I could
just as easily have said that the device would "transfer all of his bank
funds to my accounts" in those cases.  Something equally unsatisfying to
him!  (but, worth some extra effort on *my* part  :> )

Either *he* can sort out what he really wants to happen in these circumstances
*or* arrange for them to get resolved "somehow".  "Call me when you have a
complete idea of what you want" or "Pay me to help you figure out what you
want!"  (I'd much rather be *told* than have to chase down all those
little details.)

>>> 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??"
>
> We not only ask "What am I ASSUMING, here?" but we document the assumptions,
> test them thoroughly and even record the reason why it is valid or invalid.

Exactly.  When I write code, the assumptions get coded as invariants *in*
the code.  E.g., instead of:

    if (elapsed_time != 0)
       average_speed = distance_traveled / elapsed_time;
    else
       average_speed = ...

I would write:

    ASSERT(elapsed_time != 0)
    average_speed = distance_traveled / elapsed_time;

to drive home the point that elapsed_time is NOT zero at this point in the
code -- a basic assumption that the code can safely rely upon.

>>> 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!  :-/
>
> I am only permitted 5 per day (orders) and drink way more green tea than I
> do coffee.

A (diabetic) neighbor rations himself *4* of my cookies daily.  I am
amazed that he can discipline himself that well when faced with a
tin of 6 or 8 dozens to start with!  :>  In my case, an even more
"heroic" effort is required:  baking 35 dozen over the course of a
few hours and not "sampling" a few dozen in the process!  :-/
(I actually ate 6 -- not bad considering there were 400+ "temptations"
to choose amongst!)

Biscotti next.  Distressing as they require far more time and work for far
fewer "cookies"!  <frown>  OTOH, I won't have to make more than 6 or 8
dozens of them, total.

No coffee, here.  But, just about 1G of green tea daily.  Much prefer
the black (taste) but the caffeine content was allegedly unhealthy.

I've also learned that some green tea is just as bad!  My BP was
*50* points higher (than it's historical norm) on my last MD visit.
Recognizing that I had just recently switched teas, I discarded the
balance of the (bulk) tea and things were back to normal in a matter
of days.

> Have to look after your health to keep doing this enjoyable work
> for many more years to come.

<shrug>  *Something* is gonna get us -- all!

"I want to die peacefully, in my sleep, like GrandPa.  Not screaming
in terror like the people on the bus he was driving..."

Hi Tim,

On 12/2/2014 10:50 PM, Tim Wescott wrote:
>> 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.

Physical size is not an impediment, nowadays.  I've started fleshing out
a spec for a custom bluetooth earpiece that's probably *half* the size
of the board you've got in front of you (including its power source) yet
still "accessible" remotely (via the BT interface, of course).

But, you have to plan on how you will use those hardware resources
during debugging without conflicting with the operation of the device
itself (e.g., esp before you have the comms stack operational!  :> )

On Wed, 03 Dec 2014 07:46:21 -0600, Les Cargill wrote:

> Tim Wescott wrote:
>> 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.
>>
>>
> In that case, the thing better be sufficiently constrained to allow for
> reasoning about operation at the source code level.
> 
> I hope you have some way to at least pull error counters without
> stopping the CPU.

I happened to have an extreme counter-example sitting in front of me, so I 
used it.

The board's whole purpose in life is to turn a motor on for 30 seconds at 
a button press, then stop.  It can (and a previous revision did) be done 
with a couple of transistors and some discretes.

Rev 2 will allow the user to program the timer interval and save it in 
flash -- which will probably take up the bulk of the code.

-- 

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