Do not get me wrong, I would rather not introduce any bugs into any code that I write. But having bugs in code is normal for any program with over five lines. From my professional experience, the real question is what is done to prevent the most severe bug and what is done to correct those bugs with respect to priority.
Let me break that down a bit. I am a firm believer that it is increasingly difficult to keep a program bug free once it exceeds five lines of code. Call me a pragmatist, but I am a firm believer in the adage “it is not if a program breaks, but what circumstances are needed to break it and how often do they occur”. As soon as a program interfaces with something outside of itself, the number of circumstances to protect against increases. Each interface adds to the complexity of features that need to be tested to have confidence that the most severe issues are properly dealt with.
Add in to that equation the common use of libraries for developing applications. They are great in that they provide functionality at a low cost, but there has to be an examination of the testing process performed against those libraries. For example, while it may be true that the current project handles file access errors properly, it is not a given that all libraries will give the project team that same level of confidence regarding error handling.
It takes a lot of testing to cover every case, in fact one could argue that the most testing can do is handle the highest impact and most predictable things that can happen. And it is a matter of balancing cost and benefit. The PyMarkdown project has perfect code coverage because of perseverance and because I believe tools should have as close to full coverage as possible. Hence, I expended the cost to ensure the high level of code coverage.
But I did not stop there. I went on to come up with a very comprehensive set of scenario tests that include translating Markdown to tokens to HTML and translating Markdown to tokens and back to Markdown. Since each rule is based upon a correct interpretation of Markdown, I felt that anything less would not be correct. And that decision has proven to be the correct decision, as over seventy-five percent of the bugs are a result of parsing issues, not rule issues.
And that is why I feel that it just feels good to fix bugs. I am firmly aware that I am human and that I am fallible. I cannot cover every scenario, and users of the PyMarkdown project find issues with their usage of the project. I am also happy to say that in all cases so far, I promise to give their issue it’s required time and I get a thank you from each person. When I fix the bug, or consider an enhancement to the project, I start a conversation with each user to ensure that their problems with the project are dealt with before closing the issue.
Call me weird, but I like those conversations. Sometimes the issue may take weeks to fix, but one friendly conversation at the end is worth it to me!
Comments
So what do you think? Did I miss something? Is any part unclear? Leave your comments below.