Embedded Muse 151 Copyright 2007 TGG October 31, 2007

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- The Future of Engineering
- Estimating Schedules
- Yet More on Open Spaces
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

Are you in the Seattle or Minneapolis area? For the first time I’ll present a public version of the Better Firmware Faster class in Minneapolis and Seattle, on December 5th and 7th. Sign up before Nov. 5th, and receive a $50.00 discount. Registration and other info here: https://www.ganssle.com/classes.htm . You’ll earn 0.7 Continuing Education Units, learn a lot, and have more than a little fun.

Bill Gatliff pointed out that he has published information about implementing the Blowfish encryption algorithm here: http://www.embedded.com/columns/technicalinsights/12800442?_requestid=174738

In response to my comments on consulting, both here and on embedded.com, Vladimir Vassilevsky wrote: “I work as an independent consultant since 2001. This book was a great help when we started: Harvey Kaye. "Inside the technical consulting business." I recommend this book to anyone who is interested in the consulting as a career.”

Numerous readers pointed out this article http://www.spectrum.ieee.org/oct07/5598 , which is an interesting analysis of recent computer problems on the space station. For those in a hurry here’s the spoiler: software wasn’t to blame.

The Future of Engineering

At the same time our salaries are skyrocketing: http://www.businessweek.com/smallbiz/content/oct2007/sb20071025_827398.htm?chan=top+news_top+news+index_top+story .

Yet other data, some from the IEEE and ACM, show a negative bubble in these subjects in college. Engineers are, they claim, switching to less-difficult majors in droves.

Frankly, I don’t know what to believe anymore, as so many articles make so many conflicting statements. The relatively recent advent of rampant offshoring has created an enormous amount of FUD that various experts, some with their own agendas, have been quick to exploit. So we’re left confused by all of the differing claims. It is clear, though, that this profession is changing rapidly. It’s a global enterprise. Companies are anxious to reduce costs (except for non-performing CEOs, but that’s another story). Yet the demand for embedded products continues to grow.

In the last two months I’ve traveled nearly 100,000 miles visiting developers all over the world. This much I know is true (to steal the title from Wally Lamb’s wonderful book): The engineers I met in India are excited and engaged in their profession. As are the ones in Asia and the rest of the developing world. Some of these groups have enormous resources. A couple of engineers were somewhat apologetic when I asked about their team sizes, answering that, well, their teams are pretty small, only 400-800 people on a project. The work is flowing around the world, a trend that will only increase as the developing world develops. It won’t be long before China starts providing a staggeringly-huge pool of engineers.

Estimating Schedules

His method only works if developers carefully track actual data, logging just how much time was spent on each scheduled activity. That’s really good advice, though it’s rarely followed.

Data suggests the average developer is engaged on a particular project about 55% of the time (using agile approaches the number is more like 66%). Random interruptions, that meeting about the health insurance plan, and the like, consume something like 18 of the 40 hours in a week. EBS ignores this, folding those distractions into the time spent actually doing a particular scheduled item. That may work, but I prefer to track those interruptions separately. It’s powerful data to give your boss to show where the time is really going.

I recently reviewed a few books about scheduling: http://embedded.com/columns/breakpoint/201803531 .

On an unrelated note, an engineer recently referred me to another of Joel’s posts that I had somehow missed: http://www.joelonsoftware.com/articles/fog0000000043.html . It’s Joel’s test of a healthy software organization. Do read the article, but he believes we should all be able to answer “yes” to these questions:

- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?

I’m a bit unconvinced about the last question for most embedded apps, but these others are spot-on.

Yet More on Open Spaces

Michael Covington wrote: ”About open workspaces...I do a lot of reading and writing at big tables in the University library. I find it easy to actively ignore people's whispering and other noises, even up to the level of conversational speech, if I can see where they are and know they aren't trying to get my attention. I sit facing into the room so that every source of noise is visible.

”If the noise were behind my back or -- worse -- hidden by a partition, it would be much more distracting because I wouldn't be able to confirm, with a quick glance, that it didn't require my attention.”

Todd Hayes contributed: ”The discussion on open work spaces has been an interesting one to follow. I have been interested in this for years and have had several discussions with my manager about what we thought would be best. Here are a few of my insights that you might want to add to the mix:

”The group I work in now has 3 walls for each cubicle. They provide a place to hang shelves more than they provide privacy. I found myself getting sucked into discussions other engineers were having quite often. Far more often than not, it turned out to be quite productive to debate the immediate issue with them and resolve it on the spot.

”At other times, we would ask questions and spout replies without moving from our seats. I found these interruptions hardly disruptive when I was asked simple questions. I also found the quick answer from a coworker to be extremely productive for me when I was the one doing the asking. Sometimes, a third person would chime in with a very important correction or caveat about the issue.

”When I look back over the projects I worked on throughout the years, it seems to me that the interruptions were important. Although they derailed what I was working on at that instant, they would usually head off far more work by one or more others. It is my firm belief that the openness our environment provides allowed the overall project to move ahead faster and more cohesively compared to when I was given a more private place to work. It was frustrating at times to not be able to complete a straightforward piece of code for all the interruptions, but that is ok. Other engineers were collectively able to make more progress than I lost because I took the time to help.

”I have had my fair share of crunch-time efforts where a coworker and I would routinely joke around by saying "Ah, six o'clock, now we can really start to get some work done." The joke was definitely reality based but applied to a particular context: my code. A project consists not of isolated pieces of code working correctly on their own but a collection pieces working correctly together. In my opinion, interruptions facilitate more and better communication that has greater benefit than the obvious drawback of reducing the efficiency of a particular worker. Said another way, the increased efficiency of the team as a whole outweighs the reduced efficiency of the individuals.

”Now, I don't think that the openness should be taken to an extreme. I think that the people who work closely and communicate most often should be collocated in an open or somewhat open area. They should be isolated from where water-cooler discussions occur that might be distracting without adding back to the project. They should be isolated from other teams that would be having their own discussions and debates. Walls are good, but I think they should be around the teams rather than the individuals. People also need to have their space. I want a place to hang pictures of my kids and the art they create. This adds to my satisfaction.

”I think it is possible to balance all those needs. The trick for the manager is to determine where the balance point for each team is. I suspect that each team and project will have slightly different needs and there is no one perfect formula. I do believe that the local optimum for any team will be somewhere in the middle rather than at either end of the open/private continuum.”

Jobs!

Joke for the Week