Follow @jack_ganssle

Embedded Muse 176 Copyright 2009 TGG March 2, 2009


You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@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
- Naming Conventions
- Book Review
- 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 http://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.


How about a two-fer? I’m presenting a public version of the Better Firmware Faster class April 3 in San Jose, CA. Come to the Embedded Systems Conference that week AND join me for a day to learn my approach to crafting world-class systems in less time. See http://www.ganssle.com/classes.htm for more info. It’s right off the light rail line and there’s plenty of free parking.


The Embedded Systems Conference folks have offered a 25% discount to Muse readers. Use priority code CTPM15 to get the discount when you register.


I’ll be speaking at the Deep Agile 2009 event in Cambridge, MA. Here are the details:
Deep Agile 2009: Agile for Embedded Systems
Date: April 25 - 26, 2009 (Saturday & Sunday)
Registration at http://www.agilebazaar.org/


In the last issue I mentioned an article in Technology Review which featured pictures of different historical ICs. Numerous readers sent in the URL, which wasn’t available when I wrote the piece: http://www.technologyreview.com/article/21886/ . It’s really worth checking out.


Quotes and Thoughts


Harold Kraus sent this: From "A Beautiful Obsession with the Binary World" By Steven Levy . "Debugging is like laying a long railroad track," says John Levy, a software manager for Apple Computers. "There's a little piece you want to test, so you back up the locomotive five miles down the road and at ninety miles an hour, you bring it across the track you're testing. If everything is perfect, it flies right over, but if there's one flaw, the engine rolls off, flying and crashing until it comes to rest a mile down the track. Only at that point do you get to see the pieces."


Tools


Marc Verwerft wrote: “Too bad that the tool listed (http://www.campwoodsw.com/sourcemonitor.html) is only available under windows. There is something comparable to this for Unix/Linux also: http://www.dwheeler.com/sloccount/sloccount.html
The site belongs to David Wheeler, a man with a good reputation on security and Linux in general. Lots of interesting things to find there. One of the programs he wrote is SLOCcount, that 'converts' a project into effort: it first measures your project in terms of number of lines of code and then applies rules that finally come up with an estimate of how much your project will cost (either in terms of money or effort).”


Naming Conventions


Street addresses make no sense.

Why do we label an envelope:
2000 Lakeshore Drive
New Orleans, LA

That’s exactly the opposite of how the post office sorts the mail. A better form is:

LA, New Orleans, Lakeshore Drive, 2000

That’s written from the big to the small. Start with the general – the State – and work to the specific – the street number.

Linnaeus taught us how to name species. We start with the genus, the general form of the entity, and end with the species. Part of the Linnaean taxonomy for people-like creatures is thus:
Homo habilis
Homo rudolfensis
Homo erectus
Homo floresiensis
Homo neanderthalensis
Homo rhodesiensis
Homo sapiens

The same holds true in creating names for variables and functions. Start with the big and work to the small. It’s the galaxy, then the solar system, the planet, the continent, country, state and street.

So here’s a lousy name: read_timer(). Sort the names in your program and you’ll find:
read_keyboard()
read_timer()
read_USB()

… all grouped together, yet these are completely unrelated. Start with the general: the device’s name. Then work to the more specific.

Much better: timer_read(). Now a sort will yield:
timer_initialize()
timer_ISR()
timer_read()
timer_write()

Functions generally do something, so I think it makes sense to include an action word, a verb, in the name. Avoid weak verbs like “handle” and “process.” Neither tells the reader what the function does. But there are exceptions: note the name “timer_ISR()” above. In this case everyone knows what an ISR does, so there’s no confusion.

Clarity is our goal.


Book Review


Paul Carpenter wrote regarding my review of Lisa Simone’s book “If I Only Changed the Software, Why is the Phone on Fire?” He made the comment that the book’s title should be "Josie Croft, The Code Raider!” (One of the characters is Josie, and that’s her mission in the book).


Responses to Computer Science Education


Michael Pont, of the University of Leicester and TTE Systems, wrote: “We often (at least in the UK) see MSc students in engineering / CS (E/CS) come straight from an undergraduate degree. In my experience, it's often difficult to teach software engineering concepts to such students (until they've worked on big systems, experienced direct customer feedback and seen the economic consequences of missed deadlines, many students simply "glaze over" when presented with "high level" problems). If they were trying to study for an MBA, this problem wouldn't arise (MBA admission usually depends - again in the UK - on an ability to demonstrate that you have some battle scars and will, therefore, be able to place the teaching in context).

“One solution I've found to these problems is part-time MSc programmes, which are aimed sharply at working - experienced - engineers. Our latest version (which I think is pretty good) is summarised here:
http://www.tte-systems.com/services/training/msc .”


Jobs!


Joke for the Week


From Tjark van Dijk:

If IBM made toasters...
They would want one big toaster where people bring bread to be submitted for overnight toasting. IBM would claim a worldwide market for five, maybe six toasters.

If Xerox made toasters...
You could toast one-sided or double-sided. Successive slices would get
lighter and lighter. The toaster would jam your bread for you.

If Radio Shack made toasters...
The staff would sell you a toaster, but not know anything about it. Or you could buy all the parts to build your own toaster.

If Oracle made toasters...
They'd claim their toaster was compatible with all brands and styles of bread, but when you got it home you'd discover the Bagel Engine was still in development, the Croissant Extension was three years away, and that indeed the whole appliance was just blowing smoke.

If Sun made toasters...
The toast would burn often, but you could get a really good cuppa Java.

Does DEC still make toasters?...
They made good toasters in the '80s, didn't they?

If Tandem made toasters...
You could make toast 24 hours a day, and if a piece got burned the toaster would automatically toast you a new one.

If Thinking Machines made toasters...
You would be able to toast 64,000 pieces of bread at the same time.

If Cray made toasters...
They would cost $16 million but would be faster than any other single-slice toaster in the world.

If The Rand Corporation made toasters...
It would be a large, perfectly smooth and seamless black cube. Every morning there would be a piece of toast on top of it. Their service department would have an unlisted phone number, and the blueprints for the box would be highly classified government documents. The X-Files would have an episode about it.

If the NSA made toasters...
Your toaster would have a secret trap door that only the NSA could access in case they needed to get at your toast for reasons of national security.

If Sony made toasters...
The ToastMan, which would be barely larger than the single piece of bread it is meant to toast, can be conveniently attached to your belt.

If Timex made toasters...
They would be cheap and small quartz-crystal wrist toasters that take a licking and keep on toasting.

If Fisher Price made toasters...
"Baby's First Toaster" would have a hand-crank that you turn to toast the bread that pops up like a Jack-in-the-box.

If the Franklin Mint made toasters...
Every month, you would receive another lovely hand-crafted piece of your authentic hand-crafted Civil War pewter toaster.

If CostCo made toasters...
They'd be really cheap, as long as you bought a six-pack of 'em.

If Microsoft made toasters...
Every time you bought a loaf of bread, you would have to buy a toaster. You wouldn't have to take the toaster, but you'd still have to pay for it anyway. Toaster'95 would weigh 15000 pounds (hence requiring a reinforced steel countertop), draw enough electricity to power a small city, take up 95% of the space in your kitchen, would claim to be the first toaster that lets you control how light or dark you want your toast to be, and would secretly interrogate your other appliances to find out who made them. Everyone would hate Microsoft toasters, but nonetheless would buy them since most of the good bread only works with their toasters.

If Apple made toasters...
It would do everything the Microsoft toaster does, but 5 years earlier.