You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
The quality movement’s central observation is that building in quality inevitably results in lower costs. That’s the focus on my Better Firmware Faster course. It is possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Bring this class to your facility. More info here.
I'm now on Twitter.
|Quotes and Thoughts|
From Geoff Stewart: "Computers do what you tell them to do. Not what you want them to do."
|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.
I came across a nice blog, which has, among other things, a weekly posting for newbies getting into embedded development.
Rod Bartlett had some tool suggestions:
|Freebies and Discounts|
Thanks to the generosity of Imagecraft and BusBoard Prototype Systems we're having lots of giveaways this month. Feel free to enter both contests.
First, BusBoard has given me five of their Blinky Lights prototyping kits, which are designed to teach youngsters and the young-at-heart the fundamentals of electronics. I'll give one away each Friday for the next five weeks.
And there's a Jumpstart Microbox from Imagecraft, widely known for their inexpensive development tools. The Jumpstart Microbox contains a Cortex-M0 board, a shield with I/O, a new book about embedded C programming, and the toolchain. An included library makes working with the normally-complex I/O very easy. A winner will be selected before the next Muse. Enter via this link.
|Software is Too Important to be Left to Programmers|
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
In the last Muse I wrote about the quote: "Software is too important to be left to programmers." Ray Keefe has some thoughts about this:
I couldn't agree more with your perspective on programmers. Programming or coding is an element of software development. The entire design process covers a lot more than that. Saying the software development is just programming is like saying engineering is just drafting or PCB layout.
However I think the author of the quote might actually be on your wavelength, just expressing it differently.
One way to think of this is that software is indeed too important to be considered just programming.
The other element of this is that software is also just a component of a system. We develop embedded systems which consist of custom computing hardware platforms, the software that runs on those (sometimes multiple pieces of software that form a system between them), Internet based support systems and the ecosystem they live in such a computer or mobile device applications and utilities. The design of the entire system is important and not just one element of it on its own. We make decisions about what is achieved using either hardware or software and what could be done either way and then decide on the best approach to take. Each decision has benefits and ramifications.
So it is way more than just programming.
Paul Bennett wrote:
Interesting piece inspired by the quote. However, I think that software engineering may actually be much older than anyone realises. True we have not had programmable electronic computers for very long in human history but if you look back even before Ada Lovelace was born (acknowledged as the first person to use stored programming in a computational machine). The forerunner of the Jaquard Loom was a loom by Basille Bouchan (1725) which used punched card as the pattern store. However automata, in general, have been with us for a lot longer and probably appeared in the times of Greek mythology. Somewhere in between automata that could do a number of tasks dependent on the selected programme of actions would indicate that, even though it was not called such, software engineering has been around a very long time.
This will raise the question why we still have software that is buggy.
A lot of it is the current attitudes pervading society. The need for the quick fix, want it now mentality that has been growing more prevalent.
The well practised craft of applying sound engineering processes and procedures and being imaginative enough to foresee where problems might be posed, for some design paths, should all culminate in selecting and building the right and robust solutions to any need.
As I always had drilled into me. Proper Planning Prevents Poor Performance. I also aim to have requirements that meet the criteria of being Clear, Concise, Coherent, Correct Complete and Confirmable with sufficient documentation to support a provably valid solution and lack of unwarranted risk. Sadly, most software that I see presented to me often lacks sound documentation, containing instead plenty of ambiguous statements that often conflict with other information in the same package. That sort of software has a "hacking feel" to it and is not worthy of the "engineered" accolade.
My process and methods have also been proven over time as one robotic software system handling highly hazardous material is still in operation since 1985 and is now being called to operate until 2030.
And from Jim Berry:
"Software is too important to be left to programmers."
Engineers like to speak in analogies. Consider this: Programming is to software engineering as drafting is to mechanical engineering or board layout is to electrical engineering. Engineering, whether electrical, mechanical or software, is about design. A mechanical engineer represents his design by means of a drawing which is then handed off to a machinist to be built. An electrical engineer represents her design as a schematic which is then handed off to a technician to be laid out and fabricated. The unique characteristic of software engineering is that we are able to build our own designs through programming without the necessity of representing the design in a human-readable fashion to be handed off to a separate person for fabrication. That is a mixed blessing. There is a great temptation to start programming before the design is finished (in some cases even before it is started) and often without an implementation-independent representation. Discipline is required to avoid premature programming which inevitably leads to poor code. Managers often exacerbate this temptation by asking "How many lines of code have you written?" Instead they should ask "Is the software design document completed (and reviewed)?"
Don't document the code; code the document!
Daniel Daly replied:
I read with interest your writings (and readers' replies) about craftsmanship. The good-tools/good-craftsman points are well covered by you and other commenters - I accept the premises, and agree with most.
An aspect of our work that I consider part of craftsmanship (perhaps a better term is workmanship) that doesn't appear to me to have been mentioned so far is consistency in coding. This is not the same as style of coding - coding style itself is not nearly as relevant as is selection (or definition) of a coding style and adherence to it tat is conscientious, consistent, and predictable.
When reading someone else's code, I find nothing as distracting and deleterious to readability and comprehensibility as sloppy, inconsistent coding. To me, it says a lot about the writer's attention to detail. In the same way that big blobs of solder all over the place make me wonder what dead shorts lurk in a circuit, shoddy coding makes me wonder what dangling pointers, off-by-ones, or race conditions lie in nearby shadows.
One could argue that this problem is easily solved, or at least contained, with beautifier tools, but hosing down ugly code with such a tool isn't necessarily a good idea, either: it discourages that ever-important attention to detail, and may destroy important information encoded in careful, consistent, albeit unorthodox indenting, for instance.
Some languages encourage consistency better than others, I suppose, but I don't believe language choice has much bearing on it, either. One can write clear, consistent C with roughly the same effort as for assembly, FORTRAN, Haskell, or PHP.
Furthermore, it's a hollow argument, to me, that being a "neatnik" with the source code is a distraction. Perfection to the point of diminishing returns is possible in any pursuit, but it takes roughly the same effort to check in well-laid-out, readable code as it does to grunt out eleven hundred lines of crap, and it's a huge favor to oneself, or anyone tasked with reading the code.
Steve Taylor wrote:
You might also make much of the fact that "A bad craftsman blames his tools", when you understand that the craftsman, as part of his apprenticeship had MADE his own tools.
I think that the software craftsman who puts up with crap software tools should write his own.....
Martin Glunz wrote up some notes about this that are too long to reproduce here. Find them here.
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 a job ad.
Note: These jokes are archived at www.ganssle.com/jokes.htm.
Bob Snyder sent this:
"I gave away all of my dead batteries... free of charge!"
Advertise in The Embedded Muse! Over 25,000 embedded developers get this twice-monthly publication. For more information email us at email@example.com.
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
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 email@example.com for more information.