another bizarre architecture
in [Embedded]
|
From: John Larkin on 7 Feb 2007 11:42 On Mon, 05 Feb 2007 09:45:44 +0100, David Brown <david(a)westcontrol.removethisbit.com> wrote: >John Larkin wrote: >> On Fri, 02 Feb 2007 15:13:53 GMT, Vladimir Vassilevsky >> <antispam_bogus(a)hotmail.com> wrote: >> >>> >>> Jan Panteltje wrote: >>> >>> >>>>> It is better to stay on the earth rather then fall on somebody's head. >>>>> Masking the errors is the worst practice. >>>> >>>> Yes that is true. >>>> But you have to try one day to fly.... Errors will show you where to improve. >>> Deadlines. That's another reason for the software to be the far from >>> perfect. >> >> >> So, you will actually release software that you know is buggy, or that >> you haven't tested, because of some schedule? Please tell me who you >> work for, so I can be sure to never buy their stuff. >> > >John, this is comp.arch.embedded - the answer is *always* "it depends". > For some products, it is vital to hit the schedule - even if there are >known bugs or problems. Perhaps you ship the hardware now, and upgrade >the software later - perhaps you ship the whole thing even with its >outstanding problems. For other products, you have to set the highest >possible standards, and quality cannot be lowered for any purpose. I >have no idea what sort of systems VV works with - they could well be of >the sort where issues such as cost and timing are more important than >quality and reliability. There are two methodologies to consider: 1. Write a lot of code fast. Once you get a clean compile, start testing it on the hardware and look for bugs. Keep fixing bugs until it's time that you have to ship. Intend to find the rest of the bugs later, which usually means when enough customers complain. 2. Write and comment the code carefully. Read through it carefully to look for bugs, interactions, optimizations. Fix or entirely rewrite anything that doesn't look right. Figure more review time than coding time. NOW fire it up on the hardware and test it. Method 2, done right, makes it close to impossible to ship a product with bugs, because most of the bugs are found before you even run the code. Nobody can walk up and say "we have to ship it now, we'll finish debugging later." Method 2 is faster, too. John
From: Didi on 7 Feb 2007 13:40 > There are two methodologies to consider: > > 1. Write a lot of code fast. Once you get a clean compile, start > testing it on the hardware and look for bugs. Keep fixing bugs until > it's time that you have to ship. Intend to find the rest of the bugs > later, which usually means when enough customers complain. > > 2. Write and comment the code carefully. Read through it carefully to > look for bugs, interactions, optimizations. Fix or entirely rewrite > anything that doesn't look right. Figure more review time than coding > time. NOW fire it up on the hardware and test it. The most critical rule I believe I have defined for myself is "never write at once more than you can hold in your head". After debugging a piece which is < your brain capacity, move on to the next piece :-). Obviously your "think before coding", do write comments etc. also apply. Accepting that there may be bugs you won't catch may be for years is part of life above a given code size/complexity, as I am sure you know. I have had bugs show up for the first time several years after having written/"debugged" the code... No human creation is perfect, I guess, code included :-). But I completely agree with your point that embedded code about 5-10k lines can and must be made bug free, I have done it myself more than once. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Feb 7, 6:42 pm, John Larkin <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > On Mon, 05 Feb 2007 09:45:44 +0100, David Brown > > > > <d...(a)westcontrol.removethisbit.com> wrote: > >John Larkin wrote: > >> On Fri, 02 Feb 2007 15:13:53 GMT, Vladimir Vassilevsky > >> <antispam_bo...(a)hotmail.com> wrote: > > >>> Jan Panteltje wrote: > > >>>>> It is better to stay on the earth rather then fall on somebody's head. > >>>>> Masking the errors is the worst practice. > > >>>> Yes that is true. > >>>> But you have to try one day to fly.... Errors will show you where to improve. > >>> Deadlines. That's another reason for the software to be the far from > >>> perfect. > > >> So, you will actually release software that you know is buggy, or that > >> you haven't tested, because of some schedule? Please tell me who you > >> work for, so I can be sure to never buy their stuff. > > >John, this is comp.arch.embedded - the answer is *always* "it depends". > > For some products, it is vital to hit the schedule - even if there are > >known bugs or problems. Perhaps you ship the hardware now, and upgrade > >the software later - perhaps you ship the whole thing even with its > >outstanding problems. For other products, you have to set the highest > >possible standards, and quality cannot be lowered for any purpose. I > >have no idea what sort of systems VV works with - they could well be of > >the sort where issues such as cost and timing are more important than > >quality and reliability. > > There are two methodologies to consider: > > 1. Write a lot of code fast. Once you get a clean compile, start > testing it on the hardware and look for bugs. Keep fixing bugs until > it's time that you have to ship. Intend to find the rest of the bugs > later, which usually means when enough customers complain. > > 2. Write and comment the code carefully. Read through it carefully to > look for bugs, interactions, optimizations. Fix or entirely rewrite > anything that doesn't look right. Figure more review time than coding > time. NOW fire it up on the hardware and test it. > > Method 2, done right, makes it close to impossible to ship a product > with bugs, because most of the bugs are found before you even run the > code. Nobody can walk up and say "we have to ship it now, we'll finish > debugging later." > > Method 2 is faster, too. > > John
From: Rich Grise on 7 Feb 2007 16:06 On Wed, 07 Feb 2007 08:42:24 -0800, John Larkin wrote: > On Mon, 05 Feb 2007 09:45:44 +0100, David Brown .... >>the sort where issues such as cost and timing are more important than >>quality and reliability. > > There are two methodologies to consider: > > 1. Write a lot of code fast. Once you get a clean compile, start > testing it on the hardware and look for bugs. Keep fixing bugs until > it's time that you have to ship. Intend to find the rest of the bugs > later, which usually means when enough customers complain. > > 2. Write and comment the code carefully. Read through it carefully to > look for bugs, interactions, optimizations. Fix or entirely rewrite > anything that doesn't look right. Figure more review time than coding > time. NOW fire it up on the hardware and test it. > > Method 2, done right, makes it close to impossible to ship a product > with bugs, because most of the bugs are found before you even run the > code. Nobody can walk up and say "we have to ship it now, we'll finish > debugging later." > > Method 2 is faster, too. Isn't it so sad, when you realize that the vast majority - well, maybe they're only half-vast - use method 1, and still get paid! =:-O Thanks, Rich
From: CBFalconer on 7 Feb 2007 17:03 Didi wrote: > >> There are two methodologies to consider: >> >> 1. Write a lot of code fast. Once you get a clean compile, start >> testing it on the hardware and look for bugs. Keep fixing bugs >> until it's time that you have to ship. Intend to find the rest of >> the bugs later, which usually means when enough customers complain. >> >> 2. Write and comment the code carefully. Read through it carefully >> to look for bugs, interactions, optimizations. Fix or entirely >> rewrite anything that doesn't look right. Figure more review time >> than coding time. NOW fire it up on the hardware and test it. > > The most critical rule I believe I have defined for myself is > "never write at once more than you can hold in your head". > After debugging a piece which is < your brain capacity, move > on to the next piece :-). The corollary to that is "keep your functions short. One screenful is usually enough"/ Please do not strip attributions for material you quote. Please do delete quoted material that is not germane to your answer. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews
From: rickman on 7 Feb 2007 20:52
On Feb 7, 5:03 pm, CBFalconer <cbfalco...(a)yahoo.com> wrote: > Didi wrote: > > >> There are two methodologies to consider: > > >> 1. Write a lot of code fast. Once you get a clean compile, start > >> testing it on the hardware and look for bugs. Keep fixing bugs > >> until it's time that you have to ship. Intend to find the rest of > >> the bugs later, which usually means when enough customers complain. > > >> 2. Write and comment the code carefully. Read through it carefully > >> to look for bugs, interactions, optimizations. Fix or entirely > >> rewrite anything that doesn't look right. Figure more review time > >> than coding time. NOW fire it up on the hardware and test it. > > > The most critical rule I believe I have defined for myself is > > "never write at once more than you can hold in your head". > > After debugging a piece which is < your brain capacity, move > > on to the next piece :-). > > The corollary to that is "keep your functions short. One screenful > is usually enough"/ Interesting. I was taught (back in the days of a CRT being a separate entity from the computer) the screenful rule of "thumb". But I have been working lately with Forth and am becomming a firm believer in the smaller the routine, the better. This certainly works in Forth and works well. I used a Sudoku solver as my second significant program in Forth to learn more about the language. I spent a fair amount of time dealing with stack problems (underflow, items not removed on exiting a word and just general screwing up). Of course I knew the guidlines of keeping the routines small and testing as you go rather than writing a bunch of code and then to start testing. I learned by "proof of the pudding" that these rules make Forth coding and debug much easier. But I really learned the lesson when I tried porting this to C. I needed a project to use for the Luminary Micro design contest and I decided the Sudoku solver would be an interesting one to port from Forth to C. I found that the C code was fairly easy to debug, part because it was largely debugged in Forth and I was closely matching. But then I had to write new code for the new user interface. This was fairly painful in comparison because it was so hard to test the routines until the code was complete to the top. Also, the routines seemed to be a lot larger (10 to 25 lines vs. 1 to 8 lines in Forth) although I have been told I just need to use more dicipline. If C had an easy way to interactively test routines as they were written, I would say C was the clear winner (no stack to fuss with). But given the interactivity of Forth, I am pretty convinced that small routines that can be visually verified and an interactive test environment is the way to go. In either language, I would recommend a 10 line max since that makes debug easier regardless. |