You’re different and that’s BAD!

Blog Post created by ArpiJakab Employee on Jul 9, 2014

It’s a completely inappropriate children’s book title, but fitting for enterprise software.


My code is my baby—I’ve conceived it. I’ve even nurtured it through sleepless nights. I want it to grow up and play nicely with others. When it runs around in my dev environment, it behaves perfectly. However, when it goes off to the testing environment, the trouble starts. I start hearing stories of misbehavior and admittedly, I’m quite incredulous. How can it be? I know every single line of this code and I’ve tested it locally; I know it works. Earlier in my career, I may have even cast a few askance looks at my QA colleagues who badmouthed my baby. I was in denial.


Over the years, with some resignation, I have faced the fact -- my baby behaves differently when it’s not home -- and this is BAD! But what can I do? It’s all grown up and out the door, hanging out in strange new environments with testing folks who are paid to give my code a hard time. As I struggled to recreate the testing environment and steps to reproduce the bugs, I was failing to deliver on stories that I had committed to at the beginning of the sprint.


Brace yourself... here is my pitch for a more pleasant and productive way to write software.


Step 1 - Ask your operations folks to attach a CA Path Finder agent to each application server in your staging environment.

Step 2 - Write and test, business as usual.

Step 3 - A business transaction failed or is reported slow in the test environment, a.k.a. bizarro world. No problem, open up the CA Path Finder web UI and lookup the failed transaction. Examine the details of each captured call and trace the details of the failed business transaction through all the tiers of the application. Use Path Finder to examine exceptions and to log messages both in the context of a business transaction path.

Step 4  Fix the bug, move on to other stories and finish the sprint strong!



You may be thinking -- sure this will work for some bugs, but what about mandelbugs and heisenbugs? True, we have a debugger for a reason: some bugs are tough and need heavy duty root cause analysis. There may not be enough details in the captured business transaction details to deduce the exact cause of the bug. With a few extra steps you can use Path Finder to generate a test that you can use to reproduce the bug in your code on your dev box. Your code depends on backend systems -- if these are not available, use Path Finder to generate virtual services to fill in for the unavailable backend systems. You have your app and the virtual services running, attach the debugger, run the test and debug as usual.

As developers we can’t anticipate and test every scenario our code will experience in the wild.  A more productive use of time is to precisely monitor how code behaves differently in other environments. With Path Finder, you can be more involved in your code’s upbringing.