SummerAcademy on Debugging — 1. Intro and Overall Structure
Originally published on https://www.deepcode.ai/blog/summeracademy-on-debugging-1.intro-and-overall-structure
We tried to explore the topic Debugging from various angles. It was striking to us that you can find loads of material to each aspect and sub-aspect but a collected view is missing.
Debugging — according to techopedia — “is the routine process of locating and removing computer program bugs, errors, or abnormalities, which is methodically handled by software programmers via debugging tools. Debugging checks, detects, and corrects errors or bugs to allow proper program operation according to set specifications.”
Debugging is what we all need to do (sometimes it is done in seconds, sometimes it takes days).
Sidenote: Personal story of one of us: I sign my emails with CU 0xff. This comes from back in the days when I was part of a team developing a hardware-software product and I was tasked to hunt a Heisenbug. It took me two weeks, constantly reading hex-logs of the logic analyzer. After that, I felt I could hardly remember my name and could be called 0xff; somehow it stuck. And if you don’t know what a Heisenbug is, you should keep with us.
As debugging is such an important part of our daily lives, we should give it a fair share of attention. We should know the tools, the processes available.
What is a Bug?
Generally, a bug is when the product towards users or external services does not behave as expected and wanted by the user. A bug can be functional, performance, usability, presentation (or UI), compatibility, security, i11n, or documentary — aka you can find a bug in anything a developer work with. Even worse, software sees entropy just as everything else does: If you would build the perfect system and just let it run, it cannot prevent its environment from changing which will lead over time in the degradation in the perfect system until its function would break because of external causes.
Sidenote: Personal Example: In 1998, I saw a climate chamber controller (a Commodore PET) which worked for two decades and suddenly did not boot anymore. We found, the adhesive on the sticker on an EEPROM degraded. The sticker fell off and the boot EEPROM got slowly deleted. It was irreplaceable as we did not find another complete EEPROM to copy in time.
So, we are constantly forced to review and fight bugs. Enough reasons to dedicate a SummerAcademy to it.
Summer Academy on Debugging — Overall Structure
We collected material and added our personal experience. The general structure is two-fold:
(1) Basic Elements: Tools, Processes, and People explore what is in the tool chest to help us debug. Tools are pretty forward exploring the technology such as Static Code Analysis or Debuggers helping us in the debug process. Processes lists models and best practices typically used around debugging such as Test-Driven Development (TDD) or Continuous Integration Continuous Deployment (CICD). People is another important part because, in the end, it is people doing the debugging. Here, we want to raise awareness that investment in the people in the process pays out. (2) When in Lifetime it is discovered: Here we are following the lifecycle of software to show how the above listed Basic Elements work in concert. It is interesting, as the later we get in the software lifecycle, the more expensive it gets.
Some Decisions we made…
- We made the decision to use JavaScript as our environment of choice. For sure, every developer these days need to work with JavaScript. It brings certain challenges (e.g., asynchronous execution) with it and leaves others out (such as software-hardware co-development).
- We plan to have this as a living document that we will open-source on GitHub later to invite all of you to help us writing the documentation on debugging.
- We will add videos, code quizzes, streams as we go along. Make sure to check out all resources which we will link to each other.
- While we call it a SummerAcademy, you do not need to subscribe yourself to a daily time investment (while we would highly encourage and honestly love it :-) ). You can also use the body of knowledge as a reference and pick and choose topics.
- We will point to major external sources we found interesting. We will quote and cite — standing on the shoulder of giants!
- Finally, this can be by no means complete. Rather we would like to see it as a start. If you feel passionate about something we forgot or we did wrong or we did not pay sufficient focus on, change it. We will list all contributors in a list of changes in each article.
So, let us have a look at the detailed table of content.
The Table of Content
Key Take-Aways
We have A LOT ahead of us. So, from now on through the next weeks, we will publish every day a part of the Summer Academy. We hope you like it! Let us know :-)
