Why add logging?

Most importantly for some activities, logging is a legal requirement, or an accounting or business requirement. In these cases it will be in the requirements.

Unless you are leaning over the shoulder of every user of your software, you do not know what they are doing. Logging is another way to see. Profiles of your users are sometimes a valuable corporate asset (e.g. selling advertising space when you know you have a lot of users). Assuming the development team is responsible for service availability, knowledge of and quick response to any problems is highly useful.
During testing, knowledge of point of failure before segfaults is really useful. Yes, these do happen in higher-level “no pointers” languages. Secondly on larger systems a regular log markers can inform about execution time and bottle necks. These should be disabled in production.

Why suppress / hide logging ?

The automated reporting of minor lint type notices is of little value, at runtime. For development builds this is useful, but no later in a products lifespan.
Likewise logging on any scalable server code needs to be lean and buffered to avoid locking to the server with disk writes. Logging to a DB can scale up this ability, and is much easier to search/report against.
Writing stateless software reduces the need for logging, and provides a list of other benefits. Stateless logging is fundamentally useless in retrospective review, e.g. a message of “Order placed” is stateless; but “Order for 4 royal-blue armchairs, delivery date 12/12/2016” is stateful. Stateless logging can be useful for the developer is watching a test build directly; but this is better done in unit tests, so again is not a solution. Thirdly logging is needed most when the code is poorly structured. Reasonable code structure reduces the need for this, as well as many other benefits.
As a general statement, if the logging output is a lot of data and no information; it is not meeting requirements or being a solution. In this case its useless.

How to add logging

You are likely to be using a framework, it is likely to have a log facility. As such you don't need to create this technical feature. Learn how to manage this, and ensure it is disabled on production.
Where logging is an objective, obviously create it. A normal pattern for transaction systems is log each state change for the transactions. This is normally described as an Event log. This is normally held in a transaction data-store, as part of business documentation/ process (and isn't a technical item).

As your code should be reasonably structured, so a few bits of logging are all that is needed for the happy path. All exception cases that require a human interaction must be documented (in the log), or the resolve cannot be applied. Exception cases that represent a data-point in a larger scenario should be logged (e.g. on the last working day of the month the entire e-commerce reports slow SQL warnings, being induced by the billing audits also being performed and blocking systems).
Logging as a low level process, is fairly low business utility. This type of logging should be created in a fashion that is cheap to apply (e.g. a text macro in your IDE), with things like code-location being generated automatically (for example in PHP the METHOD and LINE macros are quite useful). It is quite useful if it can be globally turned on/off (a test against load time defined constant for example).
Logging as a record of user actions, including timing and user id is a valuable business asset. This can be done to a reasonable granularity with google analytics on open-web accessible systems.
This text doesn't contain references, but as a piece of reasoning, does it need them?


Notes on Logging

RSS. Share: Share this resource on your twitter account. Share this resource on your linked-in account. G+

Notes on Logging

RSS. Share: Share this resource on your linked-in account. Share this resource on your twitter account. G+ ­ Follow edited