Is application logging dead, or just resting

I’ve been developing software for nearly a decade now and
application logs still is the constant struggle when creating a project. Many have started this fight with “getting it right” and some even succeeded, but for the most part project developers tend to ignore this bit until the last minute, some event further.

The initial problem with application logs is lack of any clear approach to the process. Comparing this to TDD, you have frameworks and books ready to help you make the tests write. Application logging, from the other hand, is, to some extent, part of the environment (programming language) the app is developed in. When using fancy frameworks and programming library stacks, there’s always that special library / logging API / documented approach to making things right. When developing apps in “the cloud”, there’s that fancy cloud logging service, which you definitely must use, because it’s the part of the “whole package”. The sheer amount of approach diversity and lack of clear guidance is damming at best. The worst part – this does not help in solving the problem.

So the main thing application logs help with – showing us (developers) what is actually happening in production / development / stage / testing / any other fancy environment. Don’t kid yourself, until you have the actually data from your target env. (let’s say prod), you don’t know shit about what’s going on. Despite the fact that the problem is quite common, it’s usually concealed by the amount of accumulated developers’ / user base knowledge, which creates an illusion that “everything’s fine”.

There are many thing one can do, to create confidence in thyself about how the app works. Most common would be testing procedures, implemented everywhere around the project. When the project hits that sweet 100% test coverage, we (development department) cry the tiers of joy for how awesome that is. Though TDD brings major improvements in code quality, it does not (and cannot) save you from production hiccups. There are several variables which production has different from what we are used to.

First – the work load and use cases are much more versatile in comparison to any other controlled environment. You may be able to predict most of the interaction that’s pouring into your app, but at some point in time you will miss some.

Second – your application in production will be integrated with a database. That’s a whole other segment of unknown, which does things on production. Databases were initially constructed to provide multi-user environments for data storage. Meaning, even if you test your app to work with data perfectly, some other user might not be that accurate. At some point, be it a person or automated script, your database will have a hard time maintaining peace with your app, and the downtime will come.

Doing other things, like keeping documentation, or even having your own Data Warehouse to analyze the data, is a step forward to a more controlled system. But the only truth about the processes of your app lies in your code base. Any deviation from that truth may become critical or of an issue to your customer base, to the extends which are hard to predict.

Application logs are there to help you see with the eyes of your executable code. Find places where things went wrong and manage them. The information from the app is critical to maintaining peace of mind, while supporting production application.

The hard thing to acknowledge is that there’s no single, well defined, way of doing logs. There’s no silver bullet to getting it right for the the first, second, or Nth time.

Until there’s a strong, collective desire to know what actually is going on within our apps, there’s not way we be 100% right about it.