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)
(and I wrote)
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.
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.
Yes, again analog is easier. I can turn the switch and change the incoming water temperature while it fills.
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)
Yes, but sometimes too many choices also makes it hard. Harder for people to understand and remember how to use them.
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.
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.
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?
I haven't seen them either, and I suppose I could even be fooled by one.
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.
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".
Alternatively, "programmers aren't actual people"! :>
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)
Ha! Interesting! OTOH, I wouldn't want an infinitely variable speed on a *mixer*, either!
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!
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!
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..."
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??
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?? Turn the dial to pick one, then play with the other buttons to see what it will *let* you change! :-/
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! :-/
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.
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 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.
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.
Which is why we have the feasibility studies aspect early on.
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.
Wise council.
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.
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).
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.
Well, we all know that the law according to Professor Aloysius Sod Murphy is immutable.
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.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
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.
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.
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!)
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!
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...
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.)
Exactly. When I write code, the assumptions get coded as invariants *in* the code. E.g., instead of:
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.
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"! 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.
*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..."
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! :> )
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
IMO that's no counter-argument. My point is, that a painful test cycle motivates people to think before stupidly trying dozens of changes.
Also to me, "hardware debugging" is one of the most important aspects of a powerful debugger. Not only bad or broken foreign hardware but also own hardware under development. Being able ad-hoc to twiddle with my peripheral or front-end without the need of programming a dedicatred "interface" is priceless.
no, although age helps developing discipline, it's no guarantee, and I think older developers are also affected.
It's tempting to try changes if it is ostensibly quicker. And if you know that a cycle for a new try is painful, you get external motivation (compensation for a lack of intrinsic motivation).
Any good example supporting this?
I agree that TDD promotes thinking on the problem but it's IMO not the key.
I prefer to work on simple systems. My first embedded system was 1986 a 6502 based controller for a weighing machine
formatting link
My build system was an Apple// with a hard disk, object code size likely around 8K. Most time was programming and erasing EPROMs. Printing the source code took rathern long, though.
so you use the same ASSERT for test and production?
IMO your example is not very well chosen.
It /might/ be suitable if the "assumption" results from a calculation you proved (designed) to yield nonzero results previously. But even then I would try to handle a zero result in a less disruptive way if possible.
In production, assertions become no-ops -- they don't have handlers associated with them (because they are NEVER supposed to be violated)
The example was chosen to illustrate something to which most readers could relate -- without knowledge of a particular application. And, to highlight an example where one would TYPICALLY expect to see some explicit code to handle the "zero case" -- code that would effectively be "dead code" (never executed) simply because of the constraints that the invariant clarifies.
The presence of this invariant PROCLAIMS that elapsed_time WILL NOT BE ZERO at this point. The developer can read the preceding code to see why that is the case. Or, look at the contract for the routine in which the code fragment is included. The invariant simply makes the assumptions crystal clear in a way that "commentary" would only obfuscate:
"The elapsed_time parameter can not be zero because this function is only invoked by "update_display_parameters(). The contract for THAT function states that it will only be updated at some finite frequency which ensures that SOME time will have elapsed between invocations. As a result, *this* function inherits that constraint."
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.