|
Embedded Muse 175 Copyright 2009 TGG February 16, 2009
You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. Subscribe and unsubscribe info is at the end of this email.
EDITOR: Jack Ganssle, jack@ganssle.com
CONTENTS:
- Editor’s Notes
- Quotes and Thoughts
- Tools
- Visualizing ICs, Past and Present
- Responses to Computer Science Education
- Jobs!
- Joke for the Week
- About The Embedded Muse
Editor’s Notes
Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/classes.htm .
Brazil! The country of samba, feijoada and caipirinha. And, of course, embedded systems. I’ll present a two-day version of my Better Firmware Faster seminar in Sao Paulo March 25th and 26th. See http://workshop.embarcados.com.br for more information.
Are you happy with your bug rates? Schedule slippages? If not… what action are you taking to get back on-track? I’m presenting a public version of the Better Firmware Faster class April 3 in San Jose, CA. Here’s a chance to learn proven techniques that improve quality and shorten delivery times. See https://www.ganssle.com/classes.htm for more info.
I’ll be speaking at the Deep Agile 2009 event in Cambridge. Here are the details:
Deep Agile 2009: Agile for Embedded Systems
Date: April 25 - 26, 2009 (Saturday & Sunday)
Location: Cambridge, MA
Registration at http://www.agilebazaar.org/
I’m told there are still some sponsorship slots available for this event. Contact NancyV@LeanAgilePartners.com for details.
Quotes and Thoughts
From Geoff Patch: Programming can be fun, so can cryptography; however they should not be combined. Kreitzberg and Shneiderman
Tools
A friend pointed out a nice, free, tool that collects metrics from source code, including Cyclomatic Complexity: http://www.campwoodsw.com/sourcemonitor.html .
Visualizing ICs, Past and Present
The January/February issue of MIT’s Technology Review has a wonderful set of, well, images is the best word, of silicon die from a range of dates. Most are the traditional photomicrographs we expect when an a vendor announces their latest transistor-heavy wonder. But the very first image in the article is a two-page spread of Jack Kilby’s 1958 first-ever IC. I have never seen this in such detail before. The part has one transistor, a capacitor (!), and three resistors.
Then there’s a shot of a 1961 RTL logic device with four transistors. The caption claims it was used on the Apollo Guidance Computer, so might be a three-input NOR gate. However, the Wikipedia entry (http://en.wikipedia.org/wiki/Resistor-transistor_logic) shows that part had three transistors. As a teenager in the 60s I used many RTL devices, all from Fairchild’s uL900 family. They were packaged in odd 8 pin cylindrical epoxy gumdrops, rather resembling a miniaturized plastic version of a vacuum tube (“valve” to my British and Australian friends).
From there the article shows the increasing density of ICs via images of (this is best expressed in a table):
Part Year Transistor count
Kilby 1958 1
RTL gate 1961 4
8080 1974 5,000
8086 1978 29,000
68000 1979 68,000
386 1985 275,000
AMD386 1991 200,000
Pentium 1993 3,100,000
PPC601 1993 2,800,000
Pentium 4 2000 42,000,000
Core 2 Duo 2007 410,000,000
Core i7 2008 731,000,000
Phenom II 2009 758,000,000
The images show that there’s beauty in technology. Alas, the magazine isn’t on the web.
Responses to Computer Science Education
Quite a few people have written now about CS education and embedded systems. Here’s an except from comments by Edwin Decoene: “I always teach my kids to look around, that is ahead AND back. If managers of today once were embedded folks themselves, they should know that solving a problem is more than changing a few lines of code. They too need to look back from time to time (and hopefully learn from it).”
Jason Dougherty wrote: “I'm late to the comment party, but have to throw in my two cents on Comp. Sci. education. I wholeheartedly agree with what you wrote, and with most of the comments.
“It's certainly true that universities could do more to teach good software design and process (or even good coding practices for that matter). While we wouldn't want to turn them into technical colleges, universities should probably shift the balance between the broad theoretical and the practical more towards the latter. Some programs offer courses in software engineering, but students have to seek them out.
“However, companies share a lot of the blame here and aren't really in a position to criticize academia. In almost every interview I've had, I've been asked to write (or read) code. I can't recall the last time I was asked anything significant about software design. On the job the focus is often the same - producing code rather than designing first. This is analogous to a mechanical engineer grabbing a chunk of metal and heading out to the machine shop to cut a part. No one in their right mind would think that's a reasonable design process.
“I'm not sure how to change this prevailing view of software development. Perhaps the problem is a lack of understanding of software development among managers. Often it's perpetuated by EE's who know how to code (sort of) but not how to design. I often feel like I am swimming upstream in advocating for design before coding. I try to seek jobs with companies that seem to recognize the value of proper software design and hope I can prove it with results.”
Ed Sutter said: “I feel really strong about this stuff; and while colleges are definitely at fault here, so is the industry! The push toward "higher level programming" has replaced the push toward "learning from the bottom up".
“Its not just engineering, its in all aspects of life. While you'll always have those few who just like to work from the ground up, the majority, when given the chance will "start at the bash: prompt" (this could be extended to a metaphor for life) and call some sockets code "embedded programming".
“The bottom line is this...
“Engineering (to include firmware development), if taken seriously, IS HARD! In today's society, that unfortunately equates to unattractive. The only way to fix this, IMHO, is to somehow make hard work something that is attractive again. You can't sidestep around that fact, and we shouldn't be so quick to try to promote ways around it.”
Thomas Wick commented: “Your thoughts on firmware developers and EE degrees were very interesting. I have a degree in EE, taken many CS courses, and have worked in embedded development for 11 years. I have found that the best engineers are the ones that can solve problems, any problems, regardless of subject matter. Embedded system design is a series of decisions about tradeoffs on what a product is to contain and how it is to work. Firmware is the greatest accumulation of those decisions. This is because firmware tends to interface with many diverse knowledge domains: hardware, algorithms, system design, user interface, measurement techniques, complex mathematics. etc.
“I don’t think that hoping for recent grads to change the paths of corporate overlords is the only approach. Firmware developers are scattered all over the place. If a company has any, they are usually few and greatly outnumbered by the hardware and/or mechanical engineers. Worst yet, business managers could be directing their efforts. The firmware engineer has no voice, no organization to champion their causes. It is when industry leaders, like yourself, start to gather the ranks so that WE determine the true direction to produce quality firmware, that progress will be made.
“EE and CS professors need to teach the techniques and methods of disciplined development strategy. The firmware developers need to be open to changing the way they do things and to be brave enough to change the culture of their company. The Industry leaders need to give direction and gather momentum to make these changes a reality.”
Jobs!
Joke for the Week
I wish this was a joke. It’s a patent on the linked list:
http://www.google.com/patents?vid=USPAT7028023&id=Szh4AAAAEBAJ&dq=linked+list .