Embedded Muse 113 Copyright 2005 TGG March 21, 2005
You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
EDITOR: Jack Ganssle, firstname.lastname@example.org
- Editor’s Notes
- Computer Magazines
- Code Guardians
- Joke for the Week
- About The Embedded Muse
Want to increase your team’s productivity? Reduce bugs? Meet deadlines? Take my one day Better Firmware Faster seminar. You’ll learn how to estimate a schedule accurately, thwart schedule-killing bugs, manage reuse, build predictable real-time code, better ways to deal with uniquely embedded problems like reentrancy, heaps, stacks and hardware drivers, and much, much more.
I’m presenting this:
- Austin, TX on April 18
- Baltimore, MD on April 20
Want to be your company’s embedded guru? Join us! There’s more info at http://www.ganssle.com/classes.htm, including cheap flights to these cities from around the USA.
If your outfit has a dozen or more engineers who can benefit from this training I can present the seminar on-site. See http://www.ganssle.com/brochure%20-%20onsitenew.pdf .
Information Week has good news (http://www.informationweek.com/showArticle.jhtml?articleID=160403526 ). While in the last year US unemployment dropped to 5.2% from 6.0% a year earlier, the IT business faired much better. It dropped to 3.7% from 5.5% last year. Employment is still 82,000 jobs short of the record high in 2002. It’s not at all clear if the embedded industry falls into the “IT” figures, though.
Another article (http://www.dailycamera.com/bdc/cda/article_print/0,1983,BDC_2463_3627534_ARTICLE-DETAIL-PRINT,00.html ) claims that enrollment of computer science students is off 28% from 2000. Prospective students are afraid of offshoring, of course, and have realized that the sky-high dot-com salaries were a fluke.
Adam Dunkels has created some really cool software for small embedded systems. His Protothreads are an alternative to RTOSes, and eat only two bytes of RAM per thread. From his site: “Protothreads are extremely lightweight stackless threads designed for severely memory constrained systems such as small embedded systems or sensor network nodes. Protothreads provide linear code execution for event-driven systems implemented in C. Protothreads can be used with or without an underlying operating system.” See http://www.sics.se/~adam/pt .
His uIP TCP/IP stack needs only 4-5k of program space and a couple hundred bytes of RAM. See http://www.sics.se/~adam/uip/ .
Both packages are free under a BSD-style license.
Last issue I listed a number of computer magazines suitable for embedded developers. Readers wrote in with additional suggestions.
Jan Axelson wrote:
Two other hobby magazines are Nuts & Volts and Servo, both from T & L Publications.
Nuts & Volts started out as a newsprint shopper filled with ads, but has evolved into what Popular Electronics was years ago. Overall, the articles are at a lower/easier level than Circuit Cellar. There's lots on PICMicros and Basic Stamps.
Servo is similar but with a focus on robots.
From Nathan Sherman:
I have added 2600 Magazine (The Hacker Quarterly) to my list (http://www.2600.com). While somewhat random, this community of hackers exposes some very interesting bugs in a wide variety of mostly embedded applications, since Windows/Linux is so well covered elsewhere...
Look at "Elektronik" for example: http://www.elektroniknet.de/ , and its sibling magazines. Wonderful papers! I grab them every time I visit a trade show in Germany.
Surviving IT Project Cancellations
The April, 2005 issue of the Communications of the ACM contains an article by Charalambos Iacovou and Albert Dexter about surviving project cancellations.
It starts off with a quote from a Forbes article where an investment banker mentions he likes to hire former athletes. Not to improve his golf swing, but because when things go wrong athletes recover rapidly. They’re trained to analyze failure and benefit from the experience. If only we were so well disciplined!
Here are the authors’ 18 recommendations for dealing with a failed software project:
1) Prepare a communications plan
2) Perform a post-mortem audit
3) Form a contingency plan jointly with the sponsor
4) Modify the current development process to reflect lessons learned
5) Reflect on your own role and responsibilities
6) Ensure continuity of service
7) Provide staff counseling and appropriate new assignments
8) Learn from mistakes
9) Review related project decisions and long-range plans
10) Determine responsibility of vendors
11) Improve risk management program
12) Salvage useful parts of cancelled project
13) Document project details to preserve corporate memory
14) Conduct detailed individual staff evaluations
15) Hire an outside project manager to oversee replacement project
16) Secure project materials and assets
17) Use your influence to start a replacement project
18) Be prepared to face the consequences
While one may disagree with some of these practices, and certainly their relative priorities, there is much wisdom here.
But most of the items are appropriate for any project. I recommend item 2, conducting a post-mortem, for any significant engineering effort. It’s the scientific acquisition of knowledge and experience, rather than the usual haphazard and somewhat ineffective kind.
Item 5 is essentially introspection, a critical attribute for all of us in all facets of our lives. When my son started to drive I asked him to stop every few months and think about his actions behind the wheel. Ask questions like “am I tailgating? Speeding? Rude?”
Some sort of entropic-like force makes us all drift to lazy and even dangerous behaviors, in our driving, in our relationships, and in the way we develop systems. Stop and think from time to time. Reflect on your practices. Have you started taking shortcuts? Identify the problems before they become hard-to-change habits, and take some action.
The nuns of St. Camillus pounded all sorts of interesting ideas into the heads of myself and my grade school pals. Some will no doubt come out in the inevitable therapy sessions I’ll need as my kids crash trhough teenagerhood. Others, though scary at the time, make for good stories today.
“Guardian Angels” were the nuns’ invisible avatars, always watching over us, often helping us, sometimes recording black marks in that cosmic book of personal errors. No doubt my guardian angel is a UNIX guru, working full time just to keep the sheer volume of my black marks from crashing all of heaven’s database engines. “Reboot heaven? Y/N?”
The nuns neglected to tell us we’re each others guardian angels. Parents watch over their kids with a wary eye no supernatural creature can match. Spouses look out for each other’s interests. Friends in need find friends indeed.
These thoughts bubbled to the surface when I asked an engineer to recode a few functions in assembly language. The system worked great but just seemed a bit slow. Some analysis turned up a busy interrupt service routine, supported by a couple of equally stressed main-line subroutines.
I wasn’t looking for much speed - a 20 or 30% improvement was more than enough to give the system a snappy feel. Why not translate a bit of code to assembly and be done with the problem?
The engineer’s boss collared me, and in no uncertain terms said “No!” Though he knew that the translation would work, he figured the resulting assembly language - the only non-C code in the system - would reduce the system’s maintainability.
He is the system’s code guardian. As such he has the authority – and the common sense – to ensure we don’t do dumb things that erode any aspect of the software, software we’ve invested in in a big way. Though I might disagree with his approach, he watches over his code like a parent over children. He protects it from the whims of marketing types, and from expedient solutions like mine.
The code guardian is the quality angel. When a dozen approaches will all work, the code guardian selects one that most closely meets the needs of the customer, yet that preserves the software’s integrity.
Every project needs a code guardian. Usually this should be the team’s highest-ranking technical person, someone with the authority to say “This stinks! We’re not going to do it this way!” The code guardian needs the freedom to do work management might consider non-productive, like instituting version control systems, developing and maintaining software standards, and sometimes rejecting working routines that just don’t measure up to his demanding standards.
It’s hard to chuck working code. Sometimes it’s simply the right thing to do.
The role of the code guardian, of course, is to protect the software from outsiders (marketing) as well as from the developers themselves. Most projects start with the best of intentions: Code reviews, structure charts, careful design are our mantra when delivery is a year away. After a few schedule slips, with the deadline looming, it’s all too easy to abandon a reasonable methodology in our panic to get a product out the door. The code guardian has got to institute a discipline of methodology. He or she becomes the code Gestapo as the crunch hits, insuring that things are done right. Bad code always comes back to haunt us.
Joke for the Week
Cenqua Corporation added a couple of very amusing pages to their site for April 1. One pseudo product they’re, well, not pitching is the Commentator, which writes your comments for you. From the site: “Day in, day out, you pull off star moves: gnarly algorithms, wicked refactorings, stunning optimizations. Why should you stop and explain? Yes, you've got plodders on your team, but hey — YouAreAStar and YourTimeIsExpensive. Time spent explaining, documenting, commenting — dude! — that's time you could be using to crank out yet more mind-altering code.”
Check it out at http://www.cenqua.com/commentator. The screen shot and code snippets are priceless.
And then take the link (http://www.cenqua.com/pairon ) to their PairOn chair, designed expressly for, as they put it, Extreme XP programmers. It’s a hoot.