Today I met some old friends of mine. They were colleagues about 10 years back when I used to be in the performance management field. I was almost thrown into this field. The job was to benchmark the performance (response times) of web applications when they were used by hundreds (or thousands) of concurrent users.
Now the fun was to not only test the applications but also to tune the applications.
Now the applications were often slow, no matter how best of breed the hardware was, the software vendors were or the tools (like database) used were. And each one would point a finger at the other. A good performance tester would find out whether there was a problem and where the problem was and recommend what needed to be done to fix it. The most elementary recommendation would be to throw more RAM / processor / server into the configuration. In many cases this would not solve the problem.
And here I was asked to handle a project to test and tune the website of a well known bank in India. Sure, enough it was a disaster. Meaning I did not know how to tune it.
Finding out that the website was slow was easy enough. But I could not digest the fact that an external entity like my team (meaning people who had not written the software) could find out why the site was slow and what specifically needed to be done to fix the problem.
Two of the colleagues I met today were people whom I had recruited. The first person was not employed when he had applied for a job. He was very talented, very quiet, very competent. I picked him up immediately.
The second person was a database specialist. He was also out of a job when he applied for a job. At that time we were going through a tricky performance problem in a database. I said he could have the job only if he could fix the problem. He took up the challenge, postponed his trip down south to the village to be with his family. And fixed our problem and got the job.
In the initial days, we were all learning how to tune a software. It's much like being a doctor or mechanic. You have to know what to look out for. And to be able to zoom into where the problem is. And find a solution to fix the problem.
Over a period of a year, I learnt what not to do. And that was to NEVER to give good practices as recommendations.
Let me explain.
When you go to a doctor and say you have cancer, would you like it if the doctor looked at all the reports and said "go eat an apple everyday"? Good practices are useful before a problem occurs. After a problem occurs you are interested in doing few specific things to fix the problem and not in following good practices.
A good doctor is one who conducts the fewest number of tests and fixes your problem fast. A bad doctor is one who gets umpteen tests done and finally tells you to pray.
These colleagues and others in the team and I got to be better over a period of a year by which time we were cocky enough to say that we could improve the performance of any application by 2x factor (meaning twice).
During that time another guy whom I met today was in love with a girl. The girl's parents were dead against him. We helped our colleague to go to the town where the girl was and pick her up and whisk her back to the big city. Even now I cannot believe it. It was almost like in a movie.
Today I asked him how the girl was whom he stole from her parents. He blushed and said she was going good and that they have a daughter. And that he keeps telling his daughter to not ever run away with a boy.
Yeah right.
Old memories.
No comments:
Post a Comment