Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I write code, a certain amount of it is just for the purpose of logging, tracing, or otherwise "testing" what the program is doing. This not unit testing; this is not when it is running in "debug" mode or something similar; it is not things like assert statements that get stripped out by some compiling step. But actual production code and runtime execution for the purpose of knowing what the system is doing and writing it out somewhere. Naturally, there have to be various settings in various places (config files, admin interfaces, etc), that allow for more or less of such things. But even if all settings are at their lowest level, I still like to have my system keep track of its own state and report it in some minimalist manner that I or operations people can use to troubleshoot even without turning on/up the other settings.

So here is my question: how much of your code or system run-time do you typically devote to such permanent-troubleshooting purposes? I say both code and run-time as they are two measures: how many lines of code relative to all lines of code, because the more the code the more the maintenance; and how much run-time performance because these things do consume CPU time, however small. And there is not always a direct connection between lines of code and run-time consumption.

Personally, I'm happy to devote up to 10% of my code to such things and up to 5% of the run-time. Have you ever read any industry authorities that have an opinion on this? Who? What is your opinion?


migration rejected from Jul 28 '15 at 5:31

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by durron597, MichaelT, GlenH7, Dan Pichelman, jwenting Jul 28 '15 at 5:31

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

I think giving a percentage is too simplistic, it really depends on what you are doing. My rule of thumb is you have to put enough stuff in to be able to deal with a problem in the field (my background is system/enterprise software, so I consider programs running in a remote location). So of course you want to have appropriate logging and tracing, but what's more, you want it to be easy to use.

I put a lot of effort into capturing state when there are exceptions or other errors, because I imagine what I would need to know if this problem happened at a customer site.

I have at times put a circular buffer of past events in code so that I could figure out deadlocks. This was accompanied by a comprehensive dump of all state.

I think if you always ask yourself, how would I fix this in the field when someone untrained is operating it and I need to get all of the state I need, you won't go wrong.


In the real world we spend most of the time (and cost) in maintaining the application than developing it. So the more information you gather about the state of an application, the lower is your maintenance cost. So, I make my decision on what % of to code to allocate based on the the application type, its life cycle etc. Having said that, I just capture the metrics as the app is performing tasks so that I can introspect it on-demand rather than writing it to some persistent store. For e.g. in Java, I expose some statistics as JMX beans so that I can use the data on-demand to know the health of the application.