HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Comments
You must login to participate in this chat. Please login.

Thanks Jack and Alex.

Iron

Super good info...

Thanks

 

Iron

Very practical and informative.  Thanks.

Iron

Very Informative!  Thanks again!

Iron

Thank you Jack and Alex. Great presentation.

Iron

GREAT sir jack...appreciated...

now i am preparing for the day 5 class presentation to end of the whole class...

thanks to digikey once again, likewise to design news for this continuing education provided to us for our PDH Certificates...

it's about to end and now with the Q & A session...thanks again for an excellent presentation sir jack...

it's about slide 31 now...

i am now on slide 23 of the presentation...

i am now on slide 1 of the presentation...

i have now downloaded the presentation slides for day 4 slass lesson...

good evening sir jack! i am now on your day 4 class lesson to complete the whole week schedule...

very interesting ideas

Iron

Thank you Jack and Alex.

Iron

Thank you Jack and Alex.

Iron

Thank you Jack and Alex for another great presentation.

Iron

I remember a Professor that I had who used to say that a good way to proof read what you write was to read it backwards, literally from the end to the beginning.  It did not translate as well into code.

Iron

I know that when I try to inspect and debug my own code, I have fallen flat on my face several times just missing errors because I read what I meant and not what I wrote.  

Iron

I never realized how big a difference periodic inspections throughout the entire process could make.  

Iron

I have been using "reading" and inspections for 20 years now. The techniques are effective. When my programmers produce an unstable buggy system -- if necessary -- I will read the entire project -- find the questionable areas and get them fixed. Even done as a one person project it is far more effective than testing. Certainly a team would be the best approach o inspections.

 

Iron

That was excellent. So many programmers regard their code as secret potions nobody should understand. Managers let them get away with because managers don't think about the business this way. Excellent lecture that should be heard more widely.

Gold

Good series so far.

Iron

About fell out of my chair!  Now they are saying in a presentation about "debuggging" that it's about careful and good design and review.  Some are saying that Bob Pease is no longer with us ... what will they say next?

Trying to view "Part IV: Professional Debugging I -- Managing Bug Lists & Metrics" from archive (4th day of 2nd week).  Audio is there only for the first 3:25 of the program (covering the first 2 slides).  Do you have a backup or something you could try posting there, so I can hear the whole thing?  I've tried several times, refreshing the page, and linking to the page again from the schedule page.  It's just not all there.  Thanks.

Iron

Nice job again, Jack.  Excellent presentation!

Iron

My company blocks out blogtalkradio.com, so I have to do these sessions in archive.  However, my favorite comment occurred when I was working for a major medical manufacturer.  There were a number of lines that stated "Bad Error, need better error". 

Platinum

Good Afterrnoon to all.

 

Iron

Inspections are quite similar to design reviews prior to ging into fabrication of a physical design.  It is a lot cheaper and faster to find errors on paper than it is in the fabrication floor or facility.  Inspections and design reviews performed by qualified persons who did not participate in the original coding or design are extremely rewarding.

Iron

Great series! Thanks!!!

Iron

correction -- errors, not arrors

Iron

I introduced peer reviews for mechanical designs before release and this greatly reduced arrors and rework.

Iron

Jack, I think you made a strong argument and I will internally push for code inspections in a form consistent with your outline.

Always review the code and bugs to determine how to make it better and develop a system to make coding quicker and less bug ridden.  It's all part of coding metrics and good coding practices.

Iron

Plus if you get the right processor there is plenty of code developed on the internet to help a person get going and modify the already developed code much quicker.

Iron

Debugging C code is easier than debugging LabView.  I've seen guys trying to debug other peoples LabView programs for days without getting anywhere.

Iron

LabView works well for alot of robotics applications but I enjoy coding things for robotics in C code with the use of an RTOS.

Iron

Purturbation analysis is done on embedded design of systems on satellites and spacecraft.

Iron

You can compare versions of Visual Paradigm here: http://www.visual-paradigm.com/product/vpuml/provides/?edition=ce

Iron

Community Edition is free, other paid

Iron

UML software is also available at http://www.visual-paradigm.com

Iron

Alex; Can you tell me what I can actually DO with the credits earned from this series? Even one cup of coffee? A pretty diploma? Anything? Or is it just acknowledgement of time spent?

Iron

"Purturbation" analysis

Iron

Singular Perurbation analysis is also another method used in process control

Iron

@ Luizcosta - your approach is an interesting one but I suppose you might have to transform your code into a purely mathematical model - Use of formal Methods perhaps.

 

Iron

I have to run too. - See you all tomorrow! :o)

Iron

Thank you so much, Jack.

 

Iron

Thanks Jack for sharing!

Iron

I have to run - nice chatting with you all.

Iron

I've been using UMLet with great success: simple and easy to use, almost as good as pencil on paper

Iron

Any UML based software development tools to assist with Development - from requirements analysis prior to design?

 

IBM's Rational is the most popular. There are others but I'm having a brain fart right now!

Iron

I have use OpenCV for automated vision inspection, more code, but better results than LabVIEW and NI Vision

Iron

Thank you for the tip, Jack. I will try to reach you via your web site for more specifics about my ambitious plans to finish my PhD.

Iron

Any UML based software development tools to assist with Development - from requirements analysis prior to design?

Iron

Jack, are you connected to a University or only dedicated to consulting?

 

In the past; not so much now.

Iron

luizcosta - if you're doing a PhD on automated testing, check out some of the cool things people do with National Instruments' LabVIEW. Some tie a camera to a test machine and have it watch the displays of the system under test. The NI stuff can parse what the camera sees and use it to close the test loop. (And send me a copy of your thesis when you're done!)

Iron

Jack, are you connected to a University or only dedicated to consulting?

Iron

Thank you for this lecture

Iron

Thanks again for a very informative presentation!

Perhaps I should do that study (fuzzing and Kalman Filter) applied to automated software testing to finish my PhD.:o)

 

Go for it! In the embedded world we need extra fuzz: like increase the load by cranking up the interrupts, or eating away at the memory pool.

Iron

jack21: is "cheating" allowed in cyclomatic complexity calculations? Using an array of function pointers instead of a case statement, for example

 

Ouch! That's one reason we need inspections. It's true that we sometimes have to do awful things, but inspections sort out the awful from the insane.

Iron

Perhaps I should do that study (fuzzing and Kalman Filter) applied to automated software testing to finish my PhD.:o)

Iron

jack21: is "cheating" allowed in cyclomatic complexity calculations? Using an array of function pointers instead of a case statement, for example

Iron

In control systems design, people use white noise (or other noise like signal with know statistics) to learn about the internal dynamic of a "backbox" type of mathematical model. Is anyone studying this for debugging, Jack?

 

That's very much like fuzzing. I really thing we need to do more work on it in real-world systems.

Iron

Jack, do you suggest Static Analysis tool for C/C+ (both for Windows/Unix)?

 

Check out Polyspace (Mathworks now), Klocworks, Green Hills, Coverity, Grammatech. Great stuff, not cheap.

Iron

if possible, mock up something. A LED is the embedded version of printf-debugging.

Iron

In control systems design, people use white noise (or other noise like signal with know statistics) to learn about the internal dynamic of a "backbox" type of mathematical model. Is anyone studying this for debugging, Jack?

Iron

Ok, thanks. I remember now CAN was an inter chip comm standard.

Jack, do you suggest Static Analysis tool for C/C+ (both for Windows/Unix)?

Iron

Jack, my impression of code testing is that it allows the code to be verified correct before the system is tested in the real world, where another whole set of "bugs" come to light, such as timing, impedance problems, differences between vendor spec sheets and actual chip operation, power supply stability, heat problems, RFI susceptibility and FCC compliance, etc. Is this a fair statement?

 

I believe in integration testing - which is the real-world stuff you mention - from day 1. There just isn't much to integrate at first, but as time goes on we've generally done a good job stressing the system.

Iron

Where can I find information on "clean-room" practices as might be used with high assurance system development?

 

Those are really two different subjects. Cleanroom is about using no external inputs/code.

Iron

Jack, my impression of code testing is that it allows the code to be verified correct before the system is tested in the real world, where another whole set of "bugs" come to light, such as timing, impedance problems, differences between vendor spec sheets and actual chip operation, power supply stability, heat problems, RFI susceptibility and FCC compliance, etc. Is this a fair statement?

I tried to install Trac and couldn't get it to work.  redmine worked out of the box and has SVN integration hooks

Iron

Fuzzin is the heuristic science of trying to break the code. Usually for security and robustness testing. Is that an acurate answer Jack?

 

I'd recommend the Wikipedia article - I hate to try to be complete in one sentence!

Iron

I like redmine for bug tracking.  it provides a wiki as well for extra documentation.

 

There's also Subversion with Trac for a wiki.

Iron

Where can I find information on "clean-room" practices as might be used with high assurance system development?

Iron

Fuzzin is the heuristic science of trying to break the code. Usually for security and robustness testing. Is that an acurate answer Jack?

 

Iron

I like redmine for bug tracking.  it provides a wiki as well for extra documentation.

Iron

Can anyone tell me what you can actually DO with the credits earned from this series? Even one cup of coffee? A pretty diploma? Anything? Or is it just acknowledgement of time spent?

Iron

Is there a textbook/ reference that descirbes the inspection process for management?

 

Talk to SmartBear Software. They have a very readable book.

Iron

What is "fuzzing"?

 

Feed all kinds of random data into the functions.

Iron

Is there a textbook/ reference that descirbes the inspection process for management?

Iron

We have been using " Mantis Tracker " for bug fixing in firmware our firmware guy develops. Yet we seem to having lots of issues with the codes

Iron

Jack, how effective is fuzzing and how much of it is recommended?

 

Great question, no one really knows. I've never seen it used in embedded.

Iron

Jack, how effective is fuzzing and how much of it is recommended?

Iron

Maybe I just need to do a little research. Thanks, Jack. :)

How does Misra relate to CAN (1st class)

 

MISRA is the standard. The only CAN I know is a comm bus used in the automotive industry.

Iron

In order to verify your code through inductive reasoning, you need to test the proposition, and then the individual instance, in order to be sure your code is correct for all potential circumstances.

 

There's always modeling, too, and prototypes.

Iron

How does Misra relate to CAN (1st class)

 

In order to verify your code through inductive reasoning, you need to test the proposition, and then the individual instance, in order to be sure your code is correct for all potential circumstances.

Jack, in my opinion, testing code is problematic... sure, you test individual instances of the function, but how do you test the proposition? If you can't test the proposition, then testing an individual instance does not lead to verification of the function as a whole...

 

That's the issue with getting requirements right. For info see Karl Weigers book Software Requirements.

Iron

@syakovac, I agree with you, if the first pass is where the design is frozen. Sussessive refinement and refactoring goes a long way for the second look.

Iron

Firmware manager with me always talks of " Walk Through the code" Now I figure it out as Inspection

 

A walkthrough is less formal, and less effective, but two heads are always better than one.

Iron

Jack, in my opinion, testing code is problematic... sure, you test individual instances of the function, but how do you test the proposition? If you can't test the proposition, then testing an individual instance does not lead to verification of the function as a whole...

Firmware manager with me always talks of " Walk Through the code" Now I figure it out as Inspection

Iron

Jack, Idon't know if you saw this one: of 10 programmers in the industry (say in the embedded world) how may are involved in a project that employs test design = test that is planned way before any line of code is written?

 

Sure- less than 1.

Iron

Do you have any idea how much time NASA devotes to code inspection for space missions, what standards they use?

 

No idea how much time, but they have their own standards. They spend a ton of $$$ on this as they want it perfect. They average 1 bug per 400,000 lines of code.

Iron

Post Code Inspection, shouldn't the team also do a review classifying the kind of bugs and their frequency in the code and suggest additional coding practices to mitigate the recurrence; i.e.; refine coding standards to improve on future practice of all?

Plausibly also it can improve the capability of Code inspections to identify bug tendencies based upon the "culture" programmers.

Are there any tools for code tracing to ensure all branches or decisions are exercised i.e.; prevent overlooked inherent dependencies in code? How might traceability of dependencies best be addressed via Inspection?

 

Absolutely. That's the best way to run a team. For tools, LDRA has this feature.

Iron

NASA is very, VERY thorough, cnorton. It is worth doing some research on!

Jack, Idon't know if you saw this one: of 10 programmers in the industry (say in the embedded world) how may are involved in a project that employs test design = test that is planned way before any line of code is written?

Iron

Do you have any idea how much time NASA devotes to code inspection for space missions, what standards they use?

Iron

@jcbacas -- I think regression testing is extremely valuable and small tests are king

Iron

what about writing tests as small parts of code are written, and regresion testing at every step with all these tests ?

 

That's Test Driven Development, or part of it, and it's better than nothing. Too often our tests are awful. But I'm not a fan of the approach advocated by TDD.

Iron

luizcosta, you using "synergy" makes me feel dirty! :P

Post Code Inspection, shouldn't the team also do a review classifying the kind of bugs and their frequency in the code and suggest additional coding practices to mitigate the recurrence; i.e.; refine coding standards to improve on future practice of all?

Plausibly also it can improve the capability of Code inspections to identify bug tendencies based upon the "culture" programmers.

Are there any tools for code tracing to ensure all branches or decisions are exercised i.e.; prevent overlooked inherent dependencies in code? How might traceability of dependencies best be addressed via Inspection?

Iron

@danlafleur -- Too "blocky" makes large designs with high piece-prices.

Iron

Reverse engineering code to obtain the original design goals seems an almost impossibe task.

Thanks for a great presentation Jack.

Iron

I think this goes back to the first class by John T. on design goals: as far as firmware standards go and code inspection, should a basic functional block diagram be available so inspection teams can be sure the code addresses all the requirements in the first place, and exceptions are clearly identified?

 

Some sort of design doc should be available. UML, block diagram, you name it. But one should never start a project w/o a clear, documented, idea of the objectives.

Iron

what about writing tests as small parts of code are written, and regresion testing at every step with all these tests ?

 

Iron

Thanks everybody for the synergy.

Iron

Thank you Alex for the opportunity.

Iron

for the hardware guys out there, build the design in snmall blocks at a time and test as you go. just like the firmware.

Iron

Thank you Jack for the wisdom.

Iron

What is a good time frame between the when programer finishes his code and when it is inspected?  I suspect too soon leads to an inspection that doesn't find much but if it is too long the programer forgets many of the details and wastes time in the inpection trying to remember what he did.  Although if they did a good job of commenting it shouldn't take any time at all to remember what they did.  ;-)

 

I figure a few days to keep the ball rolling.

Iron

Jack, do you suggest any tool to measure Cyclomatic Complexity?

 

There are tons. LDRA for instance. RSM from M Squared is really good. I think there's a freebie from Campwoods software.

Iron

What is "Static Analysis"?

Iron

I think this goes back to the first class by John T. on design goals: as far as firmware standards go and code inspection, should a basic functional block diagram be available so inspection teams can be sure the code addresses all the requirements in the first place, and exceptions are clearly identified?

Jack,

What is a good time frame between the when programer finishes his code and when it is inspected?  I suspect too soon leads to an inspection that doesn't find much but if it is too long the programer forgets many of the details and wastes time in the inpection trying to remember what he did.  Although if they did a good job of commenting it shouldn't take any time at all to remember what they did.  ;-)

Iron

Am sorry but what is v(g) again?

 

 

Complexity

Iron

Also do you suggest any tool for Static Analysis?

Iron

Jack, of 10 programmers in the industry (say in the embedded world) how may are involved in a project that employs test design = test that is planned way before any line of code is written?

 

Less than one.

Iron

Thank you for the excellent presentations. What suggestions do you have please for making code and firmware less susceptable to hacking in the finished product?

Iron

Jack, do you suggest any tool to measure Cyclomatic Complexity?

Iron

Jack, what is your ONE SENTENCE to be used to small prospective software customers when they argue about the initial perception that it "will be too complicated and costly to go this route" sort of statements. In the past I used the reason that formal devlopment transforms the software in an asset that is widely independent of language and platform initially employed. Does that work, in your opinion?

 

There is a deluge of data that shows two things: doing it w/o discipline will make the code buggier, and we'll deliver later.

Iron

luizcosta: shortcuts during development cause a "technical debt" that has to be paid later ... with interest

Iron

Am sorry but what is v(g) again?

Iron

Jack, of 10 programmers in the industry (say in the embedded world) how may are involved in a project that employs test design = test that is planned way before any line of code is written?

Iron

@AJ94dB,  --     I am a hardware guy.  What we have found is that very accurate detection and measurement of coverage of specific cases is most useful.  It is also a very good measure of how upset the firmware guy is going to be since if the hardware isn't easy to test independently from the system level, the firmware guy is going to be lost and not able to see inside the design.  So, my testing means always from the top level and I instrument the code to make sure specific cases and interactions are hit.

Iron

Jack - Have you ever updated your Better Firmware Faster DVD course?

 

No, it's on my long-term todo but there just aren't enough hours in the day.

Iron

schmiedl, you realize that, if you can hack your car via the CAN bus, SOMEONE ELSE can hack your car via the CAN bus, and effectively clip your brake wire without physical evidence. XD

Alex, please post the email

Iron

One-person team code inspection suggestions:  (thanks to all)

I found that a really bad memory helps :-)

for a one person team, one thing I've done is read my code from the bottom backwards to the top and see if I can figure out if it does what I want.

 or do something else for a while and come back later

when writing code for yourself, you can be the "reader" yourself for inspection if you write comments ahead of time (pseudocode-ish) specifying what you want to do, and then comparing to the actual code to see if it does what you intended


Iron

Jack, what is your ONE SENTENCE to be used to small prospective software customers when they argue about the initial perception that it "will be too complicated and costly to go this route" sort of statements. In the past I used the reason that formal devlopment transforms the software in an asset that is widely independent of language and platform initially employed. Does that work, in your opinion?

Iron

what life cycle should we design for???

 

I guess it depends! The model will depend on your product. A ship-and-forget is very different from anvionics.


Iron

whogan3, I found the same problem. I went to archives and restarted each lesson, clicked to advance to the end. Then my credits arrived.

Iron

Good meterial. A lot valuable points. Thank you.

Iron

Jack - Have you ever updated your Better Firmware Faster DVD course?

 

Iron

Are there text books for management describing the inspection process?

 

Iron

Thank you again....end of line...

Iron

@ snadu13 : flowcharts, and also "approved" are esential for understandig what you need to do

Iron

what life cycle should we design for???

most important in a car: can I hack it via the CAN bus? :-D

Iron

Jack, thank you very well presentation.

Iron

Unreachable code is code that is written, or copied from a previous design, that is not used in the curretn application, but exists in the code.

 

Iron

It is a wave of ignorance, Jack. :)

if !(true)

{

//You will never get here

}

Alexander, is the course credit for Microcontrollers, Basics  different than Microcontrollers, Advanced? I have 20 pts after 4 days with Advanced and only 15 pts for 5 sessions with Basics.

Iron

Wonderful presentation.  Thanks.

Iron

Hey Jack,

For those of us just deciding on standards practice to invoke, which would you recommend?  I guess I'm looking for something "short and sweet", yet as all-encompassing and complete as possible.

Great series of lectures.  Thanks! 

Iron

What is "unreachable code?"

Thanks Jack for the insights I can use later and reflections on past challenges.

And thanks to all for the points of view and experience.

Iron

Nowadays i find the firmware developers not doing flowcharts as in earlier days of software personnel. I donot know why.

Iron

Excellent presentation, again, Jack.  Thanks.

Re: "I avoid block testing because it takes a lot of time "

I was like that until a co-worker got us started on unit testing with Visual Studio (the target is embedded but VS runs c code very well).  Now I can test my code and experiment to get the code perfect and refined QUICKLY.  I don't have to wait for build, load and manual test on the target.  Even better, one I have the test I am confident that I can make changes and the unit test will catch things when I do something wrong.  Define what the block is to do, design the test to prove it, code it.  We learn faster with faster cycles on smaller functions.

Iron

I'm not going to California for an embedded conference when all my work is here in Boston.

Thank you Jack and Alex..although I was late a little bit..great presentation.

 

Iron

As per SIL ratings

• All programming statements and both sides of all branches must be tested for SIL 3, but only one branch needs to be tested for SIL 2. 
• Semi-formal methods are highly recommended for SIL 3 software design and development, but only recommended for SIL 2. 
• Defensive Programming techniques are highly recommended for SIL 3 development, but these techniques are only recommended for SIL 2. 

 

Iron

Jack and Alex, Thank you

Iron

If we follow Jack's advice from an earlier presentation and keep functions small, reading the code should be easier.

Iron

today's presentation is so practical issue that is bothering me  whenever I make a program.

Iron

Very interesting and useful information. Thank you Jack and Alex.

Iron

Code inspections are often perceived as programmers not doing programming, hence not being productive.
However, programmers debugging are obviously hard at work, sweating, cursing, hunched over their terminals.
Educate the boss!

Iron

Lots of useful information. Thanks

Iron

Great plans. Must have management buy in.

excellent presentation, jack. many thanks! thank you too, alex.

Iron

Writting code for a SIL ratig for safety valve controls, very very detailed.

Iron

is object-programmaming (c+ ) better than just writing code for the complete unit???

Smartbear.com has some lightweight code review tools that can help.

Jack, any other way for debugging other than break to smaller blocks?

Iron

From the discussions i understand that the inspector of codes should be as knowledgeable, if not more, about the project. I mean the complete flow of the project.

Iron

Good insight... Thanks Jack!

Iron

Jack and Alex, thank you very much for a very informative lecture!

Iron

Another very good presentation. Thank you Jack.

Iron

Great information, Thank you for the lecture

Iron

What is a good time frame between the when programer finishes his code and when it is inspected?  I suspect too soon leads to an inspection that doesn't find much but if it is too long the programer forgets many of the details and wastes time in the inpection trying to remember what he did.

Iron

Thank you Jack, Alex, and Digikey for this great presentation. GOOD STUFF!

Iron

Thanks Jack, I was not familiar with this way to inspect codes.

thanks for the lecture

Iron

on the top of your project you can also add your email address to be able to be contacted or contact others

Iron

Any recommndations on some online resources that I can learn more details about the inspection procedure you present?

Iron

This was great, thanks Jack!

Iron

I've got to get my boss to listen to this!

Iron

Important, down to earth part of successful long lasting programming.

Iron

that's right. Inspections do not slow the project.

Iron

Great presentation... Thanks Jack.

Iron

Jack, do you have a link to the "nspections don't slow the project" metric facts?
I missed the gentlemans name.

Iron

large codes are comprised by several smaller codes. in my honest opinion, testing the smaller blocks before going to another produces lesser headaches. bugs can be identified and squished early in the process...

Iron

Jack - Any opinions about Extreme Programming and debugging?

 

Iron

I avoid block testing because it takes a lot of time to make special test structures for block environments that end up not being re-usable at the system level.  If you make a block with the testing in mind, you can easily test it at the top level....usually.

Iron

TDD done right will provide better code coverage, but building a good set of testcases can be hard... especially if you're working solo

Iron

@Jack21 - you mentioned TDD earlier in the week, what comments/experiences might you have using this method to document and write bug-free code?

Iron

yeah testing logical blocks as you go is definitely a good approach, I'm bad about that and it always comes back to bite me

Iron

it is really safe to do it this way

Iron

I like building small blocks of code and test as I go.

Iron

I like this idea of imputability.

the hard bugs are nearly always in the interaction between many blocks

Iron

Functions should self test parameters upon entry and return appropriate error codes.  This helps greatly to reduce bugs such as divide by zero!

Gold

Inspectors' names on header blocks is a very good idea. Going to start this from now on.

Iron

at least for that block, yes

Iron

do writing code in small sections and testing that code help to eleminate errors???

when writing code for yourself, you can be the "reader" yourself for inspection if you write comments ahead of time (pseudocode-ish) specifying what you want to do, and then comparing to the actual code to see if it does what you intended

Iron

@john.evans : or do something else for a while and come back later

Iron

@john.evans

but its hard to find bug in a 1 person team..

Iron

what if testing code was like testing a new set of wings, jump off the cliff and see what happens?

Iron

Good analysis to correlate bugs vs LOC inspected

Iron

for a one person team, one thing I've done is read my code from the bottom backwards to the top and see if I can figure out if it does what I want.

Iron

What I encounter is that code inspection is planned but no one has time to get together for the code inspection meeting(s) because everyone is too busy writing code!

Iron

tcyar: I found that a really bad memory helps :-)

Iron

Jack, of 10 programmers in the industry (say in the embedded world) how may are involved in a project that employs test design = test that is planned way before any line of code is written?

Iron

Yes, "Keep management off the team!"

 

Iron

We have used logging of tests in order to backtrack bugs.

Gold

@Jack21 - Do you have any suggestions for one-person "teams" to do code inspections?  Tough to see mistakes when you made the mistake !!

 

Iron

oops - did not see anything about Fagan on the slides... Jack you've just mentioned it verbally...

Iron

Jack -  you are using a lot of common sense - it yields great code!

Iron

How do you start an inspection team?

Iron

I assume, Fagan inspection process is applicable to firmware/embedded code...

Iron

The development of embedded systems becomes dramatically different from pure software projects when you start to look at the "real" electrical signals.

Iron

Jack, does v(G) stand for cyclomatic complexity?

Iron

crystal clear code without minimal comments is not "crystal clear"

Iron

luizcosta refresh ur browser

Iron

Looks like I lost audio feed.

Iron

Writing good comments is not an excuse for not writing clear code, and vice-versa.

FrankBishop, no one is arguing you should have more comments so you don't need to write clear code. What we're saying is that you need to write crystal clear code AND comment it thoroughly. :)

how do you measure  bug rate?

Iron

Hi, Jack, Alex, and everyone else. I finally made it in.

Iron

compound statement help also with macro integration

The nice thing about standards is that there are so many to choose from !!!

Iron

what are ints and strings seems to change every 5 years

There are code coverage tools for testing that all the code gets exercised

How do you have a float that does not comply with the standard?  Wouldn't it not compile?

Iron

Is the MSRA publication free or do you need to purchase it from them?

Iron

syakovak, I agree with the // vs. /* */ comments. I've run into that issue too. :)

I disagree more comments is not always better

It should be more of a question of balance between clear code

and expresive comments

Is MISRA C 2004 the most recent version?  Jack shows an earlier version.

 

Iron

Comments ? At least everyone will understand what your code want to do even is not doing that :(

Iron

Yes I agree

 

// this

// is much better

// for several lines

common lisp has an interesting comment convention:

;;;; for the file

;;; for a section within the file

;; for the bunch of lines

; inline comment after the code

Iron

what page are we on?

Iron

I learned a long time ago to not use /* and */ comments and only to use // because when you have a massive compiler problem and need to binary search for the poison, that is easy to do by globally commenting large sections with the /* */ but that only works if there are NO comments of that form.

Iron

Horray

Validation for something I experience every day

I think the style of slide 12 is followed by most companies which provide source code (RTL, C, etc)...

Iron

I like

//==========================

Horray for your comments on "use (real) English!

 

Iron

And, yes, I've seen software with comment blocks all written in French...

 

Iron

if you want a "self-documenting code", write tons of comments... lol

Iron

it sis true, you need time for that

Iron

off course documentation is important

Iron

The problem with comments is that they are not functionally linked to the code and, hence, get out of sync with no penalty.

Iron

LOL...I've done that before

Iron

be nice to the maintenance programmer trying to get the code working later

Iron

Good documentation is essential.

Iron

There are code beutifying tools that could solve the issue of indentation

by just requiring it be run on any code before its checked into source code management

http://git-scm.com/ is the homepage for git

Iron

for slide 9, I think that every program should have a complete introduction and comments (even for the individual blocks) to explain its operation to the person who has to update it in a few years.

Iron

github gives you free project hosting and tutorials and all kinds of goodies, http://gitref.org/ is a nice manual too

Iron

What is the best link to info on GIT?

Iron

Great point at slide 8, Jack. I agree with experience with units... :)

Iron

Yes, Vault is not cheap,

Iron

yeah SVN used to be the go-to VCS (CVS before SVN), but git is the way to go now

Iron

I liked vault but dollar for dollar

subversion is okay

 

I got used to git and it works very well for me. :)

I like GIT since it is SVN friendly, cross platform, and allows you to easily branch and have multiple developers

Iron

Vault is a good VCS

Iron

02 Feb 2012

I like 

2012 Feb 02

any tool for bug management  / bug matrics?

Iron

Any preferences for VCS?  GIT, SVN, ???

Iron

ceribeiro: Version Control System

Iron

@caribeiro Version Control System

vcs - version control system

Iron

VCS==version control system

Iron

ceribeiro - version control systems (SVN, git, CVS, etc)

Iron

Where can a get and compile the code in slide 4

Standardized how... To what standard? (version control, make, project, build, etc.)

 

Iron

A standard with no enforcement is not much of a standard

I believe in validating the software against the standard 

by using a automated verifcation step

aren't bugs the spice of any code?

Iron

same here - had that "long toe radio" loop going for a while until I reloaded the page...

Iron

I always say that I'm a bugger.

 

lots of bugs come from not testing edge conditions

Alex, when the sound came on, I got nothing but a repeating loop with the woman announcing the radio station. I had to reload the browser to get the program proper. Please fix that bug. :)

Nice drinking song!!!

Iron

sound id loud and clear

Iron

thats only in some languages

I expect palm trees soon here in Edmonton.

Iron

you will lose..haa haa

Iron

If the groundhog sees his shadow, there will be 6 more weeks of winter.  If he doesn't see it, there will be 1-1/2 months more winter.

Iron

Thank you Alex for providing the series and facilitating..

Iron

There is NO SNOW on the ground in Minnesota, AND it is 40 degrees out... Global warming has won :(

It's spring-like weather in Chicago...

Iron

right, groundhog should be sleeping

Iron

In Texas, we still need to see winter start to worry about when it will end.

@NoOP, groundhogs are right 50% of the time. It's spring or not yet.

Iron

miket: global warming wins

Iron

PA groundhog sees his shadow -

OH groundhog doesn't

who wins the prediction?!

Iron

Hello, ready to absorb!

 

Silver

Jared H, thank you for PDF

Iron

Same to you all. :-)

Iron

Groundhogs are clueless

Iron

Ready for today's class!

Hello everyone, happy Thrusday to all,

Iron

JaredH: thanks for pdf

 

Iron

Hello everyone.

Alex; Thank you so much for providing this valuable apportunity for us.

Iron

If anyone is interested here is a PDF of todays slides.  http://dl.dropbox.com/u/3757390/4ProfessionalDebuggingIManagingBugListsMetrics.pdf

Iron

Good Afternoon everyone

Iron

Be sure to click 'Today's Slide Deck' under Special Educational Materials above right to download the PowerPoint for today's session.

Blogger

The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.

 

Blogger

I am a "Professional Debugger" for desktop and systems apps -- micros, not so much.  Hoping Jack will change that today.

Iron

I know I'm early, just can't wait!

Iron


Partner Zone
Latest Analysis
Adam Berger hacked a computer keyboard into a mini key-tar to play with his band.
Altair has released an update of its HyperWorks computer-aided engineering simulation suite that includes new features focusing on four key areas of product design: performance optimization, lightweight design, lead-time reduction, and new technologies.
At IMTS last week, Stratasys introduced two new multi-materials PolyJet 3D printers, plus a new UV-resistant material for its FDM production 3D printers. They can be used in making jigs and fixtures, as well as prototypes and small runs of production parts.
In a line of ultra-futuristic projects, DARPA is developing a brain microchip that will help heal the bodies and minds of soldiers. A final product is far off, but preliminary chips are already being tested.
If you're planning to develop a product that uses a microcontroller, you'll want to take note of next week's Design News Continuing Education course, "MCU Software Development A Step-by-Step Guide."
More:Blogs|News
Design News Webinar Series
9/10/2014 11:00 a.m. California / 2:00 p.m. New York
7/23/2014 11:00 a.m. California / 2:00 p.m. New York
7/17/2014 11:00 a.m. California / 2:00 p.m. New York
6/25/2014 11:00 a.m. California / 2:00 p.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Sep 22 - 26, MCU Software Development A Step-by-Step Guide (Using a Real Eval Board)
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.
Next Class: September 30 - October 2
Sponsored by Altera
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service