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.
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.
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.
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.
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.
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".
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.
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.
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.
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?
@ 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.
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!)
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.
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?
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.
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?
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?
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.
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.
@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.
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...
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?
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.
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.
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?
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.
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?
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.
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 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?
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. ;-)
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?
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?
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.
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?
@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.
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
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
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?
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.
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.
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.
• 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.
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!
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.
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.
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...
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.
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
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!
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?
The development of embedded systems becomes dramatically different from pure software projects when you start to look at the "real" electrical signals.
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. :)
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.
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.
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. :)
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.
As energy efficiency becomes more and more a concern for makers of electronics devices, researchers are coming up with new ways to harvest energy from sound vibration, footsteps, and even electromagnetic fields in the air.
The government wants to study your brain, and DARPA wants to use similar information to give robots true autonomy beyond any artificial intelligence developed to date. Sound like science fiction? It's not.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
1 
