Follow @jack_ganssle

ESC Boston - Hope and Change

Summary: The old ways of developing embedded systems just don't scale. ESC Boston is the place to go to learn better approaches.

Forty years ago Intel invented the microprocessor, but few knew what to use it for. Companies quickly realized how adding a bit of intelligence to their products reduced costs and increased functionality. The embedded systems industry was born.

I was in college, working as an electronics tech at a small outfit named Neotec, but was the only employee at the company who knew anything about programming. They tapped me to be their first in-house firmware developer. Though it was easy to master the assembly language, my software engineering skills were null. This was typical of the industry. All early embedded people had been trained as EEs, not computer scientists. 30 years of lessons learned in the software business were ignored by this fledgling industry.

Programs were small and management clueless about software projects. But the 8008 had a max address space of 16k so hacking was reasonably effective.

Projects grew in pace with expanding address spaces offered by better processors as they came out. Customers wanted more features in the products we built, and we reacted in the usual manner. Hired more people. Worked longer hours. Made promises we never fulfilled. And, of course, shipped plenty of bug fixes to irate customers.

I eventually left and started a consultancy with a partner. What a ride we had! What fun it was to put our gear in, say, a steel mill with a hundred foot long piece of 2000 degree steel four inches thick moving at a breakneck pace. Or systems that lived 10,000 feet deep in the ocean, running on a few AAs for a year. Then there was the White House security system which we designed and installed during the Reagan years. When the project was done they pulled my White House badge the same day Ollie North lost his.

After too many late nights we started to sense that there were better approaches than our usual heroics. But what was wrong with us? Why were we working so hard?

Then I started an in-circuit emulator company. Now providing tech support to embedded developers all over the world I discovered something interesting. ALL of us had the same problems. Little groups of engineers all used heroics, and nearly all delivered late. Ironically, it seems we who invented the communications age didn't talk to each other. So we all faced the same sorts of challenges, thinking that we were doing something wrong and that other teams had the secrets to success.

I studied software engineering. The field, all but ignored by firmware folks, had a great body of accumulated wisdom. Frustrated with the state of our practices, in 1988 I started writing for various electronics/embedded publications about technical issues and better ways to develop code.

Over the years I've served on the board of a technical college and taught engineering at another university. In those cases it was shocking to see that schools push the same old dysfunctional software methods: here's how a "for" loop works. Now write some code.

A couple of companies asked me to come in and provide training about firmware development. Well, high school speech class was a trauma. I was terrified of talking in front of anyone, a fear that persisted into my 30s. But as a personal challenge I had decided to get over this irrational dread and took some speaking classes, and then practiced. When the Embedded Systems Conference was born they asked me to give a talk. and I found it an exhilarating experience. What fun to interact with all of these very smart people! It seemed natural to develop a seminar that would help folks get better code faster. (I'm presenting a public version of my Better Firmware Faster seminar in Chicago and London next month - see http://www.ganssle.com/classes.htm ).

No one is načve enough to think there's a silver bullet that will solve all our problems. This field is intrinsically tough. Even if we knew how to generate 10 million lines of perfect code in a day, customers will scream to shorten the schedule to an hour.

But it is possible to create better code faster. It is possible to drastically reduce bug rates and shorten schedules.

That's what the Embedded Systems Conference is all about. The show has grown and morphed, but it's still simply a mechanism to deliver maximum information to embedded engineers. There's the show floor where over 100 vendors will push their wares. We engineers need to know what is commercially available that can aid our work. Access to this "expo" is free.

The conference program, which isn't free, is where over 100 talks by experts will teach you all facets of embedded design. Thinking about using Android? A series of classes will take you from rank novice to journeyman (or journeywoman).

There are about 30 sponsored sessions, which means a vendor has paid to deliver content. Sure, the info will be biased towards a product, but most give the hard-hitting advice engineers need. And these are free as well.

Want a free scope? Tektronix and LeCroy have contests for four. I have not tried the LeCroy, but did review (http://www.ganssle.com/misc/tek2024.html) Tek's MSO2024 and found it to be quite impressive.

Part of professionalism is being connected with one's field, and the ESC is the one venue for those of us build embedded systems. I hope to see you there!

There's more info here: http://esc.eetimes.com/boston.

Published September 7, 2011