I was tasked with debugging an issue customer had found with a device. The issue was one where communication between two chips starts having some errors on the SPI bus. This issue appears to be isolated one or two hardware units and only occurs after about 3 hours of use.

So I got the unit and the first thing I do is run the unit to replicate the problem. Two days later I have found 3 other bugs but not the one I was requested to fix. So I am chatting with the boss and he says "Could it be that when you attached logic analyzer it changes impedance on SPI and thus the problem goes away?" At this point you realize that you have made an assumption that was wrong.

Doneness

The assumption was that I assumed everyone knew what I had learned about debugging. That is you always try to replicate bug a couple of times before you change anything. More specifically you make sure you can replicate the bug, else you never know when you have fixed the bug. That is if I can not replicate the bug, and change something and still can not replicate bug, did I fix the bug? The answer is undetermined.

This test for Doneness is the one of the most critical things in engineering. That is if you do not know when you are done, you will never be done.

Over the years I have intuitively learned this, maybe it was from all the years working on cars and fixing drivability issues with cars. It is one of those things you have known for so long and so well learned you can not perceive others do not know it. As I thought about the comment from my customer , I realized that maybe not everyone knows this concept of how to debug.

This ended up being one of those moments in life when you have the "ah ha" moments. That is data and behaviors you have been observing and not making sense suddenly become clear because you have determined the root cause of the problem. I realized at that moment why I had been so frustrated working at some former places of employment. That is I realize that project managers at these places never had consider the doneness of projects.

Sure most project managers know you should have requirements and test cases, and such. However most never considered to ask "How do we know when we are done with this project."

I would even say that several project managers actually never wanted projects to end as they were unsure of their future employment when project was done.

Was this doneness idea unique to me? That is was this something I had such an intuitive knowledge about that I assumed everyone did? So I reached out to some various engineers and asked them. As it turns out the good engineers all knew this concept. While young engineers had never considered when a project was done.

One good engineer indicated that he struggles with his team because they fix bugs through randomly changing code they think might cause bug. He indicated that they never actually replicate bug, and see if changes fix the bug, much less actually root cause the source of the bug. This often means they change code and introduce new bug and old bug.

This got me thinking how many other long held notions like doneness do I have that causes me frustrations.