Proof the feature works

When a software feature is developed, it is usually covered by automatic tests. During each build, tests are executed so we are sure the feature works as intended. But sometimes it doesn’t. Maybe the coverage is not sufficient, maybe a very specific situation happened and your software isn’t ready for it.

Your software can also be completely fine, but the user (or client) thinks it’s not. This can happen if the other side has incomplete knowledge about how the feature should behave or if there is some misunderstanding about it. In that case, no amount of unit tests will help you. You need some solid proof.

The more I work in this industry, the more I think early preparation for these situations will pay itself in the future. If you know for sure the basic element of some important feature works in the production, it will give you a good starting line from where you can start your investigation.

In most cases, you should be able to put debug logs to critical places, but too much logging will clutter the codebase. Not to mention that in order to switch logging level, you often have to restart the application (not so easy in production). But it’s better than nothing and sometimes it’s the only thing you can do.

Web applications with GUI can of course log too, but I prefer the concept of a secret admin maintenance page. For example, if your application has some important task queues, you can monitor queue status or the number of waiting tasks. This will give you proof that the queue works as expected.

The page needs to be well-secured and gathering data you want to monitor can be sometimes tricky (variables from internal private methods), but this approach has also many advantages. The maintenance page gives you easy access to all important data on production all the time. What’s best, you can shift some of the work from your shoulders by giving access to this page to the client. He will be able to check if important parts of the application are running and contact you only if something is really wrong.

You don’t even need to implement the page right from the start of the project. Just analyze the API and expose data that could be useful to monitor in the future. Or prepare a blank implementation of some monitoring service and call its log method inside other internal services. Strong encapsulation can be done this way without a need to expose the “I may or may not need this in the future“ variable by the API. When the time comes, implement the service and maintenance page.

Author: Luděk Novotný