Hackable Projects – Pillar 2: Debuggability

This is a continuation of Patrik Höglund series about how to make your software hackable. (If you have not read the first article, here is the link: first article)

Patrik Höglund continues to talk about how to make your code more hackable by going on to his second pillar of hackability: Debuggability. However here this word doesn’t simple mean running a debugger on your code and calling it a day. Höglund explains debuggability as “being able to easily find what’s wrong with a piece of software, whether it’s through logs, statistics or debugger tools.” To help with this process, Höglund goes over a few examples that help their developers with debuggability.
The first one is running your project on a local host. This way you not only get around the possibility of crashing your main servers, but you can also set up “scripts that invoke the server binaries with flags.” This helps to make debugging and developing your server a simpler process overall. Höglund then goes into how to debug for mobile apps. He suggests using unit tests here as well since they have great hackability. He then gives some suggestions for software to use for debugging on iOS and Andriod. Höglund then some tips for when debugging gets tricky.
The next step that Höglund brings up is making sure that you have proper logging.He links another article to look at, but he states that you should make sure that you are getting proper stack traces instead of going off of an error message. He also says that there is such a thing as too much logging which can lead to having your project be less hackable. The other thing Höglund brings up to make sure that you can use statistics to your advantage. If you run a monitoring system, like Stackdriver for Google Cloud, Höglund says that “tools can help you keep track of request volumes and error rates.” This lets you find errors quicker and allows you to rollback bad code as soons as possible.
The last thing that Höglund talks about is System Under Test (SUT) Size. He says that “small and focused tests aid debuggability, because when a test breaks there isn’t an enormous SUT to look for errors in,” and makes tests more reliable. He refers to this article for information about SUT.