|
|
||||
You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email. |
||||
Contents | ||||
Editor's Notes | ||||
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. |
||||
Better Firmware Faster Seminar | ||||
No ESC East? No Problem!What? No Embedded Systems Conference this Fall in Boston? Instead of spending a week at the cancelled ESC, come to the public version of my one-day Better Firmware Faster class near Boston November 1. It will be held at a hotel near Routes 90 and 495, about 38 miles from Boston's Logan airport and 39 from TF Green (Providence, Rhode Island). This is the first public version of the class in two years. This is a very fast-paced (and fun!) full-day course that teaches better ways to produce firmware. I'll show how to drastically cut bug rates and shorten schedules. Plus, I cover technical issues that are unique to embedded systems, like dealing with real-time issues. The average IT shop removes just 85% of the system's bugs prior to shipping; firmware companies get 95%. We embedded people do much better than the rest of the software industry! But 95% means we're still shipping with 3 to 4 bugs per thousand lines of code. We can - and must - do better. Studies show that fewer bugs nets faster delivery. That's what this class is about. There's more information here, and this is the course's brochure. Seating is very limited so sign up today. |
||||
Quotes and Thoughts | ||||
"Learning to program has no more to do with designing
interactive software than learning to touch type has to do
with writing poetry." - Ted Nelson |
||||
Tools and Tips | ||||
Please submit neat ideas or thoughts about tools, techniques and resources you love or hate. In response to last issue's discussion about visualizing code, Ryan Macaluso wrote:
A number of readers mentioned UML, and Dave Meekhof mentioned Miro Samek's tools. Rich Hardenstein uses an open source visualization tool called Gephi. He included a fascinating .PDF he created with Gephi that shows how Internet RFCs containing the string "IPv6" are related, but it is too big, and too deep, to include it in the Muse. |
||||
What I'm Reading | ||||
The demise of vacation bodes ill for American workers. |
||||
Old Eval Boards | ||||
Last issue I relayed a question from a reader about what we can do with those big stacks of old eval boards that pile up. Bandit wrote: John Johnson suggested:
Steve Karg donates them to a robot club:
|
||||
Small Parts | ||||
The title of this section is "Small Parts," which immediately made me think of a great source for small mechanical bits and pieces: Small Parts Inc. Another fabulous place to get just about any kind of mechanical component, from bolts to metal stock to welding gear, is McMaster-Carr. I order from them constantly. If you're in the USA and within 150 miles of one of their warehouses, have the parts (which are always in stock) shipped UPS ground. It's cheap, and they show up the very next day. But those non sequiturs aside, electronic parts sure are getting small. A couple of linear voltage regulators showed up from Analog Devices last week. These ADP172 devices come in Wafer Level Chip Scale Packaging (WLCSP) and are truly tiny. They measure 1 mm square and have just four connections: Similarly, NXP just announced their LPC81x series, which are ARM Cortex M0+ MCUs in, among other configurations, an 8 pin package. Alas, that's a DIP, which is nice for experimenting, but not so great for production. I believe Microchip still wins the smallest MCU award as they offer parts in a 6 pin SOT-23 configuration. In the "bigger is better" department, a friend called the other day wondering if I had any low-voltage inverters laying around for a quick experiment. Nope. So he realized he had two options: order a $0.20 part and pay a minimum order amount, plus shipping, and wait for delivery. Or, use an MSP430 16 bit CPU eval board he had. Think about it: not that long ago no one could afford computers. Now we consider using them to invert a single digital bit. |
||||
Do The Math | ||||
We're all superprogrammers. Or at least perform in the stratospheric top quartile of developers. Maybe Joe Coder down the hall is "average," but us? We're the tops. Somehow we make this assessment based on a qualitative feel driven more by ego than hard data. Nothing costs more than firmware, yet no other industry manages productivity so poorly. That used car salesman with the crooked teeth and untrustworthy smile watches his sales numbers like a hawk. The widgets we design are manufactured in a facility that tracks defects, rework, worker productivity and more, usually with graphs posted in the halls so everyone knows just how well things are going. But us? We'll work hard. Real hard. It'll be done when it's done. Many classical software estimation techniques naively yet wisely expect developers to design the software, decompose it into modules, and then figure the number of lines of code for each module. Then we solve one of the most interesting equations extant: Schedule = (lines of code) / (lines of code produced per month) ... when no one has a clue as to the size of the second term. Is it 50 lines/month? 500? 5 million? At this point the usual chorus waltzes in from stage right to complain that "lines of code" (LOC) is a very poor metric, subject to huge variations depending on styles and more. Academics, especially, fault the LOC metric and generally advocate some form of function points as a replacement. But, in industry, no one uses functions points, so if I tell you a routine will be 50 FPs you'll have no gut feel for the module's complexity. If, on the other hand, I tell you it's 2500 LOC you'll have that visceral understanding of its complexity. If tomorrow a charismatic leader took over the country and told us all gas mileage calculations will be figured in furlongs per dram, well the numbers will be just as accurate as liters/kilometer or gallons/mile, but will baffle consumers. Familiarity has value. Oddly, the literature is full of conversions between function points and LOC. On average, across all languages, one FP burns around 100 lines of code. Sometimes the Function Point debate is merely FUD tossed in to avoid the real issue -- that of measuring something, anything to get some kind of assessment into our productivity numbers. There are many ways to measure productivity; two companies I know quite literally monitor network traffic to log keystrokes per hour. Those engineers write a lot of long-winded comments. Why take such data? If we're lucky enough to have the time to decompose a problem into subunits and LOC before estimating, then the numbers give us a reasonable shot at coming up with a realistic schedule. Barry Boehm has shown us that the schedule is proportional to the number of thousands of lines of code raised to an exponent. His Constructive Cost Models (COCOMO and COCOMO II) gives various exponents and scaling coefficients to predict development time of various kinds of software. But even when we're just furiously coding to a capricious deadline tracking LOC/hour tells us, when measured over the long term, if we're improving, or just stagnating at our efforts. The Wal-Martization of software development means Joe Coder sitting comfortably in downtown San Jose is competing directly with a very smart, highly trained developer a half a world away, thrilled to work for just a fraction of Joe's salary. If we're not constantly becoming more productive we'll be retreads on the grinding wheel of global business. Track LOC/hour, measuring total time invested from the beginning of the project till the day it's finally done. That encompasses a lot more than coding and debugging... but all of the other development activities are real costs more or less proportional to the size of the project. Track project size as well. You might crank 200 LOC/month on a 100k LOC project, but your rates will be much higher for smaller systems. And log bug rates. It's easy to write lots of buggy code fast. Artists work by feel. Engineering is about collecting and understanding the numbers. |
||||
Jobs! | ||||
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. |
||||
Joke For The Week | ||||
Note: These jokes are archived at www.ganssle.com/jokes.htm. Thomas Osbrink sent this bit of brilliant engineering:
|
||||
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 jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. |