You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
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 https://www.ganssle.com/onsite.htm.
|Quotes and Thoughts
From Harold Kraus:
"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility." -- Edsger 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.
More folks have commented on tools for screen captures. Jack Everett wrote:
Vlad Z commented:
Mike Foss also likes the snipping tool:
The Register has and interesting - and scary - article about security flaws in millions of small office/home Internet routers. The piece has a number of worthwhile links and shows that many of these devices are rife with problems, some of which are trivial to exploit. In some cases one wonders what the developers were thinking.
A router is a complex product that often includes Linux, and I suspect the code layered on top is in some cases created by people with limited experience with this complex OS.
But there's more to this than that.
The bank recently replaced some our credit cards. The new versions have chips in them, which won't bolster security much for transactions here in the USA. Few point of sale terminals here can read chipped-cards; they still rely on the magnetic stripe. Our grocery store has had chip readers for a year or so, but they don't work and aren't used. Why are there no chip readers? Millions of point-of-sale terminals would need to be replaced, which would incur costs for the stores.
It's the same problem with security flaws in routers. There's simply no demand for security in most of the embedded space. Adding it would cost money, and few development teams are allowed to add something for which there is no demand.
Yet so many huge breaches have occurred at enormous costs to businesses. It's the old problem that adding X dollars in engineering cost today, to save 10X tomorrow, is seen as a poor tradeoff. Time-to-market and minimizing today's expenses are management's zeitgeist. Risk is hardly considered.
But risk is considered, at least at a corporate level. Or is at least giving a passing nod. For instance, the massive breach at Target in 2013 caused them to add this to the Risks section of their annual report:
It goes on to explain that they are facing over 80 suites as a result, and are under investigation by state and federal authorities. They admit the breach cost them $148m. The sad part of this particular story is that it has been repeated so many times.
No one would say strong security is easy. But it is important. We embedded engineers can't control social engineering but can, and must, harden our systems, too many of which are wide-open. Today you can buy a toothbrush with a Bluetooth connection, which means compromised firmware could make a toothbrush, of all things, an attack vector. Tomorrow we'll have a zillion embedded devices of all kinds connected to the Internet.
How secure will those be?
The folks over at Hackaday stunned the community last year when they offered a trip into space, or its cash equivalent (about $200k) for the best bit of home-made electronics.
The contest runs again in 2015, with the same grand prize, plus a lot of smaller though quite princely rewards. The contest starts now, and you have till August 17 to get your incredible mind-blowing entry in. This year the focus is on devices that improve the world.
I'm honored to be one of the judges. Unfortunately, they tell me no amount of finagling will let me subvert the process and get that ride on Virgin Galactic.
More info here: http://hackaday.io/prize
|Is It Done Yet?
"It depends on what the meaning of the word 'is' is." --Bill Clinton
"It depends on what the meaning of the word 'is' is when you say 'it is done'" -- Wise managers to innumerable engineering teams
"Where is it?" he asks. Mozart points to his head. "Here, it's up here," he explained. "Now it's all just scribbling. Scribbling and bibbling and bibbling and scribbling." Wolfgang Amadeus Mozart, from the movie "Amadeus."
The smartest and most productive developer that ever worked for me had his own definition of "it is done." Once he understood every nuance of the problem, once he'd structured the solution in his head, the code was "done." After that it was simply taking dictation. Like Mozart he composed the entire intricate structure of the code in his head, and after that merely transcribed his thoughts into the computer. Also like Mozart, or at least the Mozart we know from the wonderful movie "Amadeus," his transcription was nearly error-free.
But like the movie-Mozart who spent many long nights feverishly writing his scores while hiding from angry creditors and customers, that developer, too, always grossly underestimated the effort needed to go from a brain full of design to a working implementation.
Nothing is more infuriating to a manager than hearing that a system or component is "done," and then later finding out that "done" does not mean completely working and tested. A wise manager realizes "done" means different things to different developers, so develops a questioning strategy to elicit the system's true status.
"Done" is a particularly problematic concept with traditional software engineering approaches. In most of these the bulk of the testing, and certainly the integration phase, is deferred till late in the project. When management wants to lop off a few weeks from the schedule, the end-phase -- the testing - gets whacked. So no one really knows if the system works correctly.
Every agile methodology, though, stresses testing uber alles. No change, no matter how small, has any significance till the test suite runs. Any change, no matter how big, is considered "safe" once the test suite validates it. "Done" means the code is written... and tested. That profoundly alters the landscape of software development. It holds every modification, or every function, method, subsystem or complete system to the highest of standards: it works. "Done" indeed means done, without any Clintonian obfuscation.
Unfortunately, the automatic testing required by agile methods is tough in the embedded world. A user might have to press buttons or observe a display. Systems that interact with the real world might actuate something, yet have no feedback enable an automatic check to ensure the right thing happened. Some developers build test harnesses to simulate the I/O. Some commercial products like Simics offer solutions. But testing remains a thorny problem for firmware. I think the next great breakthrough in software engineering will be some product or approach that makes automated testing more tractable.
Then we'll know that done means done.
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.
|Joke For The Week
Note: These jokes are archived at www.ganssle.com/jokes.htm.
From Charlie Moher:
My boss was honest with me today.
|Advertise With Us
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .
|About The Embedded Muse
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.