The average embedded software project devotes 50% of the schedule to debugging the code. It's stunning to realize that half of the project's time is wasted fixing mistakes.
Perhaps the other half should be called "bugging."
Unfortunately that debugging just doesn't work. Most organizations ship with about ten bugs per KLOC, two orders of magnitude worse than best-in-class outfits. A focus on fixing bugs will not lead to a quality product.
How do you get projects done faster? Improve quality! Reduce bugs. This is the central observation of the quality movement. The result is a win-win-win: faster schedules, lower costs and higher quality. Firmware engineering, too, can - and must - profit from the same win-win-win.
Learn how (and far more) at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm.
Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.
Notepad++ sure is popular. Vishwanatha M S added this:
More about Notepad++: there is a plug-in "SourceCookifier". You can get the outline view of a C/C++ file with this (similar to what we see in an IDE).
There are also a whole lot of other plug-ins that really increase the productivity and make Notepad++ usage a lot of fun.
He also likes GIT:
I was going through the Tools' list and found that there is no mention of GIT version control system.
I have used ClearCase over the last 9+ years and switched to SVN about 2 years ago. One thing that I found missing in these two systems is local version management (ClearCase offers this to certain extent). After I started using GIT, this missing part was filled up. Apart from this, GIT offers incredibly fast system (because it is managed locally), a nice UI and complete freedom to do your own changes without affecting others. Another major advantage if GIT is its network independence. You can keep continuing with your work even when you are offline (while in SVN, it is not possible to commit when I am offline). Setting up a repository is pretty easy.
There are lots of resources out in the web about GIT and the difference between GIT and other systems. I found this http://ftp.newartisans.com/pub/git.from.bottom.up.pdf a good way to understand GIT. GitExtensions is a UI tool similar to TortoiseSVN (there is also TortoiseGit, but I found it not user friendly).
Colin Walls wrote to correct a misconception about Evernote:
I was a little concerned about an inaccuracy in one of your readers contributions [which suggested Evernote needs an Internet connection].
This is incorrect. Evernote synchronizes between the local device and the cloud. Only on mobile devices, the synchronization can be set to be "on demand" to reduce storage use.
Evernote is actually an amazing tool/service for managing random data, particularly if you are very mobile. If you'd like me to write a short piece introducing the tool, I would be more than happy to oblige.
I have no business interest in or connection to Evernote Corporation. I am just an enthusiastic user of their products.
In Muse 236 I wrote about the tradeoffs between being a generalist and a specialist. Readers had a lot to say!
Rob Fries wrote:
Most embedded engineers work for a place that's small (read as, has only 1-3 engineers). No one to split up the work with.
On some occasions I've had folks working for me that wanted to specialize, because they only wanted to do the `fun' work, whatever that was for them personally. The problem is, if they didn't do the other tasks, they didn't learn from the mistakes they made while only doing the "fun" work. Feedback provided was forgotten quickly because they didn't experience the pain of the mistake. The best engineers *can* do it all, and usually still *have* to do it all even after many years, but their key skill becomes a recognized asset for the group, and others with a different key skill can help them in turn.
David Wyland contributed this:
Specialization is good for the silicon economy, if you consider specialists as elements that can be assembled into teams to make new products and processes. A wider selection of more powerful elements means more options for assembling a multi-element design. But there is an assumed requirement: a lead designer that creates and coordinates the overall design of the product and how the various specialists fit into the picture. Using the Principle of Leaky Abstractions, the lead designer has to understand at least one or more levels of abstraction down from the top level design in order to debug the problems between the design and its assumed requirements, let alone just debugging the design to make it work. Without this knowledgeable leadership, mediocre design results in the best case, and disaster in the worst. Somebody has to lead. The old chestnut of a camel being a horse designed by a committee applies.
Frequent correspondent Luca Matteini added this:
I really share your feeling on having a whole project in my hands, from
the analysis through development, production support, and tech support. I
really love to see things from their conception to practical use, feels
like my work is really "complete", in some sense.
Maybe is a Da Vinci syndrome, feeling to master every art and science --
and Da Vinci birthplace is even a few tens of miles from here!
But the world has changed from the Renaissance, the notions in a physics
textbook can prove it, even though Da Vinci was anyway a genial engineer
At the same time, with the new pace of technology, things have become so
much more complex from 1980, when I read my first electronics magazine.
I think that anyone that can follow a project from the first ideas, to
final realization (with success!) is really a lucky person: as I am when I
can do the same. You just have to put some limits to your work, because it
needs a tradeoff on total complexity. You have to be conscious that it
can't go beyond your limited skills (no matter how you grow).
Many years ago I worked with a guy on some heavy mechanics systems, and he
was used to say "it's not that we're unable to do it: just isn't in our
convenience". This way he was hiding a practical limit, favoring his
We should always keep well grounded (not just electrically), and from
there reach for the best we can.
What I fear more, about specialization, is what I read in your words about
the lack of reality, that risks to infect even who works in engineering.
So, can be fine being specialized in something, but not loosing the bases.
Maybe among the bases I should list even the hunger for knowledge, that
should pervade anyone who works on applied science. Otherwise, pasting
blocks of precooked code, or blindly connecting to a black box, won't be
that different from moving boxes of storage.
Tom Mazowiesky was one of many to quote Robert Heinlein:
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
A quote from Lazarus Long, one of Robert Heinlein's in Time Enough For Love.
Fabian Picca wrote:
Regarding your comment on specialization, and while it is true that the industry demands increasingly specialized people, being a generalist is what have kept me on the embedded business for more than 20 years (and counting).
However, I couldn't agree more with your viewpoint and I also think that because of this focus on "saving the company money", it is becoming more difficult for newcomers to get a job unless they are highly specialized.
Anyway, even when extremes are bad, I still think that I prefer to stay at the generalist end of the spectrum.