Tweet Follow @jack_ganssle

Embedded Muse 146 Copyright 2007 TGG June 11, 2007


You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Cubicles
- Tools and Tips
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes


Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/classes.htm .


I’ve long advocated keeping an engineering notebook to log the bug-hunting process and for other reasons. At the Embedded Systems Conference one attendee told me that’s no longer allowed at his company, because the lawyers are afraid the books might contain information detrimental to the company! The logical end to this is to never create a document and send no email. One can’t help wonder if litigation frenzy will destroy Western civilization.


Several readers sent along this URL: http://teleworkrecruiting.com/ , which is a site that purports to connect folks who’d like to telecommute with companies prowling for such workers. It looks interesting though I’ve yet to hear successes or failures from people using the resource.

Embedded.com will be hosting a webinar on the “embedded code crisis” Tuesday, June 19 at 2:00 PM EST (18:00 GMT). Rich Nass, Dan Saks, Mike Barr, Joel Sumner and I will discuss the issue and take questions from attendees. Though registration is required, it’s free. See http://techonline.com/learning/livewebinar/199901488 .


I’ve created a video titled “Develop Firmware in Half the Time” that distills the basic ideas and processes needed to efficiently crank out great firmware. There’s more information available at http://www.ganssle.com/video.htm .


Cubicles


Several readers responded to my rant about cubes. Steve Litt wrote: “For this reason, back in the mid-80's when I programmed medical management software, I escaped an over-insistent manager (not my boss) who thought her every whim should be my priority. I ditched the corporate building and did my programming 4pm to 2am in an over air-conditioned computer center, in the "bad part of town". Besides me, the only other human in this multi-thousand square foot computer room was a single computer operator.

“When I went to "lunch" around 10pm, I was propositioned by ladies of the evening. But my productivity went up so much, my boss let me keep doing it, and the over-insistent manager got a sit-down from higher-ups, and never messed with me again.

“HOWEVER...

“Sometimes cubicles are good! In the late 1980's I did legal software programming for a huge law firm. At first the programmers had private offices, but pretty quickly we got moved to cubeville. At first I was disappointed. But here's the thing -- all of us programmers were together, and all of us were very smart and talented, so that the close contact encouraged chat about programming techniques, requests for and offers of advice, etc. The total ability of our group far surpassed the sum of the individuals because 90% of interruptions contained info that saved somebody hours of programming experimentation, eclipsing the 15 minutes (I think it's more like 30) to get back to the pre-interruption state.

“If your cubicle farm contains nothing but peers you respect and exchange info with, cubicles can, in my opinion, increase productivity.”

He went on the next day to add: “Yesterday I wrote in response to your cubicle article. I responded, saying that yes, interruptions are horribly costly, but in certain situations involving a talented and interested peer group who can work together as a team, a cubicle farm can actually raise productivity by encouraging intellectual interaction.

“Today when I woke up I realized that the statistics you quoted might be a symptom, not a cause. These statistics are between the first and 4th quartiles of developers, as stated in your Cubicle article of Muse 145. First quartile people had significantly more workspace, quiet, private, with less interruptions and the ability to divert or turn off phone calls. My initial reaction was "see, that proves it, privacy and quiet cause higher productivity."

“Waking up this morning, I remembered that I've always attributed my high programming productivity (in terms of lines per day, deadlines met, and customer satisfaction with the finished product), to my design methodologies. In the 80's and 90's I used functional decomposition. In the late 90's and early 00's I used OOP methods with some functional decomposition. Nowadays I'm using data-centric design.

“Everywhere I've worked, there were dumbheads and dweebs, working in identical conditions as me, who couldn't program their way out of a paper bag. Invariably these were the people who get an assignment, walk to the terminal, and start typing in code. %&%#$%#$!!!

“So if design methodology is the cause of my productivity, how can the statistics you stated be explained? One explanation is pretty simple...

“Productive programmers don't put up with severely interruptive conditions. They either get another job, or get management to give them special conditions, or summarily move themselves to a different shift or location (like I did in the story I told yesterday).

“A highly productive developer would be severely bottlenecked by an interruptive environment, whereas a guy who got into programming "for the money", who does it just for a paycheck, and who produces ten lines of tested code per day. would not be bottlenecked by interruptions, and in fact might derive entertainment from the interruptions. So he stays put in his interruptive environment, while his code-loving productive brethren move on to better environments.

“From the employer's perspective, the interruptive environment trashes productivity, but not necessarily by slowing down the existing developers. Perhaps the interruptive environment trashes productivity by causing the best and brightest to leave.

“Anyway, to me the bottom line is this -- if the interruptions are from intelligent team members making regular contributions to the team's intellectual knowledge, and spreading that knowledge, such interruptions will likely, on the average, create greater productivity. But if a developer's cube is located between Betty Bookkeeper and Davie Data-Entry, and Betty and Davie spend the day chatting across the walls and fielding loud phone calls about their personal lives, the programmer will move on.

“Oh, and regardless of the environment, the developer using efficient design methods will code circles around the one who doesn't.”


Art Felgate has another view: “I've heard the Peopleware study cited so many times I really question it.

“If the results were truly so poor would professional managers at Fortune 500 companies really propagate this practice?

“I have a hunch that a very large percentage—perhaps 75%--of engineers and programmers are introverts, specifically ISTP Myers-Brigg's types (this statistic, BTW, has been extensively studied and verified). Extroverts are energized by being around people and environmental "buzz"; introverts prefer quiet, and being alone as they work. It could be that the DeMarco study applies to ALL INTROVERTS, in all types
of fields, not just programmers. I don't think programmers have some special needs that other workers with similar characteristics don't share.

“I once worked for a company that forestalled installing the cube walls in a new wing. Everyone had desks and we could all see each other--it was wide open. Over time, the introverts tended to construct their own "walls" of filing cabinets and book shelves around their desks, hiding from everyone. It was kind of funny, yet at the same time very predictable!”


A reader who prefers to stay anonymous wrote: “>>* Turn the phone off! If it has no "off" switch, unplug the damn thing.

“We recently got new Cisco "IP" phones. Yes, connected to the internet
via an Ethernet. For days they were useless until they could be configured properly. And when you unplug them and plug them back in, they take a long time to "reboot". Oh, and it's also a one-port Ethernet router, so my computer plugs into the phone (daisy chain style) to get its Ethernet connection. So when the phone goes down, so does the computer!

“Plus you can configure custom ring tones. One colleague has his phone screaming "Are you THERE??" every time it rings so he can know it's his phone from waaay down the hall (and everyone else knows too). What fun! :-\”


Tools and Tips


Bob Paddock wants to mention a PCB program: “There is also PCB, but no good Windows support yet (I'm working on it). http://pcb.sf.net/”


Jobs!


Joke for the Week


Bob Landman sent this link to an amusing buzzword comic: http://www.fatalexception.org/action_item.html .