Embedded Muse 152 Copyright 2007 TGG November 13, 2007

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Book Review
- Tools and Tips
- Open Space, Continued
- More On The Future of Engineering
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

Are you in either 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.

For the first time, I’ll be conducting a public version of this class in Denmark in April. For more information see http://www.ganssleindk.dk/ .

Newnes is offering Muse readers a 20% discount on two new books: Embedded Hardware Know It All, and Embedded Software Know It All. These are compendiums of chapters from other well-known books on the subject. Sample chapters are at https://www.ganssle.com/misc/ehknowitall.pdf and https://www.ganssle.com/misc/esknowitall.pdf . The latter oddly doesn’t credit one of the co-authors, Jakob Engblom, but I’m told that will be corrected in the next release. Details on getting the discount are at the bottom of the first page of each of those samples.

Book Review

The title itself is a bit perplexing as most experienced agilists endorse practicing the agile methods with discipline, and will rail against those who plaster an “agile” label over a shop that is really using glorified hacking.

The book starts with an overview of the software engineering landscape and delves lightly into the two, often at-odds, camps of agile “versus” plan-driven approaches. They do a good and balanced job of dispelling myths surrounding both, myths that inevitably arise when agendas displace careful reasoning. From there it looks at typical days in the lives of practitioners of the two approaches, and then examines a couple of case studies. Large projects, all found that some combination of agility and conventional approaches were needed.

And perhaps that’s the principle message of the book: as projects grow, successful teams draw on the best practices of both plan-driven and agile approaches.

The real meat is in chapter 5 in which they describe a risk-analysis approach to help developers and managers find a reasonable, balanced approach based on five parameters about a project and the team. Those are: the quality of the developers, the size of the team, the rate at which requirements change, the impact of a failure, and the nature of the team’s culture. Those are described well in a paper summarizing some of the book, but not their risk analysis approach, here: http://www.stsc.hill.af.mil/crosstalk/2003/12/0312Turner.html .

The main text ends after just 160 pages, but another 70 of appendices will be of interest to some. One is a very superficial introduction to a lot of agile methods. Another describes the capability maturity model. If you’re not familiar with these methods read these chapters before tackling the book as the authors assume some familiarity with both approaches. It doesn’t hurt to have a sense of the team software process as well.

$40 is a lot to pay for the couple of hours one will spend reading this book, especially when much of it is a rehash of information most of us already know. I’d sure like to see their risk analysis approach boiled down to a long article. But the book is interesting and illuminating. The authors, having no ax to grind, dispassionately examine the benefits of both software development approaches.

Open Space, Continued

“I now work in a semi-open environment. It's not so bad when everybody in the room is working on the same project. In fact, the Japanese call this an "Obeya" room. In the automotive industry, a full-fledged Obeya room would have the *entire* project team (including marketing types) in the same room, with a model of the vehicle (or the vehicle itself in the room with the team. This sort of ideal can be extremely productive. The ability to ask questions and get immediate replies is very useful.

“When there are other people/projects intermingled, productivity goes down substantially, particularly if the other people are noisy.

“I've seen some extreme workplaces in Japan. Rows of engineers at either side of long tables, with about one metre spacing (just enough room for a laptop and a notebook) and a supervisor sitting at the end of the table (sometimes at a separate desk). About a hundred or more engineers and others in one large, noisy, cramped, dimly-lit room, working on numerous different projects. I can't imagine how they can call themselves productive. I suppose it's a cultural thing.

“Oh, and Wednesday nights are "early closure" nights - they turn the lights off at 7 PM. Mind you, the frequency of holidays in Japan means that even such long daily hours don't bring their average work week up to Australian levels.”

More On The Future of Engineering

“On the other hand, I completely disagree with the quote in that "Urban Institute, Salzman Science" report alluded to by the Business Week article: "each year there are more than three times as many S&E [science and engineering] four-year college graduates as S&E job openings." At Maryland, we have great demand for our graduates ... I have not heard a single instance of one of our EE or CE undergrads failing to find a decent job upon graduation. Rather, most of them are wooed by industry. The report's conclusions are extremely broad in scope, but they are based on an extremely narrow set of statistics (table 3 in http://www.urban.org/UploadedPDF/ 411562_Salzman_Science.pdf), so while I do agree with them that many engineering students do not end up in "S&E"-specific careers (though note that they don't list many patent-related careers as "S&E" which seems odd), I do not agree with their assignment of cause. The report implies that there just are not enough jobs for all the engineering grads we produce; I believe it is a personal choice thing: not everyone who gets an engineering degree wants to be an engineer.

“To clarify that: what I see when I teach the freshman-level Intro to Engineering class, which integrates students from all walks of engineering, including EE, CompE, ChemE, MechE, Aero, Biotech, undecided majors, etc., is that even within the population of students who want to major in engineering, less than half of them really want to be *engineers* ... only a small fraction seem to have the internal burning desire to fix what is broken, to challenge themselves to improve upon existing designs, to get into the guts of things both analytical and physical and really learn. That is not the norm in American undergrads, but it is the spirit embodied by most of the foreign students who come here for grad school, and I think that is why people in academia and the National Academies take the positions they do.”

Ed Sutter added: “As time moves forward, engineering will spread out across the world. There will be short periods where it may appear that one country/continent/culture is doing better than all the others, but in the long run, it will evenly distribute across those areas that are fortunate enough to have an education system in place. Regardless of our nationality, some of us will be engineers and some of us will be psychologists. No one group of people (IMHO) is genetically more prone for engineering than any other group. At various points in history it may appear that way, but I think that will always be caused by demographics, not genetics.

“As a result, we'll go through periods where we panic because "all our jobs are going offshore", then a year later we'll panic because "we don't generate enough engineers", and at some other point we'll panic because "we have too many engineers for the workload".... Whatever...

“Bottom line trend that (IMHO) will probably not go away for quite some time (if ever) is the use of English as the "universal" language. I have two concerns...

“1. Those countries that don't have English as their native tongue will have children growing up in a home where they learn both their native tongue and English.

“2. English, for those who don't speak it natively, will always be "the 2nd language".

“Now, what's my point?...

“Regarding #1... As companies in the native-English countries start to nationalize, it will end up to put those of us who only speak English at a disadvantage because in the end, WE are the ones that won't be able to fully communicate because WE can't speak in the native tongue of those we are working with. Ever been in a meeting where all the main talk is in English, then various groups of people talk amongst themselves in some other language? They're not being rude, they're just trying to talk comfortably; but in the end, WE can't understand the conversation.

“Regarding #2... I notice that a lot of documentation (in English) is written by those who have English as a second language. As a native-English speaking person, I find it difficult at times to understand what is written (and it is clear that someone of a different nationality wrote it). Consider someone who is native to yet a different tongue. Now they are reading the abused English document and have yet another layer of confusion thrown on top. For example: a document written in English by someone of Asian origin is then read by someone of African origin who also speaks some amount of English. Imagine what its like for them! Bottom line is that we need to be aware of written communication and the ability of individuals to write (and others to read) that documentation. The documentation written in language 'X' should be written (or at least edited) by someone who is native to that language.”

Jobs!

Joke for the Week

Why do programmers get Halloween and Christmas confused?

Oct 31 == Dec 25

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: