The best way to clean things up is to avoid them getting dirty in the first place

Warnings are useful. You get warnings from your IDE when you write something that might be a bug. You have probably made your program print out warnings or error messages when something goes wrong.

But too often, we down in the sheer volume of warnings. Then it’s impossible to separate the relevant and important warnings from the noise.

To make warnings useful again, I use a zero-warning tolerance policy. Even if the warning is irrelevant, I fix it. Otherwise, I will have to decide that it’s irrelevant every time I encounter it. If there are warnings I just don’t care about, I turn them off in my IDE. Ignoring things is mental work, and I need to get rid of all the mental work I can.

Getting the warnings out of an existing project the first time requires some work. But it’s worth it.

In the same way, the logging messages your program writes gives you useful information about the state of the system. What happens if you watch the “error” level log of your system? Or the “warning” level? Or the “info” level?`

I don’t want anything in my error log that I wouldn’t want to be woken up for in the middle of the night. If you have 24/7 support people on your project, you might actually try that experiment: After being woken up a few times by “checking customer status” or other irrelevant messages, there’s a lot of motivation for logging at the right level.

I use the following guidelines: I should be able to watch the “info” level log of the production system tick along at the rate of traffic of the system. During normal operation, there shouldn’t be anything logged at “warning” that I don’t care about. And there shouldn’t be anything logged at the “error” level that I’m not willing to be woken up in the middle of the night for.

The best way to make sure that you don’t start getting pollution in the log is to use them. Send error logs from both production and test installations via email (or SMS!) to the development team. Look at the “info” and “warning” logs every once in a while.

When something appears that you don’t want to see, fix the code. Don’t wait for a big cleanup. Fix it right away. If it’s not your code that logs, fix the filters in your log configuration.

Warning from your compiler and from your code are useful. You just need to get rid of the noise to start noticing them.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Java, Software Development. Bookmark the permalink.

Comments are closed.