Reacting to Escalation

11 Jan

In Software Industry we often have to deal with the escalations for various reasons. I often get questions from young people as why people escalate on them in spite of working for more than 12 hours a day. There are lot many reasons as why escalation happens, some people escalate due to unmet expectation, some escalate due to political reasons, some escalations are genuine, some escalations are pure fake and some are just show of strength. There could be N number of reasons as why people can escalate on you, lot many reasons are out of control and you have a hardly left with any choice other than dealing with it. What really matters during that time is how we maintain our calm and patience and deal with the situation? I have managed escalation for many years at times managing then very well and at times taken a beating and have seen lot of up and downs in my professional career . I had people who appreciated my work and there were people who wrote me off totally. So I feel I have some tips that I can suggest the people,

  • Maintain Calm and Patience. Control Emotions. Talk Less and Listen More.
  • Watch out as what your speak with others. Lot many times taking too much or giving too much explanation does more harm than good. If someone asks for explanation, do provide it, but only after negative thoughts are off your mind. Don’t reply when you are mad.
  • Sleep well and let thoughts flow off for at least 8 to 10 hours. You might feel like victim but its fine. Talk to your colleague /friends /Wife and pass out your thoughts.
  • Have confidence and belief no matter how bad things are, you will put your every effort to set it alright. You will never give up in spite of getting resistance.
  • Sometimes during tough encounter, unpleasant/Vicious meetings, it’s better to take a break and come back. I have seen lot many people going to wash room to wash the face and come back. Probably they take a break so that they can re energize themselves. It’s very good smoothing technique.
  • Accept the mistake if it’s genuine error on your side and take steps to ensure people that it will not be repeated. No Excuses.

Reacting to the escalations is all about altitude, confidence and optimism. Life nor career stops due to escalation. But yes they do provide an opportunity to improve. So improve yourself and thank to the person who escalated on you since thought you something new. At times reading the escalations is also about the wisdom.



17 Nov

Software Industry is full of blamers. We see blamers in all levels of hierarchy from Junior level personal to senior leadership team.

Have you ever heard below statement,

‘It wasn’t me. It was them. Seriously They messed it up. I did warn them, but would they listen to me?’ And on and on they go. This might sound familiar?

One of the other pattern is ‘It wasn’t me.’ and then we can feel the abnormal eye contact(intense or shifting ) and abnormal speaking tone( desperate or tight).

We can often sense a tightness and even panic in the person  who is denying responsibility – whether they are going on at length about it or just flatly denying it. So, we have to deal with their panic and avoidance, as well as the situation.

Often this blaming happens because the person finds it hard to accept responsibility for what they’ve done or to apologize for the effects of what they’ve done. Maybe they take personally what they did wrong, as a reflection of who they are (eg instead of stopping at ‘I got that wrong’, they automatically add something like ‘… so it proves I am stupid, again’). Maybe they’ve suffered punishments in the past for making mistakes,and are avoiding the possibility of punishment again? Maybe they’ve been told that it’s a sign of weakness to apologize or accept responsibility? Whatever the reasons or the causes, their blaming seems almost like an automatic reaction.

Whatever organization we’re dealing with – a team, a business,a hospital, a school, a family – the key is to establish a safe culture of responsibility-without-blame. This is easy so long as we focus on future activities and leave people’s identities
(ie who they are) and feelings out of the equation. (This might puzzle or even shock people who’ve been used to blame and punishment, so be prepared if they need a bit of time for it to sink in.) We hear a lot about establishing a ’blame-free’
culture, but how can it be done? below are some tried and tested

  • Break the pattern of protestation by interrupting them if necessary. Stop them ‘doing’ blaming, however they do it.
  • Focus on the future, and what needs to happen.
  • Try ‘Forget what has happened; what exactly needs to be achieved?’
  • You may need to give them time to come back to you on this, but when you have the outcomes clearly agreed, you can then ask them, or agree with them, how exactly the outcomes could be achieved, and by whom, by when, and
    with what resources and support.
  • Learn by reflecting: ensure that each person involved thinks about what they’ll do differently as a result of what they’ve learnt from this episode. Some people will benefit from doing this one-to-one. Some teams or groups will benefit from doing it together. Or a combination of the two might work. (Not only does this reflection enhance the overall learning of the individuals and the team, but also it demonstrates that punishment is not necessarily the best way to function.)

One of the reasons I am writing on some of the soft skills is that we need to create awareness about soft skills. We often ignore soft skills but they are very essential part of the job and life.

Different types of Difficult People

7 Nov

If you are working hard, putting lot of efforts and still you believe that you are not able to keep people or your management satisfied, then probably you are dealing with difficult people with thick skin.Over the years working in various programs and projects, I have observed that few project with much more complex technologies , I was able to deliver faster and with excellent results  and than there projects which were on darn simple technology , yet I faced many sleepless nights delivering those. When I think about those projects which went smoothly than those which did not go, I see that projects which did not go smoothly were having a project stakeholders which were very difficult people to deal with.There were always nagging even for the smallest miss for various reasons. So I am going to write about different types of people who exhibit different behavior, probably we can categorize people based on their behavior. Below are the different types of people with different behavior.

The Tank: Pushy and ruthless, loud and forceful, or with the quiet intensity and surgical precision of a laser, the Tank assumes that the end justifies the means. If you are in the way, you will be eliminated.

The best example of these kind of people I have seen are onsite delivery folks of the service providers.They will do anything and everything to keep their clients happy and satisfied no matter even if means doing bending the rules.They believe that its their job to keep clients happy at all costs.

The Sniper: This covert operator resents you for some reason. Instead of getting mad, he or she gets even by identifying your weaknesses and using them against you, through sabotage, gossip and putdowns.

Office Colleagues are the best example for snipers. I have  N number of times in projects team members complain about each other or doing gossips.

The Grenade: This person explodes in tantrums that seem disproportionate
to the present circumstances, sending others ducking for cover and wondering what it’s all about.

Some of the cases for Grenade I have seen with sales folks.Even for the smallest miss, they create lot of noise.

The Know-It-All: This person knows 98% of everything. (Just ask!) Know-It-Alls will tell you what they know—for hours at a time!—but won’t take a moment to listen to your “clearly inferior ideas.”

Most of the senior level folks fall in this category. We do expect senior folks to know it all.

The Think-They-Know-It-All: Although these people don’t know that much, they don’t let that get in the way. If you don’t know much about what they’re talking about, they may mislead you into trouble or throw a project off track.

Most of the fake candidates show these kinds of behavior.

The Yes Person: Quick to agree, slow to deliver, the Yes Person leaves a trail of unfulfilled commitments and broken promises. Although they please no one, Yes People over-commit to please.

Probably I belong to this category. My wife says that I always say Yes to everything and then don’t keep the word.Probably people who have worked with me will also agree to this.

The Maybe Person: When faced with a crucial decision, the Maybe Person keeps putting it off until it’s too late. Finally, there comes a point when the decision makes itself. Then it’s nobody’s default but his or her own.

Most bosses in IT companies fall in this category. They avoid fixing things till it breaks completely.

The Nothing Person: You can’t know what’s going on because the Nothing Person tells you nothing—no feedback, verbal or nonverbal.

Folks working in Strong IT functional organization exhibit this behavior. They will not open their mouths no matter what you do until they see they some benefits out of your activity.

The No Person: This person says, “Every silver cloud has a dark lining” and “I’m not being negative, I’m being realistic.” Doleful and discouraging, the No Person drives others to despair.

There are few folks who are straight forward and will convey the decision with  bold No.

The Whiner: These people wallow in their woe, whine incessantly,and drag others down with the weight of their generalizations that nothing is right, everything is wrong and its always going to be that way unless we do something.

Most of the people including myself at times whine about activities or environment which are not favorable to us. Majority of the people I have seen are whiner.

Since IT business is mostly about dealing with people and their behavior , I believe every IT Engineer should have some basic information about human psychology.In  some cases , it helps a lot.

PS: The source of this article is Dr Rick and Dr Rick Brinkman.


Checklist for Troubleshooting Web Application in Internet

6 Mar

One of the hard things of troubleshooting the production issues is to identify the root cause of the issue. When the application is deployed in the open internet and accessed by the variety of the browsers, and has large number of hops in the network, it becomes quite a challenging task. So in this post I will walk you through the list of things which needs to be checked at high level on client side in order to identify the root cause of the issue and before proceeding to do the review of the code base.

Browser Setting

  • What is the proxy setting of the browser, does it access the application via proxy or connection is directly to the internet.
  • How is browser configured? Does the user have administrative rights or he has basic rights on the browser settings.
  • Is the browser configured to show user friendly messages? If Yes than can we reproduce the issue by removing those user friendly messages and just displaying the actual message which application is throwing.(Please note if your application does not do proper error handling, there exists a risk that you are displaying nasty code to the users. E.g. Famous yellow screens of the .net)
  • Is the browser configured to run in standard mode or compatibility mode? This point applies to IE. (Ajax and UI Issues are most often related to compatibility mode)
  • In case the issue is related to certificate, then checking whether the relevant certificate is present in trusted store often helps.
  • If your application uses popup windows to display some information, then checking if there are any add on or setting in browsers which is blocking pop ups also helps. Some browser add on silently block pop ups without giving any information to the users.
  • Is the browser setting on default? These are the setting which is factory default. One of the easiest ways to troubleshoot issues is reset the browsers to default setting.

Client Computer Settings

  • Is the client computer behind the firewall? If yes than verifying that it’s correctly configured saves lot of time.
  • Checking the antivirus software installed on the client machine also helps. Sometimes in case where your application uses specials character, there exists a chance that badly configured antivirus might filter out or block the incoming responses.
  • Hardware and software configuration of the user’s machine. In case if your application does lot of heavy lifting on the client side, then it often helps to educate the users that minimum configuration needs to be met.

Network Infrastructure and configuration

  • Is the network correctly configured? Using the bidirectional ping command often helps to identify the network issues.
  • Is the client able to resolve the application host name correctly?
  • Checking how many hops the user needs to make to connect to the server also helps
  • In increasing user experiences. General Thumb rule I often use is more the hops user does to connect to the server, more the response time he is going to get.
  • Is there any load balancer or firewall between the server and client? If yes than checking if they are correctly configured also helps.

User access or Login Issues

  • Is the user giving the right credentials and if yes then checking if server is doing correct validation of credentials also helps.
  • Is the identity and access validation done by application or by third party component like Site minder? If by third party, then checking the third party component in isolation often helps.
  • Does the user have appropriate access level to access the resources? If yes then further troubleshooting is required. Else its waste of time.
  • If browser is client, then disabling friendly error message settings in browser will reduce the time to identify the issue by almost 50% since no extra debugging tools are required unless the case if of missing or stolen headers.

Compression,Decompression,Mobile Performance and LoadRunner

4 Feb

Recently I inherited some of the  LR scripts from one of my colleagues,it was all about building the json calls for stressing the backend spring security framework which was first layer of entry into the mobile infrastructure.Those scripts were simple scripts  built using the custom request with json string as a body part.One of the things that really surprised me as part of this effort was that web custom request in itself was taking close to 100ms to 300ms to do decompression of the server response during load testing.

Okay first let me give you some background,servers were configured to send the response compressed in gzip format with content encoding header as gzip.The functionality under scope had SLA of 1 sec max and quite a few functionality in scope also had SLA that was less than 500ms.Quite a challenging SLA’s I would say.But again these functionality were supposed to be accessed over the mobile device,so probably less the response time better it is for users.

Most of the response coming from the server for all functionality was served as chunked bytes,so what it means is that server sends initially some bytes as response in compressed gzip format,LR decompresses  those bytes in 5 to 10ms and then again server sends next range of bytes as chunked gzip response and then again LR will spend close to 5 to 10ms to decompress those bytes and like wise the process continues till we have final set of bytes.All these process happens in the single connection and connection never closes with the server.In case if you do have some server response validation in place, then expect that it will add another 10ms to do that validation.

Now I have measured all these times in the single iteration of vugen,these times increase exponentially when we are running the Load Test in controller or PC and this overhead of decoding the gzip content becomes a quite an issue when response time SLA are in ms.

Here is how it looks when you see the behavior in LR Vugen with decompression on in the script.You can see that it takes 5ms to decode the 154 bytes of response.Now imagine the normal webpage will have size of 2mb of data gzipped,so you can see the impact of this decoding  when size of page increase specially when response is coming as chunked bytes with no fixed content length from the server.



I think HP LR team might also be aware of this behavior and probably that the reason as why they might have come up with function to disable this.Use Web set option with decode content flag turned off if you are running the scripts which do not require validation and has response time SLA’s in ms.The drawback of disabling this feature is that all your correlation and other checks for server response will fail since server response will show up as binary content like below.



I would suggest you to disable this feature if you can and do the response validation by using the other techniques like verifying server logs etc.By disabling this you will gain close to 15 to 20% reduction in response time reported by LR.

Is this expected behavior of LoadRunner ?, I think they have to do this,unless they decode the response, none of the other function like web reg save param or web reg find will work and these functions are core functions of LoadRunner.Probably the right way is that LR should not add these decompression timing in their transaction markers.These timing really pollute the results specially for web applications or probably they can increase the speed of this decompression library what they are using in LoadRunner.

How to Identify Slow Running SQL Query in MYSQL 5.5x

1 Oct

From past couple of days I have also been playing around with MYSQL 5.5X Database doing some bit of writing queries, creating tables, indexes ,routines here and there for one of project. MYSQL database seems to be bit easy to understand and provides almost all similar features as provided by MSSQL or Oracle. (Of course there might be some difference in the ways they are designed or in the way they use SQL).

As soon as someone reports that application is slow or during test if we find slowness, the find thing we need to do is to identify cause of slowness (Most people don’t do this step, they become defensive, at times even I have exhibited this behavior,its humanly approach). There could be many ways to identify the cause of slowness and there could be many reasons for this slowness. However for the sake of this post let’s assume that we have identified the slowness as MySQL database and we have ruled out other causes for this slowness.

In order to identify the slow running MySQL query, one can run the below command in MySQL workbench or via MySQL client and see whats going on in the MySQL box,

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql> show full processlist\G
*************************** 1. row ***************************
     Id: 1
   User: root
   Host: localhost:51606
    db: mydb
  Command: Sleep
   Time: 372
   Info: NULL
*************************** 2. row ***************************
     Id: 2
   User: root
   Host: localhost:51607
     db: mydb
Command: Query
   Time: 58
   Info: SELECT * FROM MYTABLE WHERE auto_id = 46102


As you can see from above that Select statement in itself is taking around 58 secs to execute.In addition to above,Show Process List command can also be used to get  insights as which threads are running in MySQL server and it is quite often used to debug connection issues.This link will provide more info about this command.

Once we know which SQL is taking more time, then the next task here is to replicate the issue outside the application using the same data and same statement but with using  MySQL client. Only when we are able replicate this issue outside application, we can say that issue is with SQL Query and not with any other elements of the environment or application.In almost all cases replication of issue happens successfully.(However do watch out for those smart and excellent communicator DBA, who often share the screen with businesses to show them that in spite of querying more rows of data, issue cannot be reproduced and query executes in fraction of eye blink,in such cases ensure that we use same set of data which is used in application during the time you saw slowness along with before and after row count for the table and also all condition remains the same.)

Moving on, once you are able to replicate the issue, the next step is to identify the Query plan generated by the query,in MySQL server, this can done  by using Explain Statement,

           id: 1
  select_type: SIMPLE
        table: MYTABLE
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 47890
        Extra: Using where

In above query execution plan,any query that do not use an index signified by the key row above in the preceding output can be considered a poorly tuned SQL query. The number of rows read in evaluating this SQL statement,is as signified by the rows row,gives some indication to as how much data is read and can directly correlate to the amount of time required to execute the query. The type row with a value of ALL is also an indicator of a problem.

Adding the indexes to the table might help in these cases,but again it also depends a lot on the structure of the table, so before applying any fix to the situation, it makes more sense to understand the table structure and amount of the data the table holds,

Below command will give you the information about table structure,


The above statement will provide you the information about the table along with all column information.Once we understand the structure of the table it becomes quite easy to apply and try out various fixes.Below command will give you information about data length and other various table information


Both the above commands gives us very interesting information and this information can help in doing sizing of the databases along with capacity planning.

Once we have all these information, we can start working on applying fixes.Maybe after I fix some of my tables, I can write some more interesting things to do.




Dealing with Browser’s back Button with Headers and Javascript History Object

28 Aug

Quite often while coding application which has lot of forms in it, there comes a requirement where in developers needs to deal with back button functionality of the browser.Disabling the back button with Javascript is one of the options used by many sites to deal with duplicate submission of forms.

Browsers maintain information about pages visited in the browser’s history and Javascript can be used to manipulate the history using windows.history object.

Some of the methods which we can use to know more about history are.

This works exactly as back button of the browser.Goes 1 page back.
This works as exactly as forward button of the browser.Goes 1 page forward.
The number of pages in the history stack of the browser can be determined reading its length property,
We can go back and forth in the history  identified by using current position of the page,
go function is used to load relevant pages from the history. go(-1) loads the 1 page backwards from the current page and go(1) moves the browser 1 page ahead from the current page.
HTML 5 History object also provides good way to deal with History management of the browsers, some of the functions in HTML 5 are as below,(Reference: Opera Dev Library)
  • window.history.length: Returns the number of entries in the joint session history.
  • window.history.state: Returns the current state object.
  • window.history.go(n): Goes backwards or forwards by the specified number of steps in the joint session history. If the value you specify is zero, it will reload the current page. If it would cause the target position to be outside the available range of the session history, then nothing happens.
  • window.history.back(): Goes backwards by one step in the joint session history. If there is no previous page to go to, it does nothing.
  • window.history.forward(): Goes forwards by one step in the joint session history. If there is no next page to go to, it does nothing.
  • window.history.pushState(data, title [, url]): Pushes the data specified in the arguments onto the session history, with the given title and URL (the URL is optional).
  • window.history.replaceState(data, title [, url]): Updates the current entry in the session history, with the given data, title and URL (the URL is optional)

History object of HTML5 gives us the tool to push/replace the url in the browser’s history and its this feature which I believe is somewhat in secure in nature.Maybe we can have some warning message whenever some scripts wants to read or write the history of the user’s browser exactly the way geolocation api’s work.

Anyways coming back to our topic, we can also use the javascript to control the behavior of the back button,one of the ways quite often used is

function disablebackbutton()
This is most ugly way of dealing back button problem.Just disable it on onload and onpageshow events.

Another clean way of dealing with back button issue is tell browsers not the cache or store any information of the page in its history and this can achieved by setting appropriate headers.With Servlets and JSP , this can done  by

    response.setHeader("Pragma", "no-cache");
    response.setHeader("Cache-Control", "no-store");
    response.setHeader("Expires", "0");
    response.setDateHeader("Expires", -1);

These headers can be added to any page which requires that it should not be cached or reused in any way.I did go via header’s approach did resolve the back button issue.Now whenever I use back button I get Page expired message and for some pages form values are not pulled out from cache.

I would suggest going via header’s approach as this can be done at server side and has very limited or low dependency of the clients and most browsers honors those headers.

Technorati Tags: ,,,
%d bloggers like this: