You probably heard of the patient who went to see the doctor for a general checkup.
The doctor
examined the patient, ran some tests, analyzed results, and came back with a list
of things that
don?t look good. The patient said ?Hey Doc, but, I was feeling really good until I
walked in here.?
I heard a software version of that recently ?Hey Doc, but, this application has been
running fine
for two years.? (Actually, as I learned later, they had seen sporadic problems, but
none repeatable).
I was reviewing a multi user application and found global/static objects being used
without any
synchronization.
I
get nervous when I see static or global variables in server side applications. I
am not saying don?t
use static members. They're good for read-only information, for example. However,
in this case, the
global object, deep inside, had some variables which methods liberally modified.
Synchronization is particularly not what I would recommend in this case either. There was
really no
reason to share this object, and then end up with a need to take care of concurrency.
I know as developers we try to save resources, get convinced that some patterns and
practices are
really good to use. And they are at times. But, we need to evaluate what's right for
the problem on hand.
And, just because our application runs, it doesn't mean it's correct. That?s like
crossing the red light and
claiming it?s safe. It is safe until the day Karma kicks in. If you are lucky you
find the problem during
development and testing. If you're not so lucky, it happens at the worst possible
time in production.
