Haha, bugs. Tom DeMarco was fond of reminding everyone that defects are designed in and that the 80:20 rule applies to defect designers: 80% of the defects are contributed by 20% of the designers. As managers we need to find different jobs for the 20%.

Also, at one time most software defects were “off by one” errors. Was that array zero-based or one-based. Does this loop end with “<“ or “<=“ etc…

I used to joke that the more “dots” in a software version, the more likely it has bugs. This was largely true with a couple graphics card vendors in the early naughties. Vendor A had one dot (e.g. X.Y) and their drivers were rock solid. Vendor B had three dots (x.y.z.w) and their drivers were problematic. For sure the number of dots makes one wonder about their software development discipline.

In one organization I know of, the product build was always broken except at release time. It took an all-hands month to get it cleaned up, so they couldn't do releases very often and still do development. In another organization, the discipline was that the build was never broken, and if it ever did break nobody went home until it was fixed. No surprise that the latter group could deliver a complete, fully-tested product release every two weeks.

My rule of thumb (possibly channeling Lady Bracknell) is if there's more than one bug in a piece of code I can't have been awake when I wrote it so throw it away and write it again.

Anyway, I saw your comment about "Keep a tally of bugs in each function. It can be pretty informal. But that data will quickly and quantitatively show which are in the small batch of what is bad code" and it's spot on. I've been writing bugs for over 40 years, now. I can confirm that even if this informal way is to remember "hey, I was here last month for something similar" then you are on to something. Likely bad code (not just an obvious '<' that should have been '>').

I think one reason folks don't just dive in and fix "bad code" is that someone else might have written it. One of the hardest things to do is to rewrite someone else's code. We tend to think they were more clever and/or better than us and if we could just spend a little more time figuring this out, all will be obvious and the universe will be aligned. I can absolutely state that this is true less than 10% of the time. Heck, haven't we all experienced the feeling of "what idiot wrote this" only to later recall it was ourselves?

I know I write much better code than I did 40 years ago. Heck, I write better code than I did even one year ago. We all learn (or should) and improve in any number of ways. So a bug in a module/function/method is an opportunity to clean it up, not patch it when it's obviously "bad." Even in mission critical code the time spent rewriting is always less than debugging/patching/debugging/hacking/debugging/rewriting. The rewrite should be on the smallest failing unit possible (unless there is a larger project to rewrite large sections) but I've found that it's often the most time-efficient way to get past the problem.

The last weeks I've been involved in a project which has had me thinking a LOT about designing in a way that makes debug and verification easier, and certain things keep coming back which I wanted to share. To be honest a lot of this is stuff which I thought was a bit basic, but as I find myself discussing this with other (not inexperienced) engineers, maybe it's not as self-evident as I thought. Anyway.

1. Modularity and encapsulation. I came across a piece of system design where (essentially) the inner workings of devices (like memory maps and file system info for FLASH storage) are exposed across APIs and comms channels. My gut tells me that this isn't great, but I have difficulty in explaining why. My design approach for this would be to design the API by *function* and hide low level stuff behind the interface. I think it is much easier to test, and also to do logging at system interfaces, so when things go wrong, far easier to diagnose. (There are no other reasons like speed or whatever that go against this.)

2. Debug output. I don't mind loggers that use the USB channel which is also used for programming (and these days, often for power too) as a first up solution. But when I am going to be spending a lot of time designing and debugging and there is a spare UART and associated pin available - give me that every day. Especially when you have several boards that are supposed to be working together and don't, and every time you run a new test you have to reconnect every damn terminal. A dedicated UART out with your favourite terminal on the end just stays up as long as the host is up, even when you power cycle the target. Saves a lot of time in the end.

3. LEDs. Please please HW guys - give me at least one LED. You can find the space. When other stuff doesn't work or you are in the bootloader with no debug - a simple LED can make such a difference ... oh and by the way, bring a bunch of those "spare" GPIOs out to something I can solder a wire to as well.

Thanks for reading. To be honest this stuff seems so old-fashioned and trivial I wonder a bit why I am bothering you with it - but, it keeps coming up so it cannot be as universal as I think it should be, I guess. Either that or I am hopelessly stuck in the past ...