|
Embedded Muse 94 Copyright 2004 TGG March 12, 2004
You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.EDITOR: Jack Ganssle, jack@ganssle.com
CONTENTS:
- Editor’s Notes
- Feature Driven Development
- Time Management Tool
- More on Redefining C’s Operators
- Jobs!
- Joke for the Week
- About The Embedded Muse
Editor’s Notes
The Embedded Systems Conference is this month in San Francisco. I’ll be teaching a class about Managing Embedded Projects on Monday March 29th. Tuesday I’ll moderate a Shop Talk discussion called “The Future of Engineering in an Outsourcing World” (from 7:15 AM to 8:15). The conference is always a fun time; do come by and say “hi”.Thanks to all who voted for a venue for the next public Better Firmware Faster seminar. Chicago won overwhelmingly; it doesn’t hurt that it’s cheap to get to the city from most of the USA. The seminar’s date is May 17. Seating will be limited so sign up early. See https://www.ganssle.com for more details.
Looking for work? Definitely check out http://www.asktheheadhunter.com/newsletter/OE20030617.htm. Nick Corcodilos explodes myths around resume factories like monster.com. It seems only 3.6% of all hires are made through monster.com; all of the other sites fair much worse.
The article is an interesting and revealing read. I’ve always advised people to never abdicate their job hunt to headhunters or automated web sites. Though these might be useful adjuncts to a search, the wise job seeker takes control of the hunt and is always actively involved. It’s just another job to the headhunter… but it’s your career.
Feature Driven Development
The last decade or so has been an exciting time to be in software development. Hardware design has, in my opinion, lost some of the fun now that ICs are so dense and speeds so high. But the software world has been flooded with new ideas and methodologies. Some are brilliant, others goofy, but all are fascinating.One is Feature-Driven Development (FDD). Do read “A Practical Guide to Feature-Driven Development”, by Stephen Palmer and John Felsing (ISBN 0-13-067615-2, Prentice Hall, 2002), which is a readable treatise on this important topic.
Feature-Driven Development (FDD) is a relatively agile development methodology that is, in my opinion, much more suited to most embedded efforts than techniques like eXtreme Programming. XP is an interesting idea with lots of fabulous concepts we should steal, but I’m concerned about how XP shortchanges design. FDD requires considerable initial design, yet preserves much agility in the feature implementation phase.
As an aside, a new article (http://www.stsc.hill.af.mil/crosstalk/2003/12/0312Turner.html, People Factors in Software Management: Lessons From Comparing Agile and Plan-Driven Methods by Richard Turner and Barry Boehm) gives a quite good analysis of where Agile methods fit in the spectrum of projects. The quick summary: Agile methods are best if you have lots of superior people, a project whose reliability isn’t critical, quickly-changing requirements, a small team, and a culture that thrives on chaos.
FDD, too, requires above average to superior developers. That seems to be a characteristic of most new methods. Where do all of the average and below-average people go? Obviously, simple math tells us an awful lot of developers won’t score in the superprogrammer category.
FDD has a Project Manager who owns the project and acts as a force field to shield the developers from interruptions and administrivia. Day to day direction falls to the Development Manager, a person endowed with both people and technical skills.
A Chief Architect is responsible for the systems overall design.
Chief Programmers own feature sets and lead small teams implementing the code. They rely on Class Owners – the actual workers cranking out software. Unlike XP, where everyone owns all of the code, in FDD the Class Owner is responsible for a particular class.
FDD has 5 processes. The project starts with an overall design, called a “domain object model”. From there a features list is constructed. A plan is made, grouping features into sets which are assigned to Chief Programmers.
The fourth and fifth processes comprise the project’s engine room. A Chief Programmer selects a set of features that can be implemented in two weeks or so. He or she designs each feature, creating a list of classes which are designed and implemented. This closely resembles Gilb’s well-known Evolutionary process, which focuses on “time-boxing” a schedule – that is, figuring out what can be done in a two week timeframe, implementing that, and iterating.
The book includes a 10 page cheat-sheet that details each part of FDD. It’s a handy guide for outfits just embarking on a new project using the methodology.
The book has frequent sidebars featuring a dialog between an experienced FDD developer and one just embarking on a project using the technique. I found this distracting and not terribly enlightening. And the authors push TogetherSoft’s product just enough to be annoying.
But these are minor complaints. Unlike some programming books that are long on passion while shortchanging substance, this volume gives a clear introduction to FDD, with enough “how-to” to use the method in your own projects.
Highly recommended.
Time Management Tool
Dave Kellogg wrote in about my comments on a time-keeping system:I have been using "Personal Time Clock" (PTC) daily for about a year for collecting metrics info, and have been quite happy with it. Cost is reasonable ($20). PTC is written by Ken Reek, author of "Pointers on C" (which I highly recommend). See: http://www.kmrconsulting.com
Features that I like about PTC: 1. A two level hierarchy of categories and projects.
2. The log file is in flat ASCII (as all PC data should be).
3. There is an optional programmable interval timer that pops up a reminder box: "Are you still working on project XYZ?" I leave this turned on (at every 15 minutes), since it helps keep me honest and current about being logged into the correct project.
4. Very flexible report generation.
5. Data export to Excel, etc. for additional analysis.
More on Redefining C’s Operators
Many readers had comments on an approach in the last Muse to avoid C’s “==” and “=” confusion. Most had comments about comparing a Boolean like: #define EQ == if ( BooleanVariable EQ TRUE ) Don Brockenfeld wrote: If you're not going to treat Boolean variables as predicates, then you should avoid comparing the bare variable to TRUE. In C89, all nonzero values are equally true, but only one of them will be equal to TRUE. The danger is that one portion of your code will compare the variable to TRUE and another portion will compare it to FALSE. As a result, your code will follow an inconsistent and "impossible" thread of execution. In embedded systems this can be worse than if the program had uniformly taken the FALSE branches when it should have taken the TRUE branches. I prefer to use predicate format: if ( BooleanVariable ) {...} if ( ! BooleanVariable ) {...} Alternatives are if ( BooleanVariable != FALSE) {...} if ( BooleanVariable == FALSE) {...} A trickier alternative takes advantage of the fact that the standard guarantees that logical expressions will only evaluate to 1 or 0: if ( !BooleanVariable == !TRUE) {...} if ( !BooleanVariable == !FALSE} {...} (I admire the cleverness of this alternative, but fear the consequences of a forgotten exclamation mark.) C99 adds a Boolean type. I recommend to anyone using Boolean variables to fake a C99 compiler if you don't have one. Make your ownThanks Don!
Other readers worried that using EQ, NE and the like as replacement operators extends C and makes it unreadable to untrained people. Several suggested extensions like BITAND for &, LOGAND for &&, etc; some facetiously, others seriously, others to show how bad things can get.
Jobs!
Joke for the Week
Those wild and crazy engineers at ILX Lightwave (who are looking for a firmware engineer – see above) came up with this all-too-appropriate prayer:Our manager which art in our cube, hallowed be thy schedule. Thy project end come, Thy schedule be done, minus the testing and fixing. Give us this day our daily flogging, and forgive us missing features, as we forgive feature creep. And lead us not into meetings, but deliver us from marketing, for thine is the paycheck, the pain, and pressure for ever and ever.