One more shot
Tuesday, May 03, 2005
Wednesday, February 23, 2005
Whoever said fundamentalist cant make good economists ?
http://www.expressindia.com/fullstory.php?newsid=42274
The Paki finance minister is secretly wishing that more actresses follow Meera. With so much "talent" in Pakistan, its only a matter of time before thier economic woes are taken care by the revenue generated by these fines.
The Paki finance minister is secretly wishing that more actresses follow Meera. With so much "talent" in Pakistan, its only a matter of time before thier economic woes are taken care by the revenue generated by these fines.
Tuesday, February 01, 2005
Farewell Food, no Thought
I am in the process of moving out of DC to start a new job. Since my current company is on a week long cruise this week I decided to quit last week itself. I know, I should I have quit after the cruise but these damned ethics came in the way. Life will be so much more simple without them.
As I announced my resignation, I knew people would be taken aback. I expected a few handshakes and goodbyes, but what I got was 8 farewell parties in the last 6 days. Physically it was very tough, my gastric juices and stomach have never been subject such rigorous tests. It was only a matter of time before they revolted thus increasing the number of bathroom visits.
May be, by acknowledging my sins I will be condoned and the extra layer of fat around my stomach will magically vanish. So here is what happened in the last few days
Date :
Group : Few RADG (Racist Asian Dinner Group) members
Venue :
Agenda: Update on the latest of the racial slurs.
Date :
Group : Java Team
Venue : On the borders
Agenda: Hedging bets on my returning back to Appian
Date :
Group : Appian open all Dinner
Venue : Bailyes Pub & Grill
Agenda: Farewell sugar talk
Date :
Group : DC Desi (non ABCD)
Venue : PF Changs
Agenda: Celebrating birth of one more ABCD of the Group
Date :
Group : NON RADG (Racist Asian Dinner Group) members. Some pseudo Asians were also present
Venue : Tachibana
Agenda: How to make the perfect Maki Sushi
Date :
Group : College buddies
Venue : Heritage
Agenda: Keep the rumor mills running
Date :
Group : Couple one on one
Venue : Charcoal kabob
Agenda: Investigating Indian culinary influence on everything edible in this world.
Date :
Group : Couple one on one
Venue : Gua-Rapo
Agenda: Liberals - free for all
Thursday, December 23, 2004
Four stages of work
My friend and I were talking about our work at lunch today. He told me about a grid that he has come up with to clearly define 4 stages of the work. This is what the grid looks like.
Most people are stuck in the 4th quadrant where they are neither trying hard nor making swift progress. My initial assessment was that the most productive quadrant is Jamming but you can’t sustain trying hard for a long period of time. The key is to be in Cruising quadrant. It’s much better for your endurance. The only problem is that it’s very easy to slip from Cruising to Slacking. The other paradox is that if you try hard not to go from cruising to slacking, you might risk getting into Jamming. The key is to make a healthy balance between not trying too hard and still being focused. It’s really difficult to that especially so many interesting things going in the workspace. Some of them are shown below
Conflict Resolution Is this really a release blocker bug ??
Enthusiasm of your colleagues
Your own desires to find your inner self
| Trying hard | Not trying hard
| |
|---|---|---|
| Making swift progress | Cruising
| |
| Making slow progress | Grinding | Slacking
|
Most people are stuck in the 4th quadrant where they are neither trying hard nor making swift progress. My initial assessment was that the most productive quadrant is Jamming but you can’t sustain trying hard for a long period of time. The key is to be in Cruising quadrant. It’s much better for your endurance. The only problem is that it’s very easy to slip from Cruising to Slacking. The other paradox is that if you try hard not to go from cruising to slacking, you might risk getting into Jamming. The key is to make a healthy balance between not trying too hard and still being focused. It’s really difficult to that especially so many interesting things going in the workspace. Some of them are shown below
Conflict Resolution
Is this really a release blocker bug ??
Enthusiasm of your colleagues
Your own desires to find your inner self
Wednesday, December 22, 2004
Cruise Bio
Each year my company goes on a weeklong cruise trip to the Caribbean - Mexico (or Alaska if the HR Manager is really pissed at us). Before the trip all employees are asked to prepare short bios about themselves. These bios are compiled into a small book, which is distributed among the employees as a memento of the trip. Here is my bio for this year’s trip.
Name: Abhishek Agrawal.
Birth city:
Etawah, UP - India. It is an overgrown village of a half a million people in the middle of nowhere
Prone to:
Frequent spells of selective amnesia
Convicted of:
2 speeding tickets and 1 for jumping a red light (and also for trying to drive through the wall). Oh yeah, once reprimanded for stealing 2 year olds ice cream.
Claim to fame:
$3000 phone bill
Talents:
Still trying to find one
Dreams of:
Making a product so efficient that customers don’t even need to buy it.
Believes:
Life is an angry bull and you are a stupid matador. You stand in its path, grab the bull by its horn and try to bring it down. The bull hurls you in the air and you land with the control of a helicopter with no gas. Even though your body is badly scratched and there is blood dripping down your face you don’t give up. You stand up once again and charge back towards the bull. The result is no different this time. You keep fighting until you are tired, exhausted and your motivation becomes that of a wet noodle. Beaten to submission you don’t know where to go and what to do. You loose all hope and THEN you make the decision of your life, YOU MARRY IT!
Name: Abhishek Agrawal.
Birth city:
Etawah, UP - India. It is an overgrown village of a half a million people in the middle of nowhere
Prone to:
Frequent spells of selective amnesia
Convicted of:
2 speeding tickets and 1 for jumping a red light (and also for trying to drive through the wall). Oh yeah, once reprimanded for stealing 2 year olds ice cream.
Claim to fame:
$3000 phone bill
Talents:
Still trying to find one
Dreams of:
Making a product so efficient that customers don’t even need to buy it.
Believes:
Life is an angry bull and you are a stupid matador. You stand in its path, grab the bull by its horn and try to bring it down. The bull hurls you in the air and you land with the control of a helicopter with no gas. Even though your body is badly scratched and there is blood dripping down your face you don’t give up. You stand up once again and charge back towards the bull. The result is no different this time. You keep fighting until you are tired, exhausted and your motivation becomes that of a wet noodle. Beaten to submission you don’t know where to go and what to do. You loose all hope and THEN you make the decision of your life, YOU MARRY IT!
Thursday, December 16, 2004
Saturday, September 25, 2004
Extreme Programming:
Almost everyone who has ever been a part of a software development team has experienced a sense of anger, frustration and helplessness at how “things just get out of control”. Unlike manufacturing, software development process grants each person the potential to completely wreck the product cycle with an unwitting minutest intervention. Is this a person or a process problem? Why do software development projects fail? How can we alter the process of development to make it less sensitive to the actions of the people involved in it?
Appian sponsored Java Users Group (AJUG) decided to find answers to these questions by looking at the alternate software development methodologies. We started with looking into details of Extreme programming – first proposed by Kent Beck. His book, "Extreme Programming Explained" is broadly divided into three parts – The Problem, The Solution and The Implementation, each of which is about 50 pages. On a Saturday afternoon it will take you less 3 hours to go through the whole book.
Kent recommends paradigm shift in software development process. The emphasis is on designing little, implementing, testing and repeating the process as fast as possible. This is completely antagonistic with the most technology team’s emphasis on designing early and thoroughly. The book strongly recommends use of XP methodologies like pair programming, unit and functional testing, which definitely have a lot of positive points. Kent also provides a rather simple yet remarkable way of cost benefit analysis of adding a new feature during the various stages of product life cycle. Unfortunately in one and half pages the idea is bit under sold but then this is not a book about pricing software.
One of the most intriguing ideas put forth is the concept of common ownership of code. Most technology projects have core of their architecture closely guarded under the watchful eyes of their most senior programmers. Kent makes a strong case for allowing every member on the team to make any change they deem necessary to any part of the system. At first this seems completely illogical and fraught with risks, but he explains that with pair programming, automated testing and refactoring its not as perilous as one would wonder. The left liberal in me is convinced but the pragmatic one tells me that the risk involved are highly dependent on the ability of every member of the team to understand the architecture and also on the quality of the automated tests. Weakness in any of the two can end in some disastrous consequences. I have spent sleepless nights (not quite) thinking about this, but I am still not convinced. Common ownership is highly depend on the XP methodologies and cant be put to practice unless other XP stuff is working very well for the team.
Overall this book is worth every penny of its value. You might not agree with any of its ideas, but it does provide some fresh insights on tackling problems we face on a daily basis. It’s not a fast paced suspense thriller - DaVinci code, but it’s closest to that in the world software engineering. I will specially recommend it to the people who are disturbed by the chaos and confusion surrounding development of software products and are looking for more repeatable and predictable processes.
I do agree with the Kent about this -- Embrace change!
Appian sponsored Java Users Group (AJUG) decided to find answers to these questions by looking at the alternate software development methodologies. We started with looking into details of Extreme programming – first proposed by Kent Beck. His book, "Extreme Programming Explained" is broadly divided into three parts – The Problem, The Solution and The Implementation, each of which is about 50 pages. On a Saturday afternoon it will take you less 3 hours to go through the whole book.
Kent recommends paradigm shift in software development process. The emphasis is on designing little, implementing, testing and repeating the process as fast as possible. This is completely antagonistic with the most technology team’s emphasis on designing early and thoroughly. The book strongly recommends use of XP methodologies like pair programming, unit and functional testing, which definitely have a lot of positive points. Kent also provides a rather simple yet remarkable way of cost benefit analysis of adding a new feature during the various stages of product life cycle. Unfortunately in one and half pages the idea is bit under sold but then this is not a book about pricing software.
One of the most intriguing ideas put forth is the concept of common ownership of code. Most technology projects have core of their architecture closely guarded under the watchful eyes of their most senior programmers. Kent makes a strong case for allowing every member on the team to make any change they deem necessary to any part of the system. At first this seems completely illogical and fraught with risks, but he explains that with pair programming, automated testing and refactoring its not as perilous as one would wonder. The left liberal in me is convinced but the pragmatic one tells me that the risk involved are highly dependent on the ability of every member of the team to understand the architecture and also on the quality of the automated tests. Weakness in any of the two can end in some disastrous consequences. I have spent sleepless nights (not quite) thinking about this, but I am still not convinced. Common ownership is highly depend on the XP methodologies and cant be put to practice unless other XP stuff is working very well for the team.
Overall this book is worth every penny of its value. You might not agree with any of its ideas, but it does provide some fresh insights on tackling problems we face on a daily basis. It’s not a fast paced suspense thriller - DaVinci code, but it’s closest to that in the world software engineering. I will specially recommend it to the people who are disturbed by the chaos and confusion surrounding development of software products and are looking for more repeatable and predictable processes.
I do agree with the Kent about this -- Embrace change!
Wednesday, May 19, 2004
Strategy and Strategic Planning: (Henry Mintzberg)
I really like Henry's work in strategy and planning. These are the excerpts of some intersting points he made in an article I read recently.
Most successful strategies are visions not plans.
Strategy making process - capturing what managers learn from personal experience and experiences of others and the hard data from market research, and synthesizing that learning into a vision of the direction that the business should persue.
Does not involve formanl techniques.
Planning represents calulating style of managment and not commiting style of mangment.
Learning plays the most crucial role in the development of novel startegies.
Business unit managers should take full and effective charge of strategy making process.
Planners: Ask the right question ? Dont try to find out the right answer.
Strategy making process should not and cannt be formalized. Formalization hinders creative thought process, which is the the most essential part of Strategy making.
Thursday, April 29, 2004
"Location" - Clusters and Competition: Michael Porter
Michael's take on Locations. This is definitely interesting. May be companies competing in close affinity is not that bad afterall.
Clusters suggests that much of the competitive advantage lies outside a given company or even outside its industry, residing instead in the locations of its business units. eg: Odds of building a world class mutual fund company are much higher in Boston than in any other location or a textile related companies in North Carolina (although I would rather move them to China).Clusters attract foreign investments. (You can build world class facilities, but without presence of conducive clusters its difficult to attract industries. This explains why efforts by governments to divert industries to specific locations has failed so often -- Butibori in Nagpur)
Subscribe to:
Posts (Atom)