You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
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/onsite.htm.
|Quotes and Thoughts|
We could, for instance, begin with cleaning up our language by no longer calling a bug "a bug" but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz., with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it is a disguise that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect. While, before, a program with only one bug used to be "almost correct," afterwards a program with an error is just "wrong." -
E. W. Dijkstra
|Tools and Tips|
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.
There's a tool I have had a love-hate-love relationship with. SnagIt by TechSmith is a screen capture tool for Windows and Macs. I have only used it on Windows, as the Mac's Grab utility, while pretty bare-bones, has been adequate for my needs on that platform.
SnagIt has been around for 25 years. Initially it was a small program with limited features that did a superb job of screen capturing with some some image editing features.
Then they ruined it. Features were added, and it slowed down. To resize a big image took 15 to 20 seconds. Worse, if you specified a new size in pixels, say 532 wide, after typing "5" it resized (very, very, slowly). Ditto for the "3" and the "2." You had to wait before typing each digit. I opened a support ticket. TechSmith never responded to it. So for years I put up with the crappy behavior. Once in a while I'd send them an email asking if this had been fixed, never getting a reply. It seemed unwise to pay for a new version given no expectation of better behavior.
A year or so ago I replaced my Windows machine and decided to give them another chance, buying the latest version for $50. It's fast again! To resize a 7 MB image takes under a second. The user interface is completely different from the older version, but is pretty easy to navigate.
It captures regions, windows or the entire screen, and can grab scrolling screens and videos. There are a lot of tools to annotate and modify pictures; far more than I'll ever use, though I'm not a power-user of imaging tools. Some video editing is supported.
$50 seems a little pricey for a screen capture utility, but the improved SnagIt is worth the money to me as I use the program all the time.
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
Years ago a single mom we were close to gave up on her 17 year old daughter. Teenaged girls are tough, but Joey had her mom totally exasperated; the girl followed no rules, mouthed off constantly, and made it nearly impossible for mom to take care of the two other kids. We offered to take Joey in, and obtained legal guardianship.
Alas, little did we know just how hard things could get. Joey, it turns out, was pregnant. Her mom snuck her out of our house for an abortion without our knowledge, and tried to slip her back in a few hours later. Then her boyfriend slugged her. Later he broke her arm. I went to our lawyer to press charges, but Bob took me aside and said: "Look, in two weeks Joey will be feeling sorry for the boy and won't go through with the case." That was inconceivable to me and I told him we wanted justice. Turns out Bob predicted her reaction perfectly, but as the parent-figure I overruled her immature sympathies and eventually the guy went to jail.
Things went downhill from there.
A year later, at our wits end, we convinced her to join the Air Force. Today, Joey is the mother of three, happily married, still in the service, and has shed all vestige of those long-ago problems. The military saved her in a way we could not, by imposing a rigid discipline that brooked no transgressions, and that kept her doing the right things the right ways.
Then there's Jeremy, my son's friend. He's extremely bright and I'm sometimes astonished by his insight into the nature of technology and science. Yet he dropped out of high school and now, if he's to be believed (not always wise), has gotten a GED. Also the product of a single-parent family, also more or less abandoned by mom, Jeremy now drifts from crummy job to crummy job, doing lawn maintenance one week and automotive audio installations the next. Yet he has the soul of an engineer. Despite my repeated urgings, which he does take as coming from a friend rather than from a parental figure, he seems unable to start doing anything that might have some long-term benefit. When he expressed an interest in going to a community college I offered to write the checks. But the benefits of college are years away, and his girlfriend wants attention today. The car payment was due yesterday. And his pals are off having fun now... why shouldn't he?
Anecdotally, I'm told that one reason engineering enrollments in college are down is because many students see the engineers studying all of the time. Let's see: party now or buckle down?
The late, famous aviator, sailor, filmmaker and author Ernest K. Gann in his autobiography "A Hostage to Fortune" notes that writing was the hardest thing he ever did. At times, to insure he stayed in the office focused on putting a certain number of words on paper each day, he'd literally tie himself into the chair! Gann succeeded because he used this and other strategies to discipline himself to do the right thing at the right time.
After 12 years of Catholic education under nuns who wielded corporal punishment with seemingly savage delight and rigorous Jesuits whose had an unbending stance on, well, everything, I entered adulthood abhorring the word "discipline." Yet life's never-dull twists and turns have convinced me that discipline is indeed a critical component of getting anything done in a consistent manner. Woody Allen said that 90% of success in life is just showing up. Too often even showing up - which I take as a metaphor for being there and simply doing the right things - is more discipline than many can muster.
In software engineering discipline is even more important than in most other professions. We build intricately complex systems which are invisible; no one can "see under the hood" to get a sense of how well the system was crafted. Other kinds of engineers are held accountable by customers who can see that the system looks like junk. Not so with code. Only engineers who are highly disciplined can consistently construct software of beauty that's well-behaved. Discipline means using the right approaches even when a dangerous shortcut is calling us like Jason's sirens.
Discipline. It's not just for the Jesuits or the military. None of us like it, but I think it's the most important tool in our arsenal.
Nigel Orr had some thoughts on IDEs:
I wanted to reply to Tim Wescott's well-considered 'rant' about IDEs with a couple of things:
I'm currently working with TI's Code Composer Studio (CCS), and it's the first IDE that I have felt comfortable and productive working with, I usually have exactly the same misgivings as Tim and fall back to gvim and make.
TI publish a guide at http://processors.wiki.ti.com/index.php/Source_control_with_CCS to detail which files need to go in to source control, it starts "One of the first questions that come up when working with source control and CCS is which CCS project files need to be checked in to source control.". It's a good start that they recognise the problem that he (and I) have come across with other IDEs bloating the repositories or breaking when temp files have been merged from another branch.
It has a Windows interface to configure the critical SYS/BIOS linker configuration files (.cfg), but reads and writes the plain file, so if you change the file in a text editor, the next time you go to the GUI view it stays in sync (and within the IDE, you can choose to edit the file 'source' rather than see the GUI view.
As he says, an IDE is a great toy for a baby engineer. It's also a great 'welcome to this new processor' tool for an experienced engineer if done right (once you're used to Eclipse, anyway!). However, if (as TI seem to have managed), it produces straightforward source code and allows seamless switching between text editor functions and IDE 'shiny things', then there is potential for it to be a productivity tool for expert engineers too. It's not perfect (for instance, build errors sometimes get 'stuck' in the error list even if they have been fixed), but it's a big step forward.
I would emphasize that CCS has been the exception for me, usually I agree fully with Tim, there are some truly terrible 'eye candy' IDEs out there, but if CCS is one of them, I haven't found out yet!
I also came across http://www.ti.com/lit/an/spra372/spra372.pdf , detailing how to put CCS itself into version control, so old versions of the toolchain can be retrieved and used. That is refreshingly forward-thinking from a toolset supplier.
Some readers have been pretty negative on IDEs in the last few Muses. I share their concerns for long-term viability of products created within a proprietary project format. However, I find working within an IDE a lot smoother than, say, using a command line. (Not to "bash" command lines; I'm always building bash shell scripts to process files).
Perhaps in a perfect world one could constantly migrate old projects to new tools and computers. Few have the time.
I have had old command line tools fail under newer versions of Windows and even fairly recent GUI programs break under Microsoft's latest release. Old programs of any sort may not run on newer OSes. Some companies put the entire development platform into storage. Years later they may pull out that ancient PC to support a project. But even in storage capacitors fail. Hard drives go bad. Magnetic media may suffer from bit migration. Even DVDs have limited lifetimes. (There are archival DVDs which claim 100-year retention).
By all means check everything into an active version control system. But that does not insure that the needed tools or hardware will work in the future.
Many embedded systems are in maintenance for decades. Some companies are contractually required to guarantee support and parts availability for 30 years or more. 30 years ago our embedded tools had no source level support, C++ didn't exist, C was uncommon in the embedded space, Windows 1.0 had just been released, and most of us didn't have hard disks. Three decades hence our environments will be just as different.
Of course, most of us will be retired or gone so this will be someone else's problem!
I have been getting a lot of email recently from new graduates of engineering and computer science programs who can't snare that first job. Most positions today require at least a few years experience, creating a Catch-22 making it difficult for those with newly-minted degrees to find work. This seems to be a problem across cultures, as I'm hearing this from Americans, Europeans and Middle-Easterners.
In the old days companies routinely prowled college campuses, recruiting seniors who hadn't even graduated yet. Talent was scarce and needs were high. Today talent is still scarce, if one believes the hustling in the halls of Congress for more H1-B visas.
It does seem to be true that today companies want people who can be productive immediately.
What do you tell these young people? I suggest better resumes and custom cover letters, learning exactly what the prospective job entails and tuning the documents to each prospective employer's needs. That's part of the discipline (discussed above) of job hunting. Many argue that engaging with an open source project helps establish one's bona fides, but I have seen little evidence of success with this strategy.
Are there any other suggestions?
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words. There is no charge for job ads.
Note: These jokes are archived at www.ganssle.com/jokes.htm.
**FLASH** Eveready Bunny arrested, charged with battery.
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at firstname.lastname@example.org.
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at email@example.com.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at firstname.lastname@example.org for more information.