Debugging
So, you’ve built something new and wonderful. But when you try it out, there’s a sinking feeling - it doesn’t work like you think it should. No matter, from an high-level view the design and building of software is an incremental process as you gradually approximate your goal. Initially it is through building things, later it is through correcting what you’ve built so far that didn’t work out quite as planned. This stage is debugging. In debugging we play a different role.
Earlier, I said I designed software like a the “master architect” shaping my world. In debugging, I’m exploring that world and finding what doesn’t fit. Usually, the problem is seeing what’s going on. Once I see what’s happening, the solution is usually straightforward. I almost said “trivial”, but that’s not true. It can require a lot of work to rearrange things correctly. But, it’s straightforward in that the path forward is clear.
Once in a while, things are more interesting and not so clear. Don’t wish that a software person have interesting bugs. It took me two weeks once to find one bug. This bug only happened very occasionally and was contingent on two things pretty unlikely happening together.
Turns out when the server (in this networked system) was busy, it sent the same data but in fewer packets that were larger instead of more packets of data that were shorter. The infrequent times when a full-sized packet of data was sent, it overwrote 1 byte past the end of the buffer for the packet’s data in the receiving software. That one byte was a flag byte that indicated something totally separate in the software. So, I was dealing with a highly intermittent bug whose cause was completely separated from its effect.
Software isn’t linear, that is, a small change in an software input might cause either a small change or a large change in output. It can be highly discontinuous. A small change in input might also cause a crash, or perhaps absolutely no change at all. This discontinuity is both software’s power and pain.
Debugging is detective work, a sort of forensic design. It’s tracing things and trying to see where things go from smooth and natural to off the rails. There are a number of tools useful like debuggers that allow the developer to work at the symbolic computer language, but sometimes, not often, but sometimes, you have to descend into the belly of the beast and handle the ones and zeros. Or, at least the hexidecimal (base 16) equivalent thereof.