Good presentation - the entire class / week. Lots of good tips and ideas. Needed the refresher and got some new ideas and saw some clever concepts in the code segments, will have to check out your book for summer reading I suppose ...
I think the discussion of reuseable code when using a higher order language needs to include refactoring of the code to reduce methods to smaller (1 page or less) blocks of code which can be pulled out to a generic library. These libraries can be shared accross different projects
The most useful parts of the week were how and where to adapt code to varying environments and hardware. I take hardware and software reuse to heart. You've provided a few more tools for my design and problem solving toolbox. I lead projects where hardware, firmware, features and support software design are very closely coupled in a small design team. Propogating of good ideas, not just getting a product out the door is a thread in my leadership style.
@gongji: How to guess the combinations of features to test when you don't how a customer would use it is a good questions. In a printer, for example, we could print a page on letter paper at 600 DPI single-sided. And we could print on ledger paper at 300 DPI double-sided. And many other combinations of settings for the print job. I wrote a random tester which randomly set about 20 parameters and then tried to print page. We did find one obscure defect with that method. But was it enough? I came across this article, "Combinatorial Software Testing" in IEEE's Computer August 2009 magazine that addressed that very topic. I downloaded their ACTS software (http://csrc.nist.gov/groups/SNS/acts/) and played with it, but as is typical, real work interfered with research for a better way.
@asdurey: Tools for automated low-level function testing: Those tools are fewer because you are talking about code in kernel space (as oppposed to application space) and code that accesses hw, and so the test harness would have to support stubs for kernel-space stubs and simulated hw.
The key to the good documentation result is capturing meaning. Just getting the right line to go to the right state at the right time is only the tip of the iceberg. Implementation (mechanical, electrical, PLC, relay logic, firmware) is the solution, not the description or spec. The problem is in the teaching and use of good communications skills (IMHO).
@RoboPaint: What software tools do I prefer? Isn't that like asking a chef what kitchen utensil he or she prefers? I've used vi, gvim, PSPad, NotePad, awk, grep, sed, sh, ksh, bash, Visual Studios, make, cc, cygwin, Word, Visio, Excel, Paint.net, Solitaire, Chrome, iTunes, and so on. What's funny is while I'm in MS Word, I can write text just fine. When I'm in vi (or gvim) I can write code just fine. But when I try to write a code snippet in my Word doc, I can't do that. I keep trying to hit escape and then use h, j, k, and l to move around. :-)
Hate having to write comments like that one. If I find myself doing it, I put on my Sherlock Holmes hat and go sleuthing for what's going on. Sometimes, it drives our hardware guys batty to have to go dig up why they did what they did and how it works but I get them to do it. I do not do magic fudge factors and trick code without thoroughly explaining them in comments.
@GStringham So far all of the products I have been involved in are in the prototype phase, although we have been through several revisions of a couple of them. But, since I am learning all of this now, I should be all set for future versions :)
@rlallier Interesting (and good) take on that comment. I was thinking more along the lines that the comment was written by a software guy who wasn't the original code author. He was tasked with maintaining the code and was adding comments as he figured things out. He didn't see the point of that code and tried removing it, but found that made it fail! I've been in that position a few times. I've probably written some dumb comments like that too!
@Brandon: I'm guessing from your comments that you are working on a brand-new product, Version 1.0. You'll start to see reusabilty stuff when you work on your Version 2.0 hw which needs Version 2.0 code, (which, of course, is totally reusable from your 1.0 product, right? :-)
Thanks Gary for the feedback on my features combination question. However, I design chips for consumer electronics market (cellphone). You never know how your customers will use your chip. We do randomization on all features combination, but we can only cover so many cases. It is very time-consuming and there is no guarantee. I am wondering if you have ever come across such problem.
@casner LOL Someone hasn't talked to the hardware engineers enough. It's "funny" (not really) to run across comments and code which give evidence that the software engineer didn't exactly understand the functionality of the hardware he was working on and just "winged it" because of things the hardware engineer told him he had to do to "make it work." Can't make software people too embarassed to ask questions! Knew a hardware engineer who could be very intimidating. Caused the software guys to presume things because they were chicken to reveal, through questions, that they didn't know exactly how the hardware worked. I wasn't afraid to ask the "dumb" questions, because I always figured if I couldn't explain what I was doing in the comments, then I didn't have a good grasp of what was going on myself.
@gongji: You don't need to test every combination of swtiches. In my example, Feature A and B are related somehow so those should be tested in all combinations. But if Feature C is unlrelated, there is no need to test C with all combinations and permutations of A and B.
When I wrote test procedures it was so anybody off the street could run them. With repair manuals it was almost the same way. Coding comments should be verbose enough that anybody can understand them (even yourself) weeks after they are written.
Value for me this week has been learning CPP tricks. I've always used it, but have never pushed it to its max.
Biggest hit for me this week is: #define PRT_DEBUG(a) printf a W.O.W. - My code is filled with multi-line debug output, which screws readability. I'm going to use this to reduce all that crap to one-liners.
Very nice to get something out of a class I can put to use immediately. Thanks, Gary!
Good series of lectures. The company where I work is making a big push for continuous improvement. These kinds of education programs to help with continuing process improvement for software development are helpful.
@tniles Yeah, I do that sometimes during development to verify an algorithm is correct. However, what I can't get is support from management to create a full test suite (of these test functions) that can be used for regresssion testing. We're always behind schedule and nobody wants to "pay it forward," so we keep doing manual testing (or none at all depending on how much the sales manager is yelling for the new feature or bug fix).
@abarman I know what you mean about the streaming. IT where I am worked hard to get our corporate network from blocking it, and even then, we had that cut-out problem. I used our guest wi-fi access and network to log on to get around the blocking and unreliability. Unusual. YouTube videos come in just fine on the corporate network.
ASIC development is becoming more and more software-like (writing RTL code). Reuse is a big requirement for us too. Lots of parameters in our design and strict naming rules. I didn't hear anything about naming rules in your presentation. Is that important in the software world too? I would think so...
In general the lectures were useful to understand what's happenning in industry in general about code reuse in embedded products. It helped me a lot to confirm that we are in the right path and we have to continue this this effort of producing reusable software components; it benefits everybody, not just internally to reduce development time an cost but also our customers
Thank you for taking to the time to provide such a great lecture
@lawson and @cavebiker: you can always place tests within your code if you have the extra memory space. Can't cover everything, but could cover a lot of basics, too. (example: passing given inputs to produce expected/known outputs)
I am a hardware engineer and I really like to have more feedback from firmware engineers to help me optimize the ASIC, especially regarding register mapping. However, in most of the companies I worked at, hardware and software rarely talk. It is a shame.
Our off-the-shelf C compilers, for the newer products support extensive preprocessor directives. Our in-house language compiler, which is C-like, has an unfortunately limited and primitive set of preprocessor directives. For example, it does not support the #error or #warn directives. I have worked around this limitation by putting in code that will not compile into clauses which otherwise should have used a #error
@Brandon Ow! Feel your pain. First job out of college, we had no marketing dept. Sales had a direct pipe to R&D and the license to promise the customer anything. My boss called us the SMOP department, for Small Matter of Programming -- because that is what the sales guys would tell our customers who wanted custom features or functionality.
@Kentj I concur. Also, proper naming of functions and variables that provides insight into what they do. There's several good books on readable code that have concepts that seem so simple but they so often seem to be skipped or not done in practice.
@GStringham: I've been pulled away on critical builds this week (yes, even during the lunch hour...), so I missed parts 2-4. Would it be worth tuning in live today, or would it be better to just get caught up on the previous lectures?
Anyone who attends five hours worth of lectures and Q&A just to get a $5 gift card has their priorities messed up. We've had a reuse edict passed down from on high and I'm looking for all the info I can get.
All your discussions about the starbucks card this week is making me nervous. I'm trying to figure out if you are attending only because you want free coffee and you really don't care what I have to say. Or if I am so boring that you need coffee to stay awake during my presentation. :-) Maybe I ought to do more singing or play a laugh track in the background. :-)
-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.
-Be sure to click 'Today's Slide Deck' under Special Educational Materials above right to download the PowerPoint for today's session.-Be sure to click 'Today's Slide Deck' under Special Educational Materials above right to download the PowerPoint for today's session.
I mean the old way that they determined if you "attended" if you downloaded the slides before class then you would get them, now they limit to the first 25 people, but who knows what determines if you "attend". Do we have to download the slides, do we have to login, do we have to post? I have no idea if according to them I am "attending".
The first Tacoma Narrows Bridge was a Washington State suspension bridge that opened in 1940 and spanned the Tacoma Narrows strait of Puget Sound between Tacoma and the Kitsap Peninsula. It opened to traffic on July 1, 1940, and dramatically collapsed into Puget Sound on November 7, just four months after it opened.
Noting that we now live in an era of “confusion and ill-conceived stuff,” Ammunition design studio founder Robert Brunner, speaking at Gigaom Roadmap, said that by adding connectivity to everything and its mother, we aren't necessarily doing ourselves any favors, with many ‘things’ just fine in their unconnected state.
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.