« The End of ASICs as We Know Them | Main | A Few Words of Reality about Multicore Programming Tools »

Link This | Comments (8)

Steve Leibson

Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.

August 4, 2008

How’s your latest firmware project going? Bugs? Schedule slipping? Resource problems? Headaches? Not sleeping well at night? Driving you to drink? Thought so. It’s the same for everyone. The usual schedule slip for embedded firmware projects is 100%. It always take twice as long as our most coldly realistic estimates. You say you’d like to escape this particular hamster wheel? Really? Honestly? OK, I can tell you how—but there’s a catch. After I tell you, most of you won’t do it. How do I know? Because you never have.

OK, OK, I’ll tell. You can escape the traps quickly and inexpensively without a lot of pain by embracing Jack Ganssle’s vision of firmware development and managing your software projects with realism and managerial backbone. Who is Jack Ganssle you ask? He’s the Thomas Paine of firmware development. You know Paine. He’s the guy who wrote Common Sense, the pamphlet that made the case for American independence from England.

Jack Ganssle is the Thomas Paine of firmware development because he’s studied the topic for decades and he has common-sense ideas about how to slice through the Gordian Knot of firmware development. He’s been giving the lecture “Develop Firmware…In Half the Time” for many years at the Embedded Systems Conferences and on demand at corporate locations around the world.

Too expensive you say, especially for unproven ideas? Can’t afford the time to go to the Embedded Systems Conference and can’t afford to bring Jack in for a personal visit? How would you know? Did you ever call the guy? OK, OK, sorry to ask such a personal question.

Let me summarize Jack’s position. Are you a software professional? Are you certain? If you’re a real professional, like a doctor or a teacher, your profession requires you to keep up with new developments in your field and incorporate those developments that are known to work (like penicillin) into your daily practice. So I (and Jack) ask again, “Are you a professional?” Thought so.

“Stasis is Death” says Jack.

If you and your team are developing code today the way you did a few years ago, you have nowhere to look but in the mirror if you want to see the source of your troubles.

“The way to code faster,” says Jack, “is to change your methodology, but new methods don’t work because we lack the discipline to implement them.” We try to measure our way to success but we measure the wrong things. We write 300-page software-development standards that are too complex for individuals to keep in their heads so, in the end, the standards aren’t followed.

So what do you do? I’m not going to steal Jack’s thunder except to say that you can get a very long way down the road to better firmware-development success by spending $349 on Jack’s two-DVD video and then sitting yourself and your team down to watch all three hours of it. Then you and your team should discuss it and decide how much of Jack’s common-sense approach to firmware development will work in your situation. Most of it will. I’m very confident of that.

Sounds too simple, doesn’t it? In my opinion, the video’s cheap for what it delivers. You and your entire team can watch it again and again for one low price, until the common sense sticks. You can stop arguing about stuff that doesn’t matter—like where to put the braces in your C source code—and start using techniques that will help you immensely—like banishing global values, creating prioritized feature lists, and planning on what you’ll do when the deadline arrives and all of the code isn’t finished.

It really is too simple.

And again, I betcha won’t do it.

So ask yourself this one question, “Why on earth wouldn’t you?”

Here’s where to order it.

Posted by Steve Leibson on August 4, 2008 | Comments (8)

August 12, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
M. Simon commented:

Steve, Here is my last. If a programmer is not disciplined enough to program in FORTH they are not disciplined enough to program in any other language. Which if you read Ganssle''s "Hate FORTH" bit and follow his latest and greatest on how to improve programming efficiency is exactly his point. BTW as you well know a lot of things we do are not the best way to do them. We got where we are because of network effects. In any case as Ganssle points out FORTH is probably the best way to bring up cold iron because you can try stuff quickly. Learning how registers work by trying stuff. And then there is the problem of the mismatch between the languages we use and the iron they run on. We cover that whole problem up by upping the clock speed. And branch predictors, and long pipelines. Not to mention our power management kluges. And all the other little and big complications we use to cover the real problem. Well that is starting to run out of gas. As I said the hurt is not great enough yet.

August 11, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
Steve Leibson commented:

M Simon: I know several programming langueages, picked up over the last 40 years. It may come as a big surprise to you that FORTH is one of those languages. Ex-HP engineers like me are genetically drawn to stack-oriented languages like FORTH. I read Leo Brodie's "Thinking FORTH" back in 1984 when it first appeared. Feel free to leave as many comments as you like, but I've already given FORTH a fair evaluation. However, think about this: if you have to continue to wax enthusiastic about a language that's as long in the tooth as FORTH, perhaps it's just not as right for everyone as you think. And that's my final word.

August 11, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
M. Simon commented:

And another thing: lines of code is the wrong metric. Effective functions is the correct one. Obviously if I can write an effective function in 10 lines and my counter part does it in 50 lines and I can do 20 lines a day and my counterpart does 50 lines a day I am more cost effective even if he has 2X or 3X line output I do. Oh, yeah. My rule is that my code should be largely self documenting. You should be able to READ it. Comments should be minimal. Which is just what that government inspector saw. What does that gain you? Maintenance is much easier for 10 lines of code vs. 50. And that is just one gain. What is required? Very clear thinking and discipline, discipline, discipline.

August 11, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
M. Simon commented:

I just looked at Ganssle's "I hate FORTH" and could find nothing to disagree with. I repeat: in the hands of incompetent programmers it is a guaranteed disaster. Moral of the story? Get rid of the incompetent and mediocre and go with only the very best. Brooks in the "Mythical Man Month" makes the same argument in a more round about way.

August 11, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
M. Simon commented:

Steve, Read Thinking FORTH and get back to me. I think you will find that it espouses PRINCIPLES that Ganssle also pushes. As to it sucking: you might want to look at the FED-EX experience. They claim they did a total redesign of the box their delivery guys use in six months with no hickups vs an estimated two years in a more popular language. I remember competing against a team of 30 C guys in a mil R&D program with 3 guys in my shop. The mil guys would ask for what amounted to a total redesign of the hardware/softaware. We got the job done in a month or so. Tested. Working. The "C" guys were still struggling after 6 months and complaining about our unfair advantage. I do admit that FORTH in the hands of undisciplined software folks is a total disaster. However, I made sure our team was disciplined. We had a government inspector read our code and he said it was the easiest code to understand he had come across in years. And he looked at every thing from FORTRAN to C to Pascal to ADA etc. The moral of the story? Fire 27 of the people on your software team and teach the remaining 3 good FORTH practices. BTW I also did the hardware design while riding heard on the programmers. As I say. We aren't hurting bad enough to take that approach. Yet. Also. I have applied what I learned doing FORTH to doing C programming on one of the first mil/aerospace CAN bus testers (in house). On time and under budget. I did 70% of the design, some of the coding, all the special hardware, and averaged a work day of about 4 hours. My boss was pissed that I put in so little effort. But I was being paid very big bucks (by the hour) and only put in the effort required. At the end he was very pleased with the project budget and getting it done on time. BTW I used a lot of FORTH for test code necessary to get all the hardware pieces running together. Just the way SUN does with Open Boot. But yeah. If you want to keep a large team of incompetent programmers employed and come in at 2X to 4X the time and budget "C" all the way. I'm with you there.

August 11, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
Steve Leibson commented:

My mistake, Jack Ganssle has written about FORTH. The article is titled "I Hate FORTH" and it was published July 31, 2001 in Embedded Systems Design magazine. The first sentence in the article is "FORTH sucks." Looks like things go downhill from there. Here's my bottom line: You can write bad code in any programming language that I know of. You can make your program unreadable. You can obscure intent. You can exploit little-known programming tricks and compiler foibles. In short, I do not think any programming language is ever the whole answer to the problems of programmer productivity or software integrity. FORTH's no exception.

August 10, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
Steve Leibson commented:

M Simon: FORTH has been the answer to the question no one is asking for three decades. If Jack Ganssle thought FORTH was the answer to the firmware problems he confronts daily as a consultant, you can bet he wouldn't be "keeping it a secret."

August 10, 2008

In response to: Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.
M. Simon commented:

The proper rules for firmware development are available free on line in a book called Thinking FORTH.

And it should be mentioned that the #1 thing killing firmware development is the use of the "C" family of languages.

The stack thrash on context changes is a killer in terms of time.

So what do developers do to make up for that? They use bigger, harder to test modules.

And who remembers FORTH? Just a few of us old farts and the smart guys at FED-EX who get firmware out on time and on budget.

When the pain gets bad enough there will be a revolution. We are getting close. BTW Ganssle knows FORTH pretty well. Why does he keep it a secret?

1. It is not popular

2. It would kill his cash cow

Not that I blame him any for either point. Selling people what they want is good business. Telling them what they really need will get you kicked out the door. "But look at all the money we have invested in legacy code. I will look stupid if I junk it. It is just not done."

Me? I'd rather go hungry. A rather unusual attitude to be sure.

About EDN | Site Map | Contact Us | Subscription | RSS

POST A COMMENT
Display Name

Before submitting this form, please type the characters displayed above. Note the letters are case sensitive: