|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at firstname.lastname@example.org. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
October 7, 2019
What is the proper brace placement rule? Should we use tabs or spaces? If spaces, how many?
Teams fight holy wars over these issues when they really don't matter. What does matter is consistency: we all follow the same rules, all the time.
If there was one change I could make in too many teams, it wouldn't be helping them learn the intricacies of the language or mastering their tools. It would be to instill discipline in their processes.
As one who grew up in the Vietnam era sporting long hair and a disregard for norms it pains me to say this, but half a century of engineering has taught me that without discipline it's impossible to get consistent results. If you violate the voltage levels specified for a part the system might indeed work, but probably not over temperature. Most engineers would give the evil eye to one who ignores absolute max ratings; in the EE world we've learned that reliability results from following the datasheet. Obeying the rules. All of the time, without exception.
Too many of us haven't learned this lesson on the firmware side. One of my favorite questions is "do you have an enforced rule about X", where X can be any of a number of ways of building systems. They answer is nearly always no. There might be a vaguely-understood rule, but that's generally ignored or forgotten.
Software is hard. It's one of the newest branches of engineering, and as such, there's a lot we don't know, a lot we're still inventing. But there is a lot that we do know, and we ignore those teachings at our peril.
Joe uses tabs; Jill three spaces, Max two. All are working on the same project and the code starts to look like something created by the denizens of Babel. But Joe really likes tabs as it's a single keystroke, so why follow rules codified in a standard somewhere?
Or, we do try to do code inspections, but, jeez, we're busy, Bill is on vacation, the boss is screaming. Yeah, the process says inspections are required for all work products, but who pays attention to those rules?
We need a defined process, a standardized way we go about creating our software. There are many processes, not one is the golden standard. A team of 1000 has different needs than a group of two. But my experience is that absent a reasonable process it's impossible to consistently generate world-class code. (And most teams have no idea how close to world-class their products are, as few take any sort of measurements. Measurements should be part of the process to quantify success or failure.)
And then we need discipline. Follow the rules! Given the vast quantity of data we have about the efficacy of the components of various processes, it's border-line insane to cheat.
Discipline does not imply a nightstick-wielding Stasi sergeant. A team lead should encourage compliance, and simply not accept code that violates the process. We're all human, and we'll drift away from doing the right thing unless held accountable.
In the early 80s I wrote several compilers. The oldest modules are in all capital letters as my development system didn't support lower case. Indentation was erratic, commenting less than ideal, as I was young and stupid. Later modules are much better and decades later I still take a lot of pride in those. How I wished I'd been smart enough – disciplined enough – to consistently follow my own rules early on.
Today, when I'm writing code, my overarching goal is to create something I can be proud of. Consistency is a huge part of that.
Feel free to email me with comments.
Back to Jack's blog index page.
If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
Recent blog postings:
- A Lack of Forethought - Y2K redux
- How I Write Code - Comments first, code second.
- How Projects Get Out of Control - Think requirements churn is only for software?
- 2019's Most Important Lesson. The 737 Max disasters should teach us one lesson.
- On Retiring - It's not quite that time, but slowing down makes sense. For me.
- On Discipline - The one thing I think many teams need...
- Data Seems to Have No Value - At least, that's the way people treat it.
- Apollo 11 and Navigation - In 1969 the astronauts used a sextant. Some of us still do.
- Definitions Part 2 - More fun definitions of embedded systems terms.
- Definitions - A list of (funny) definitions of embedded systems terms.
- On Meta-Politics - Where has thoughtful discourse gone?
- Millennials and Tools - It seems that many millennials are unable to fix anything.
- Crappy Tech Journalism - The trade press is suffering from so much cost-cutting that it does a poor job of educating engineers.
- Tech and Us - I worry that our technology is more than our human nature can manage.
- On Cataracts - Cataract surgery isn't as awful as it sounds.
- Can AI Replace Firmware - A thought: instead of writing code, is the future training AIs?
- Customer non-Support - How to tick off your customers in one easy lesson.
- Learn to Code in 3 Weeks! - Firmware is not simply about coding.
- We Shoot For The Moon - a new and interesting book about the Apollo moon program.
- On Expert Witness Work - Expert work is fascinating but can be quite the hassle.
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.