Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Dec 26 '11 at 19:54

This question came from our site for professional and enthusiast programmers.

2 Answers 2

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.