Proposed Anti-Pattern, Shot in the Dark

The purposed anti-pattern has been named “Shot in the Dark” after a conversation with Dr. Heinz Kabutz. As the name implies, Shot in the Dark describes the best efforts of a team attempting to correct a poorly performing application without the benefit of truly understanding *why* things are as they are.

Typically most performance problems are found after the application has been assembled. The discovery comes either shortly after the application has been assembled or more often then not, shortly after deployment into production. Consequently the most applicable scale for this purposed anti-pattern is Application.

The most useful refactored solution name is measure, don’t guess. Though those tasked to fixing the performance problem may come with educated guesses, they are guesses none the less. If the guess is correct, then the behavior of guessing is only re-enforced. More often then not the guess is incorrect. In these cases it is quite common that much time has been wasted fixing things that may not look right but were not at the root of the problem. The only real way to ensure to know what is causing the problem is to take a measurement. Without a measurement you are guessing.

The refactored solution type is to use tools to take measurements. As is the case with most tools, training is involved for tools to be effective.

The root causes include ignorance and haste. The first seems harsh but it refers to the lack of knowing either how to take or interpret measurements. Haste is a result of the timing of the discovery. If the application has been deployed then the deadline to fix the problem is yesterday. At this point in time it is too late for training. Without training and the knowledge that training provides, human nature dictates that developers will do what developers do and that is examine the code. However, an application is more then just code. An application is the sum total of the code, the environment in which it has been deployed, and the set of users that is services. If any element of this equation is missing then it becomes difficult to acquire useful measurements. Without any useful measurements, all that is left is a shot in the dark.

The unbalanced forces that lead to a shot in the dark is a total lack of performance management. The trap is that we are all trained and focused on performance. However that focus is often misguided. If one does not plan for performance then performance is often achieved by accident. This does not mean that one should optimize prematurely. All it says is that performance requirements need to be treated similarly to any other requirement.

• Solid performance requirements need to be stated
• One needs to think about and devise a plan for how performance requirements will be met.
• If tooling is involved in measuring then training must be planned for in advance of when it is needed.

In each statement you can substitute the word performance for business and tooling for your favorite product you can see how reasonable (obvious) these statements are. So obvious that one has to wonder why performance is ever allowed to happen accidently.

The anecdotal evidence is “The problem sounds like it is…., I think it is caused by….”. It is the inclusion of hedge words and phrases that should sound the alarm that you are about to take a shot in the dark. The only actions that should be taken in this case should be to take a measurement. A good measurement will remove the hedge words from these sentences.

tags: java  performance  antipattern  tuning