feature article
Subscribe Now

Be a Better Programmer

Fewer Bugs and a Happier Boss, All at the Same Time?

We all say we want to learn new things, but the first part of learning is admitting your ignorance. Little kids in elementary school have no problem with this. They’re learning new things every day – every minute – so absorbing new information comes naturally.

But as we get older and gain some measure of competence in our careers, our hobbies, and the world in general, we also tend to ossify. We don’t want to learn because we don’t want to acknowledge that we’re inexpert.  Learning a new language means preparing to make a thousand dumb mistakes, garbling the grammar, and sounding like a hilarious idiot to native-speakers. Learning about wine means first acknowledging you don’t know much about wine. It’s the same for electronic engineering and programming. To get better, you first have to concede that you’re not already the best. And that can be hard, especially when you’re confessing your inadequacies in front of your peers.

Doctors and priests owe a duty of confidentiality to their clients. You can tell your doctor or psychologist anything and it will never leave the room. “What happens in the exam room/confessional, stays in the exam room/confessional.” For programmers, that guy is Jack Ganssle.

Jack has made a career out of programming embedded systems, which then morphed into a career teaching others how to program embedded systems. One of the most persistent roadblocks he encountered was the belief among his clients/disciples that they already knew how to program embedded systems. It’s hard to teach something new when your students think they already know the subject.

So Jack targeted the programmers’ bosses. As a rule, the head of a large software team or engineering department isn’t an active top-notch programmer (at least, not anymore). Thus, the bosses were more receptive to Jack’s suggestions. They also had less ego on the line. After all, Jack wasn’t telling the boss how to write better code; he was telling the boss how his/her underlings could write better code. That’s less threatening.

A bit more subtly – and this was a crucial point – it was the boss, not the programmers, who often stood in the way of better code. By educating the boss and the coders simultaneously, Jack found that the development teams could produce better code with fewer bugs, all while staying on schedule and within budget. A win-win!

Jack’s “Quick-Start Guide to Firmware Engineering” emphasizes metrics and discipline above everything else. If you’re going to call yourself a “software engineer,” then start acting like an engineer. Programming is not art. It’s not something you do when the mood strikes you and your Muse is indulgent. It’s a profession, so act professionally. That means numbers, metrics, and discipline are all important.

That starts with version-control systems. Most of us are familiar with versioning systems of one type or another, but surprisingly few teams actually use them religiously. Without versioning, things can get out of hand very quickly, and the team is forced to fall back on institutional wisdom and peoples’ sketchy memories.

For many years, I conducted a survey of embedded programmers and asked them (among other things) how much time they spent planning their code, writing it, debugging it, documenting it, reviewing it, and so on. One of the takeaways was that programmers spend more time debugging their code than they do writing it. That’s just nuts, and Jack agrees.

If debugging is the act of removing bugs, then programming must be the act of putting them in. His solution is to sit down for regular code reviews. Don’t start writing code until you’ve planned out what it’s actually going to do, and then agree on those boundaries with your fellow programmers. Meet regularly to review your code with your peers. Use automated code-inspection tools combined with human eyeballs. Look for bugs in every single line of C code. Sure, it’s tedious, but so is debugging. Bring pizza if that helps.

Error handlers are the worst. They’re designed to catch hardware failures, software failure, or operator failures, yet they’re rarely tested very well. Over the years, Jack and others have found that error handlers have, ironically, a higher failure rate than normal code. Comb through your error handlers with all the automated code-coverage tools you can find.

Spend like a drunken sailor. Really. Programmers are expensive, so anything you can do to cut the amount of time they waste on debugging and head-scratching is money well spent. Forget $1000 code-development tools; spend $10,000. Heck, if you can find a $50,000 tool, buy that, too. It’s a drop in the bucket compared to what it costs to feed a team of programmers working overtime before a shipping deadline.

Back when I had a real job writing code, I ignored about half of the warning messages my compiler would spit out. I mean, it complained about everything. I routinely skipped over the first 40 warnings or so, because they were always the same: nit-picky complaints about syntax or references or variable names. The same warnings popped up every time and just became part of the background noise in the process. I wanted to find the real mistakes. The warnings were just the compiler company showing off that they knew the ANSI C standard backwards and forwards.

You know what? I was wrong. As Jack points out, you should strive for completely warning-free code. For starters, that eliminates even small lapses of sloppiness. It also enforces rigor. And it keeps every programmer’s code consistent with everyone else’s, because if you’ve all got the same compiler looking over your shoulder, you’re all going to write equally squeaky-clean code. But most of all, warning-free code helps you (and the person who eventually takes your job) years later when you recompile that code and wonder, “was this one of those ‘okay’ warnings that I could ignore, or is this a new warning that I need to fix?” Today you can remember to ignore the first 40 warnings, but tomorrow you won’t remember if it was 40, 39, or 41. Better to have zero warnings and treat any that do pop up as significant.

Finally, leave your programmers alone to do their work. There is definitely a creative aspect to programming (as with other engineering disciplines), so it’s important to leave the talent pool alone with their thoughts. Don’t invite them to marketing meetings. Don’t pop in to ask how it’s going. Don’t pair them up in cubicles in a noisy open room. Don’t phone them, don’t email them, and don’t interrupt them. Give them a relatively private space and make sure they believe it’s a private space. Humans and other animals get stressed if they think they’re exposed, so the expectation of privacy is just as important as the reality. “This is a programming zone. Stay the hell out.”

In the end, you’ll have happier programmers (or be a happier programmer). If Jack’s observations are any indication, you’ll also have better code. It’ll cost less to produce, because everyone involved will be spending their time more productively, with less debugging. And the schedule may even improve, since debugging is such a time-sink. Maybe spend the savings on pizza. And art. 

2 thoughts on “Be a Better Programmer”

  1. “Spend like a drunken sailor” If only. Anecdotal evidence is that even the few hundred dollars for Lint is too much. A Green Hills presentation at ESC some years ago, told of asking a programmer what would improve his life. He said a second screen for his PC would make him considerably more productive, but management refused to pay for it. In the next room the hardware guys had diagnostic equipment that stacked up to hundreds of thousands of dollars of investment.

    Programmers don’t help themselves though. “If it compiles that’s fine” is one of the most widely held views. Linting/static code analysis/code reviews are all just management inspired ways to control the creative flow of the free spirited coder.

  2. Programmers put the bugs in. So they should get help where possible with tools and training to minimize. One way is to have a very rigid structure across the whole group.
    On LinkedIN there was an interesting discussion, and some said: I want my programming freedom – so the freedom to put the bugs in?? As others pay for the repair? So all of these companies do not support the green movement period.
    There is a niche group of programmers: The ones using Forth – the secret weapon if projects get stuck. MPEForth steps in on projects using own software, HIDECS gets involved if intrinsically safe is a requirement, e.g. in medical, nuclear … Paul did a nice paper many years ago http://www.forth.org/forth_coding.html The same rules apply to any language. The updated version we only send out on a personal level by email, epldfpga@aol.com.
    The issue somehow starts with the C compiler – there seems to be no way to have a certified C Compiler – only certified C code.
    With Forth you can. And experience shows that software project times are shortened by 5 to 30%.

Leave a Reply

featured blogs
Mar 29, 2024
By Mark Williams, Sr Software Engineering Group Director Translator: Masaru Yasukawa 差動アンプはã1つの入力信号ではなく2つの入力信号間の差にゲインをé...
Mar 26, 2024
Learn how GPU acceleration impacts digital chip design implementation, expanding beyond chip simulation to fulfill compute demands of the RTL-to-GDSII process.The post Can GPUs Accelerate Digital Design Implementation? appeared first on Chip Design....
Mar 21, 2024
The awesome thing about these machines is that you are limited only by your imagination, and I've got a GREAT imagination....

featured video

We are Altera. We are for the innovators.

Sponsored by Intel

Today we embark on an exciting journey as we transition to Altera, an Intel Company. In a world of endless opportunities and challenges, we are here to provide the flexibility needed by our ecosystem of customers and partners to pioneer and accelerate innovation. As we leap into the future, we are committed to providing easy-to-design and deploy leadership programmable solutions to innovators to unlock extraordinary possibilities for everyone on the planet.

To learn more about Altera visit: http://intel.com/altera

featured chalk talk

ROHM's 4th Generation SiC MOSFET
In this episode of Chalk Talk, Amelia Dalton and Ming Su from ROHM Semiconductor explore the benefits of the ROHM’s 4th generation of silicon carbide MOSFET. They investigate the switching performance, capacitance improvement, and ease of use of this new silicon carbide MOSFET family.
Jun 26, 2023
31,531 views