The Enterocial need!!! Can we get Enterprises Ready?
Tuesday, 24 November 2009
So much of hype of Social Media, so much to speak about it.. but with the world turning its heads on Social Media, Social search , Social culture... are the enterprises ready to adapt any of the good that Social Media brings in? Well I am not sure how much of it will be debated or how much will be agreed... but the challenges in running big enterprises lets you think on the best ways to improve enterprises and interaction in enterprises.... and Social buzz can be of good help there...
Scribbled bySameer 0 comments Links to this post
What did you miss?
Monday, 23 November 2009
I got a call from a friend 15 minutes before I had to decide on writing this post... The conversation very short and simple, effect very long and lasting... To give a bit of a background my friend is leading a team of 50 Engineers, analysts, QA and Business Managers, A year ago while we were busy building our Team, he too had started to set a direction to his...
Scribbled bySameer 0 comments Links to this post
Build fast, Break fast
Saturday, 21 November 2009
There is nothing in this world called quick solution. If something is going to be built quick , it is going to break quick. Our experience in building good quality softwares is a good example for this... I remember first time our interaction with our then Product Manager Karin.... we discussed on a feature where the estimate given by a developer to add a new feature was given to be a couple of weeks... a similar feature done earlier in couple of days...
Scribbled bySameer 0 comments Links to this post
Labels: build vs break
Lessons from the Recent Deadlock issues
Tuesday, 17 November 2009
I usually don't do this over this blog... on my private blog diary however I maintain my own lessons but thought it has become very critical and worth a share. The recent deadlock issues really really tested my patience... it started on 30th October and finally seems to have ended today. But before I loose track of what and how we did, what we should take care.. here are my lessons from the issue :
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 !!!!
Scribbled bySameer 1 comments Links to this post
Technology , Outages , Bugs and Us
Friday, 13 November 2009
No matter what you do... there is nothing called as full automation...
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
Scribbled bySameer 0 comments Links to this post
Few ways to identify a Commited collegue
Monday, 9 November 2009
- 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
Scribbled bySameer 0 comments Links to this post