Jack Ganssle, Editor of The Embedded Muse Jack Ganssle's Blog
RSS Feed 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 jack@ganssle.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).

On Discipline

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."

Recent blog postings: