Go Down

Topic: Troubleshooting software – lost art ? (Read 2854 times) previous topic - next topic

robtillaart


Have you read "The inmates are running the asylum"?

Yes (too) long ago,  very good book about usability IIRC , well written good examples
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

AWOL

Quote
I am not sure, but one of my firts, if not the very first, post was about " where is debugger"?
I could not believe the answer i got - "you do not need one, it runs in loop" !

It was your third post
You'll notice that the word "loop" doesn't appear at all in the thread.
Why do you make this stuff up?
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

bperrybap

vaclav,
It isn't just troubleshooting s/w that is a lost art, it is the entire concept of being
able to design and plan out a project is starting to become considered as unnecessary.

From what I can tell the  trial and error methdology with no plans is the "Arduino Way"
and is actually encouraged.
Here are some quotes from Massimo Banzi's book "Getting Started with Arduino":

Quote
Classic engineering relies on a strict process for getting from A to B;
the Arduino Way delights in the possibility of getting lost on the way and
finding C instead.


Quote

I've spent a long time looking for an English word that would sum up that
way of working without a specific plan, starting with one idea and ending
up with a completely unexpected result. Finally, "tinkering" came along.


Quote
Tinkering is what happens when you try something you don't quite know
how to do, guided by whim, imagination, and curiosity. When you tinker,
there are no instructions--but there are also no failures, no right or wrong
ways of doing things.


Quote

This is why we developed "opportunistic prototyping": why spend time
and energy building from scratch, a process that requires time and in-
depth technical knowledge, when we can take ready-made devices and
hack them in order to exploit the hard work done by large companies
and good engineers?


The real tradegy in using this type of methodology is that there is so little
understanding behind the "creation" that it impossible to know if it really works
or just happens to appear to be working.
i.e. could it blow up or malfunction at any momment.

--- bill



JimboZA

Well said, bperrybap.

For me personally, I'm loving the Arduino tinkering. Tinkering is exactly the right word, it's a relaxation for me. I'm enjoying being able to say, wth, I'm going to stop here and Google a bit and see where that takes me. Then pop out to my nearby supplier and buy a new chip just for fun.... thats's how I came by a Hall sensor, a digital pot, and and and. And at almost 60 years of age I think it's time I had fun! I have, btw, post-grad in engineering, so I do know just how wrong this is, but it's fun!

But I wouldn't dream of using any of my or anyone else's tinkering in a real-life project. It scares me shitless to read of tinkerers who are hooking Arduinos to their car throttles or house wiring..... Those are recipes for death.
"Could you do the egg bacon spam and sausage without the spam then? "

No PMs for help please.
DO NOT power servos from Arduino 5V: give them their own power and connect the grounds.

robtillaart

(some thoughts came up)

A design should be detailed to the level that someone skilled in the art can interpret the design unambiguously.

for SW a sort function do not need to be specified (in general)
For a drawing of a house it should not be specified how the bricks are laid.....
A pneumatic design assumes the pipes are air tight.
For an electrical schema ....



Tinkering is not good or bad in itself. Problem with tinkering with microproc and electronics is that you must have (build up) basic knowledge how sensors and actuators and processors work internally. The complexilty of most LEGO or MECCANO part is from another order of magnitude than a lets say a DHT temperature sensor. Libraries abstracts those complexities to a simple interface but it cannot hide all of its internals (unwanted side effects).

An example:
The map function maps an input range to an output range. suppose I want to map an analogRead to milliVolt.
typical code
(1) mV = map(analogRead(A0), 0, 1023, 0, 5000);

but the following works too:  (OK, small differences)
(2) mV = map(analogRead(A0), 0, 256, 0, 1250);   // 0 will still be mapped upon 0, 1023 upon 5000;

The side effect shown is that the ranges given in the map interface are not constrained. The mapping extends beyond the given numbers and the internal math goes even beyond the given ranges. (internal overflow e.g. map analogRead(A0) on microVolt 0..5e6).

just some thoughts.
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Vaclav



Have you read "The inmates are running the asylum"?

Yes (too) long ago,  very good book about usability IIRC , well written good examples


Every new owner of Arduino should read this book. Than for entertainment follow up with " Business @ the Speed of Thought"


I just love folk's  saying - any culture or language...
" if  you have no plan you will never know when you are finished". ( probably Chinese?)

I hope this thread keeps going without getting too much personal or get derailed. One of the "regulars"  already tried.
I also hope that some of the "tinkerers" will  visit here.

I have spend few years using a different technology which had a similar "problems" in forums discussions.
However, the vendor's attitude was to support users and to sell  product. Apparently Arduino "management" attitude (is).... you add your own description here......

In my opinion Arduino "management" likes to generate traffic ( "...format you code and I may help you " ) and occasionally lets the "tinkerers" let the smoke out of "ready to run  hardware".

The best one so far - cannot copy and paste into UI dialog. Arduino "management" reply - " can you use CTRL L  /V?"

This tinkerer is spending time making the LCD library to REALY work on 4 bit data bus.

Cheers
Vaclav

AWOL

I've moved this topic to Bar Sport - it seems to have degenerated into a vague rambling rant.

Quote
In my opinion Arduino "management" likes to generate traffic

I'd be surprised if you've ever interacted with any of the Arduino management, so how you formed that opinion is a bit of a puzzle to me.

Quote
"...format you code and I may help you "

This one clearly troubles you - you keep going back to it.
I'll try to explain again, because obviously my earlier attempt failed, but first, I'll have to introduce you to a word - the word is "courtesy".
If someone doesn't post their code in code tags, they run the risk of having their code mangled by the forum software, rendering it illegible and wasting time as people try to pick the meaning from it.
So, because everyone (yes, even me) gives their time for free, wasting time is discourteous.
Not posting code correctly is counter-productive; a problem that is hard to read is less likely to attract replies, so you see, it is in everyone's interest to encourage the use of code tags, so we take every opportunity to remind people.
It's very simple.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

Nick Gammon


However, the vendor's attitude was to support users and to sell  product. Apparently Arduino "management" attitude (is)....


What on earth makes you think the Arduino management are moderators? We are not the management, we are unpaid volunteers, trying to help beginners (and more advanced users) with their projects.

Quote

"...format you code and I may help you "


Yes, well that is because code like:

Code: [Select]
speed_array [i] = foo;
time_array [b] = bar;
myfunction (8);


Comes out like this if you don't:

speed_array = foo;
time_array = bar;
myfunction (8);


Can you see how hard it is to help people if the code is all mangled like that? If not, why not? We've asked you quite a few times to use code tags and you not only don't do it, but you then whine about even being asked.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

SirNickity

It isn't just troubleshooting s/w that is a lost art, it is the entire concept of being
able to design and plan out a project is starting to become considered as unnecessary.

From what I can tell the  trial and error methdology with no plans is the "Arduino Way"
and is actually encouraged.

...

The real tradegy in using this type of methodology is that there is so little
understanding behind the "creation" that it impossible to know if it really works
or just happens to appear to be working.
i.e. could it blow up or malfunction at any momment.


My answer to this is "Perspective".  In other words, so what?  If I take a $2 micro, and connect it to a $0.30 LED without a resistor, and I blow up the LED and the micro's output pin, who cares?  That didn't hurt anyone, and I just learned a valuable lesson.

It's not the traditional sense of engineering -- it's learning by doing, by creation, and getting an immediate fix for your curiosity.  In honesty, I think society should encourage this form of learning more.  This is not to say I don't find academics worthwhile -- I wholeheartedly do.  I spend hours and hours reading PDFs of how to best to minimize (insert counter-productive force here), and read descriptions from designers doing things well beyond my level of understanding until things start making sense.  The practical applications I get as a beginner develop an insatiable curiosity for the "how" and "why" that have no meaning to me on day one.

Fundamental theory without application is dull and hard to integrate into understanding.  Once you see something, and then you are told why that happened, there's an immediate connection there, and instead of being a chore, it leaves me wanting to understand even more.

It's easy to get confused, as someone with more advanced understanding, why these newbies can't be bothered to learn first...  But remember, when you first start out, you have no idea what you don't know -- or what's even possible.  A little time hands on starts developing a road to knowledge that some will take, and others will prefer to remain ignorant.  Not everyone will have the tenacity to become a full engineer.

I agree though, there's a big difference between playing around with blinking LEDs and mini robots and tying into household AC and vehicle control.  The latter usually get stern warnings from regulars about staying out of projects that are far beyond one's level of understanding when safety is a factor.

FWIW, I tend to write code as I go along.  I start with an idea of what I want it to do, and start writing functions that accomplish those tasks.  Along the way, I find where my interfaces don't line up correctly, and then I think about how to solve that in the best way.  I don't really understand how someone can develop an API without building use-cases for it.  I've discovered all kinds of gotchas I never would've thought up in advance.  (E.g., this object won't know about this member variable until X happens, so there needs to be a callback here, or the caller needs to retain an object reference... etc. etc.)  I do end up re-writing code a lot, but is that time I would've saved if I had spent it diagramming instead?  I don't know.  Not always...

Go Up