Monday, 30 November 2009
Are you burnt out?

We ask this question... a few hours, days moment before we make a request to our Boss for a week long vacation or just when you think that its being a full quarter and you haven't taken your holidays .... I have read and seen a lot of guys saying , talking , writing this... We are burnt out and need a break from routine... I too sometimes. But I never found out what this burnt out means... Honestly never.. when you are not very productive at work is burnt out? Or You had too many tasks in the last few months and now you dont means burnt out? or you just achieved what you were supposed to and now you are burnt out?
Tuesday, 24 November 2009
The Enterocial need!!! Can we get Enterprises Ready?
Monday, 23 November 2009
What did you miss?
Saturday, 21 November 2009
Build fast, Break fast
Tuesday, 17 November 2009
Lessons from the Recent Deadlock issues
1. A bug should be treated as immutable - It should be removed or created never fixed.
Every time a bug is created in an application it causes a lot of issues. People say we fixed the bugs.. the truth is every time a bug is said to be fixed, there is either another created or the same one removed. Don't ever think of a fix actually fixing the actual problem.
2. List down the problems , don't fix them yet
We usually mistake by finding one problem and starting to fix it. A better approach is to generate a huge list of problems in 3 orders:
1. Actual Problems
2. Potential Problems
3. Past problems in the same area
Prioritize it with 3 different sets of people... QA, Dev and Project management.. generate a list and then start working on them. In the meantime you may get requests to hit each of these areas adhoc.. Do not move around, unless you have convincing inputs. Fix one and make sure the fix doesn't break anything else.
3. Pick up the one that you think is obvious and get deeper to the non obvious
When you start the investigation on tricky issues, you end up investigating or looking for problems.. more usual answer to bigger problems are very small fixes.. I remember one of the alerting issues we had in the past had a typo and 2 years 3 hard core developers could not get the fix working.
When you step into a problem area make sure you cover the linked non obvious area.. there maybe something very silly in there...
4. Never bring only experts on the issue
Experts tend to focus only on technical directions, many times experts have a rigid view of how things work and they dont want to move away from it and find problems... 3 times during this deadlock issue we found that non experts came very handy:
1st When they traced that downloads block.. by accident or by luck and by hawk eye
2nd When they found that uploads take time when done in parallel
3rd when somebody not even on the system gave an idea to look at areas that are used in conjunction and have less of a link
All 3 times we found good traces and inputs to move further and find out whats on.
5. Analyse, List , Analyse , Detail , Analyze , Fix , Analyze , Test, Analyze, Analyze the Analyzed
Follow it hard... anything you do , just analyze and re analyze.
6. Trust your Findings, Analysis, Team , Fix , Test and Release
Trust whatever you do. Stand by it. Make sure it succeeds.
7. Nothing can be found and fixed in 1 go
It can never be, make sure you find , remove and keep finding.
8. There is never an end to a problem.
It will come back. Very soon. Be prepared.
9. don't loose track of what you have done.
List them out. put it as a checklist and then tick them on and off. Revisit them.
10. Wiki your approach and the tools, technology you used to fix it
Document your approach.
11. Spend hours and hours on looking at whats going on, minutes looking at exact problem area
May help you give more ideas on where to look at the exact problems.
12. leverage the dependency factors, Isolate what is not common
Add up flexibility to your analysis
13. Make a Team to look at the issue not individuals.
Individuals focus on certain areas based on there likings and feelings. Bring a Team that can drive discussions to move in the right areas. Add Team that can value in discussions..
14. Group to find it, Individualize to analyze, Pair to fix, Group to Test
Bring groups to find the issues, helps when different people, Individuals to analyse them , brings developers to pair and fix them as they can be more effective.
15. Revisit what is done earlier
Go back and see what has being done so far and what has being done in the past.
16. Track everything you do to resolve
Keep it in a way you can refer to it later.
17. Buy a Lunch to those who fixed it
Finally !!!!
Friday, 13 November 2009
Technology , Outages , Bugs and Us
One manual error and you are gone for life.... Over the last few weeks
some good effort from the Team we have successfully being able to get
rid of the eclipse to our code... Yes we got rid of conflicting ORM
technologies in our code, upgraded and migrated our self to the best
one that works...
However its not easy... technology is predictive and so are the bugs
it holds, in 2 spells we have had severe troubles. Locks , Lock
contentions , Dead locks... pulling of people from critical tasks to
let our customers use our systems, Sleepless nights debugging the
locks and the SQL behind them, debugging the code , 1 , 2, 3 several
times... , Seeking experts every now and then..
I am sure you face this, If you are a technology team every now and
then. We learn our lessons and we become more effective , more
precautionary...But is it enough?
Well No... you need to bring Caution and Precaution in the Team. Bring
a Pessimistic QA and an optimistic developer in your tasks and maybe
it will work.. Here are few things that can take you at ease when you
are in such situations...
1. Bring a Policeman in your Team, He should not be the tech Lead, Not
the Architect.. he should be one who knows a bit of technology and
asks you why a certain line of code is checked in.
2. When in troubles take Baby steps... You can change the whole world
in one day and You can change yourself to match the world in a day...
Dont try to do either.. slow down.. take step 1 watch , step 2 wait ,
step 3 snooze and step 4 wake up...
3. Relax... just hard work is not enough , you have to be creative in
finding problems
4. Do not listen to your Sales Team nor your developers.... Both go to
extremes... One wants to do everything with Technology and immediately
the other wants everything immediately...both hurt in problem
situations
5. Bring a Semi expert , Non Expert and one expert in a loop and see whats on
6. List down areas , check them out to find the issue...
while I write this I think about it... Am I going to go tomorrow and
follow this the next time we have trouble?
Hell Yes
Monday, 9 November 2009
Few ways to identify a Commited collegue
- You have never see him out of office
- The places he is most found is the work desk , meeting room , coffee macine
- When he speaks about the project, he is at top of his voice
- He is on every forum and community related to the domain you work on
- When he is done he would sit at other desk and watch what they do, help them
- The first and last email you get at work is from him
- He is there in sun , rains and winter
- You think you can sleep well because he is there to handle any emergencies
- You get a chat message or an email in the middle of the night on how you can do something better
Sunday, 8 November 2009
Path to Organizational Success - Be Demanding?

Everyone of us is demanding, very demanding... we want good salaries, we want regular promotions, we want everything that someone can offer and someone cant... We crib for what cannot be offered more than what we get already... in other words we are too demanding.. I am sure when the Managers discuss this they discuss the same... Eventually I think its not too bad to be Too Demanding... But it would be worth for an organization if you change the perspective...
Project Success and Team Values
Friday, 6 November 2009
Of Teams and Mediocrity II

Tanveer said :
A Interviewer don't want to hire a person better than him, a manager give preference to a candidate from his community, People who refer candidates set out as well as break out the interviewing process.
That is what people say that only because of few team members this project is actually driving.
So finally you left with one choice i.e. - 4th choice.
Now since you know whos and whats of mediocrity target independent elements...feel them, be with these problems... try to understand individual reasons to problems...
Now since you know the causes and reasons of mediocrity.. try to penetrate it...