Embedded Muse 224 Copyright 2012 TGG April 16, 2012
You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at email@example.com.
EDITOR: Jack Ganssle, firstname.lastname@example.org
- Editor's Notes
- Quotes and Thoughts
- VDC Survey
- Responses to How Hard Are You Working?
- More on The Demise of Print
- Tools and Tips
- Joke for the Week
- About The Embedded Muse
Are you happy with your bug rates? If not, what are you doing about it? Are you asked to do more with less? Deliver faster, with more features? What action are you taking to achieve those goals?
In fact it IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm .
Quotes and Thoughts
"The object-oriented version of 'Spaghetti code' is, of course, 'Lasagna code' (too many layers)." - Roberto Waltman
Responses to How Hard Are You Working?
A number of people sent this link: https://www.alternet.org/2018/04/why-we-have-go-back-40-hour-work-week-keep-our-sanity/ . It's an analysis of why overtime can be problematic. One quote: "The other thing about knowledge workers is that they're exquisitely sensitive to even minor sleep loss. Research by the US military has shown that losing just one hour of sleep per night for a week will cause a level of cognitive degradation equivalent to a .10 blood alcohol level. Worse: most people who've fallen into this state typically have no idea of just how impaired they are. It's only when you look at the dramatically lower quality of their output that it shows up. Robinson writes: "If they came to work that drunk, we'd fire them -- we'd rightly see them as a manifest risk to our enterprise, our data, our capital equipment, us, and themselves. But we don't think twice about making an equivalent level of sleep deprivation a condition of continued employment.
"The Business Roundtable study found that after just eight 60-hour weeks, the fall-off in productivity is so marked that the average team would have actually gotten just as much done and been better off if they'd just stuck to a 40-hour week all along. And at 70- or 80-hour weeks, the fall-off happens even faster: at 80 hours, the break-even point is reached in just three weeks."
James Thayer wrote: "I'm heading in a slightly different direction than you were headed when you wrote this, but it does remind me of the time, not all that long ago, that my boss's boss (the president of the division) decided to stop by our lab in the evening and found no one there.
"The next morning, I got dumped on. He wanted to know:
a) Why I had not instilled in my team the importance of the deadlines that he had set (And as it happened, these deadlines _were_ incredibly important. And equally as impossible...but that's another story...)
b) Why it was, given that we had spent tens of millions equipping this lab, that I didn't understand that this equipment needed to be fully utilized.
"As it turned out, though, my team did understand the importance of the deadlines and the lab was heavily utilized even at that late hour.
"What my boss's boss did not understand was that the advent of internet protocols on embedded systems meant that one could usefully get work done without being in physical proximity to the equipment one was testing on. On top of that, we spent a lot of time running code in emulation on our workstations. Moreover, with secure tunneling protocols in place, some of my engineers would go home to dinner with their families and then put in a couple of hours working on target from their homes.
"My boss's boss had grown up in a time when engineers spent most of their time in the lab (as did I when I started out.) At the other end of my career though, the lab can be a pretty lonely place."
A reader who wishes to remain anonymous penned this: "Perhaps in the old days of the stay-at-home mom things were different. Dad could essentially shrug off all roles except that of breadwinner.
"I had a boss once whose wife still took care of most `inconvenient' things on his behalf -- sitting in the 2-hour long line for auto inspection, for instance -- and then got upset with me and other bachelor employees when we took a chunk out of the work to deal with the same stuff.
"Overall I'm probably working ~45 hours/week, and salaried so my only compensation for going over 40 is the occasional stock option or bonus. However, I wind up doing a lot of "flexing" with my hours. When I'm working from home (probably 70% of the time) I sometimes put in only 6 hours in a day and use the rest for various errands, but then I add in a few hours on the weekends. When I'm working from the main office (the other 30%) I often put in several 10 to 16 hour days in a row and rapidly make up any remaining shortage.
"It often seems that going out into the garden for a couple of hours when I'm stuck on a design problem brings new clarity of thought when I return, much like what the XPers talk about."
Jen wrote: "I'm working all the time. It's worse now that I have a regular W2 job instead of a consulting job. While I hated all the time keeping of consulting, at least if I worked overtime it was for a good reason and I was a touch richer as a result. I could see how the extra work impacted me in the net positive direction. I also felt I could turn down things as I saw fit.
"While I'm more effective an engineer and manager from the consulting world, it means that in a corporate environment, I'm really a technical manager and architect that gets the `opportunity' to do technical work a few minutes a day. I'm desperately trying to hire enough people on my one-person team to lessen the overall engineering and meeting load. Perhaps I'm doing it all wrong, but I'm finding most managers aren't equipped with much better than title and signing authority.
"In return for this chance, I get to add more stuff to my resume, a little more leniency to handle outside life, and more business travel which can be a blessing at times (who doesn't love visiting the food truck culture of other cities?!). But in terms of tangible benefits, it's pretty lean."
Charles Manning submitted this: "As the saying goes, you don't get overtime without corresponding under time.
"I have done a bit of overtime over the last many years, but seldom more than two or three days a week and never more than approx 10 hours per week.
"At one place I worked, it was pretty much the standard culture to pull an over-nighter at release times. One of these I remember clearly: I refused to play the game and knocked off at 6pm, but everyone else put in their orders for pizza and settled down for a long night. The next morning I came in early - 7:30 am - carrying a box of warm muffins. Our overnighter heroes were completely zonked out and could not carry out a coherent conversation - let alone write code. After a few muffins they all went home for a `short nap'. Only one came back that day and was so tired he did nothing. I was fresh and managed to get in a good day of work without any interruptions.
"I am pretty sure long hours at the desk are pointless."
Another anonymous reader wrote: "As an independent contractor working from my own location, it is difficult to look like I'm working hard if I only bill 22 hours per week because the rest of the time is dealing with administrivia, personal business, system administration, reading technical articles, continuing education, acquiring new contracts, etc. If I get 40 billable hours in, that means I've neglected a lot of other stuff."
Mike Skrtic's take is: "Interesting you should ask about work habits. I have a workaholic friend in counseling and on the way to divorce over his work habits. I too have a milder version of the same problem, but had a wise mentor/CEO who 15 years ago ordered me to stop. I was given a 50 hour per week max limit, and the words "Mike, you're a valuable asset to this company, and being burned out is no good to us. If it can't be done in 50 hours per week, you need to re-evaluate what you are doing or how you are doing it." I spent 2 months walking around feeling very frustrated because "he won't let me do my job", and I began to re-evaluate my work habits.
"One of the tools which has helped me considerably is a time program which we log in and out of at work - an electronic punch clock. We used to call it the Gestapo Program, but when I changed my perspective from the company watching over my shoulder to this is a tool to help me manage my work habits it has become a good friend. When I check my e-mail in the mornings before work, before my family is awake, I log in for a half hour; spend some time over the weekend documenting a good idea - log in for 45 minutes. You get the idea. The extra hours go into a flex time pool which I can draw on for a variety of family needs and activities. The company also has a policy regarding the flex time pool - it is allowed to go to plus 100 hours, and minus 20 hours. And this is enforced by HR. It's a pretty good system."
And there's this from Geoff Patch: "Your article in EM 223 regarding working hours was very timely.
"We just took on a new engineer yesterday. He has about 5 years experience with a large multinational defense company, and one of his first comments when I spoke to him was that everybody in the team here seemed so relaxed, compared to where he'd worked previously. This was obviously very pleasing for me.
"He said that his previous employer had regularly required that he and his colleagues engage in death marches as project deadlines came closer. These typically involved 4-6 weeks of 50-60 hour weeks followed by a brief respite and then more of the same. He said that this resulted in a work environment full of almost permanently tired, anxious and irritable people, which was not pleasant and not sustainable. It certainly wasn't sustainable for him, because he left and came here.
"My view is that crunches near project deadlines are a sign of poor management and poor engineering process (e.g. estimation), and should be avoided at all costs in order to preserve product quality and staff morale. Paying people for 40 hours per week and requiring them to work 60 hours is simply exploitation, and it quickly results in unhappy staff and increased defect rates. This leads to increased staff turnover with its huge associated costs.
"Any organisation that deliberately engages in business practices that directly result in reduced quality, loss of staff and increased costs won't be in business for long in these difficult times."
More on the Demise of Print
Kevin Clark wrote: "Why do I prefer print magazines over E-zines?
"Next year or ten years from now, or fifty years hence, the print magazine will still be readable and usable, and useful. I can mark it up, or cut it up and file it, or scrapbook it. I can look up references to previous issues by digging up the back issue. My alma mater's library has miles of racks of back issues of thousands of magazines going back 100 years. In my formative years, it was a tremendous learning resource. They say that nothing is ever truly deleted on the Internet, but that seems to apply only to embarrassing posts and pictures, not magazine articles. Science journal articles I can read at the local university library for free are often available on-line only on a subscription or pay basis for $10-$50 per article, (not even per issue).
"The e-zines which I get today almost always have at least one bad link, and it's always the one I'm interested in. And those are often internal links for their own back issues.
"The delivery format of E-zines has changed over the years. PDF is down-loadable, and fairly stable, HTML is neither. Several years ago, proprietary formats were used. Even now many e-readers and PDAs use proprietary formats. Have those formats been converted to PDF, or are they lost forever? Can I cut a single article out of a 10MB PDF file and save only that? Some PDF's are even "protected" against printing, and often the PDF pictures are limited in resolution, even compared to a print magazine.
"The Google Books project has digitized millions of books and magazines, and they have searchable text, but are often not available for viewing due to copyright issues, and those that are seem to be designed to prevent downloading or even printing for offline perusal.
"Yes, digital content is searchable, although most online search engines are a joke, having no (obvious) wildcard or Boolean search capabilities, and each one working differently from the others, using their own inscrutable logic to deliver a range of pages from totally relevant to totally irrelevant.
"What it boils down to is durability, stability, accessibility, usability."
Tony Mactutis had a different thought on learning and trade magazines: "On another note, I wanted to comment on something related to your thread on trade magazines. Something I try to do every year to keep my skills growing is to take a college-level technical course. I have found that the online courses offered by Columbia University to be excellent. Besides engineering, they offer online courses in math, physics, materials science and many other topics that we might have like to have taken while at college but did not have time (or whose usefulness we did not foresee).
"It costs about $2k to audit a course, and my bosses have always been more than willing to pay for them. Some of them have even allowed me to do the coursework on company time! The courses can be taken for credit but I prefer to audit. However I still take notes and try to keep up with the homework."
Tools and Tips
You can never have too many power supplies, but they can get pricey. I found a cheap one some time ago that is pretty decent. It's the Mastech HY1803D which costs about $80 at Amazon, but Kits USA (I have never purchased from them so have no info about their business practices) sells it for $58.
The HY1803D is a single output supply with a range of 0 to 18V at up to 3 amps. It has an adjustable current limit and digital meters for volts and amps.
One small problem: the readings on the voltmeter are sometimes affected by radiated noise in the system being powered. The numbers bounce around a few tenths. I've only seen this with high-speed systems (sub-nanosecond switching rates). Decoupling at the banana posts doesn't help. But the output voltage remains stable.
And, the holes in the banana posts through which you can insert a wire are oriented randomly. That means you have to peer awkwardly around the post to figure out where to put the wire. I marked their location with a sharpie.
Let me know if you're hiring firmware or embedded designers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words.
Joke for the Week
Note: These jokes are archived at www.ganssle.com/jokes.htm.TASK - To Shoot Yourself In The Foot
You shoot yourself in the foot.
You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me over there."
You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you have no exception handling ability.
USE HANDGUN.COLT(45), AIM AT LEG.FOOT, THEN WITH ARM.HAND.FINGER ON HANDGUN.COLT(TRIGGER) PERFORM.SQUEEZE RETURN HANDGUN.COLT(45) TO HIP.HOLSTER.
You shoot yourself in the appendage which holds the gun with
which you shoot yourself in the appendage which holds the gun with
which you shoot yourself in the appendage which holds the gun with
which you shoot yourself in the appendage which holds the gun with
which you shoot yourself in the appendage which holds the gun with
which you shoot yourself in the appendage which holds...
You shoot yourself in the foot with a water pistol until your foot is waterlogged and rots off.
You shoot yourself in the foot with a BB using a SCUD missile launcher.
Foot in yourself shoot.
You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.
The compiler won't let you shoot yourself in the foot.
If you succeed, shoot yourself in the left foot. If you fail, shoot yourself in the right foot.
You shoot yourself in somebody else's foot.
Put the first bullet of the gun into the foot left of leg of you. Answer the result.
You spend days writing a UIL description of your foot, the trajectory, the bullet, and the intricate scrollwork on the ivory handles of the gun. When you finally get around to pulling the trigger, the gun jams.
Unix % ls foot.c foot.h foot.o toe.c toe.o % rm * .o rm: .o: No such file or directory % ls %
Shooting yourself is no problem. If you want to shoot yourself in the foot, you'll have to use Clipper.
Not only can you shoot yourself in the foot, your users can, too.
You'll be able to shoot yourself in the foot just as soon as you figure out what all these bullets are for.
You'll really only appear to have shot yourself in the foot, but you'll have had so much fun doing it that you won't care.
You tell your program that you want to be shot in the foot. The program figures out how to do it, but the syntax doesn't permit it to explain it to you.
You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot. Three years later, your foot comes back deep-fried.
We'll let you shoot yourself, but it'll cost you a bundle.
You insert a clip into the gun, wait half an hour, and it goes off in random directions. If a bullet hits your foot, you're lucky.
Object "Foot" will be included in the next release. You can upgrade for $500.
I knew you were going to shoot yourself in the foot.
You can use this machine-gun to shoot yourself in the foot, but the firing pin is broken.
We don't sell guns anymore, just ammunition.
Just as soon as Solaris gets here, you can shoot yourself anywhere you want.
After correctly packing your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot. When you try, however, you discover you can't because your foot is of the wrong type.
You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.
You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.
After realizing that you can't actually accomplish anything in this language, you shoot yourself in the head.
After searching the manual until your foot falls asleep, you shoot the computer and switch to C.
You buy a gun. Bullets are only available from another company and are promised to work so you buy them. Then you find out that the next version of the gun is the one that is scheduled to actually shoot bullets.
After consuming all system resources including bullets, the data processing department doubles its size, acquires 2 new mainframes and drops the original on your foot.
Smalltalk, Actor, et al
After playing with the graphics for 3 weeks, the programming manager shoots you in the head.
HTML <a target="http://body/lower-half/leg/foot.appendage">Shoot here</a>
The gun fires just fine, but your foot can't figure out what the bullets are and ignores them.
You ask a wizard for a pair of hands. After lovingly handcrafting the gun and each bullet, you tell everyone that you've shot yourself in the foot.
You daydream repeatedly about shooting yourself in the foot.
FTP % ftp lower-body.me.org ftp> cd /foot ftp> put bullets
You manage to shoot yourself in the foot, but while doing so you also shoot yourself in the arm, stomach, and leg, plus you shoot your best friend in the chest, the neighbor's dog and your car. A month later you're not able to understand your program anymore when you read the source.
About The Embedded Muse
The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at email@example.com.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.