For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.
By Jack Ganssle
Anyone Can Do It
The article "Embedded Developers Do Some Soul Searching" (http://www.embedded.com/showArticle.jhtml?articleID=21700389) describes how mechanical engineers at Adidas made a new type of smart shoe.
"Adidas engineers said creation of the software algorithms was among the most complex challenges, in part because the design team consisted of mechanical engineers who had scant programming experience. Thus the team went back to school, signing up for a course in programming Microchip's PIC16F88 MCU."
"We didn't have much choice," DiBenedetto said. "We flew to Chicago, took classes and started writing code."
I'm sure this is a cool product, and salute the engineers for creating something so complex. But at the risk of sounding elitist, the story sends goose bumps down my spine.
Programming is a specialized discipline. Many people can crank code - heck, even teenagers manage to infest the `net with their evil creations. But it takes years - not weeks - of training to learn how to build great code.
I can use an X-Acto knife to perform minor surgery, say to remove a splinter. But only a fool would attempt an appendectomy without years of specialized training.
An EE like your or I might build a treehouse for the kids in the backyard. But we need civil engineers to do a skyscraper's loads analysis.
One of the great ideas behind Dartmouth Basic was to popularize programming. Practically anyone could create simple chunks of code that did useful things. We quickly learned, though, that most of that software was awful. It might work, sort of, but was typically neither reliable nor maintainable.
The PC changed all of the rules of computers. Everyone has one their desks. We all have at least some sort of programming tools at hand, whether Excel macros or scripting agents. These tools bring great power to the average user and are a Good Thing.
But sometimes they create the perception that it's easy to create programs. A 5 line macro or 100k LOC embedded system - what's the difference?
In my opinion one of the great problems in our business today is an undercurrent that we're not really professionals. "Let `em crank some code," the boss intones. "Don't have any CS people? Give those mechanical and chemical engineers a few days of classes and let them help."
But with a few days, or even years, of training I can guarantee that I'd be an incompetent nuclear engineer. There's no way I'd be able to do the vibrational analysis of a spacecraft, or design a refinery. Those people are experts.
As are we.
A great deal of skill goes into building extensible, maintainable and reliable software.
So maybe the reason there are so many buggy apps out there is that we're not using the highly trained professional software folks on these projects.
Some might say the Adidas people were only designing a simple shoe. It's probably not an application that will grow and evolve much.
But an expert software person knows that nearly all software is organic. The programmer black-belt has seen a dozen jobs, all promised to be throw-away prototypes or simple apps never requiring support that turned into major product lines. A decade later the same code is still being improved and shipped, and has now been ported into many other products.
As long as the software community is viewed as a set of interchangeable cogs, fungible assets easily replaced by a co-op student or the secretarial staff, we'll be saddled with buggy, unmaintainable code.
I work with embedded developers all over the world, and see projects of all stripes, from brilliant successes to those dismal failures which destroy jobs and companies. I've observed that despite years of training and experience at this work, many of us are in desperate need of even more book- and experiential-training in the field. This is not simple stuff.
What do you think? Are we experts who apply years of knowledge to solve problems in a clean and extensible fashion? Or can someone with a quick class or two replace us?