Patriots all the way.. woohoo.... !!!!
http://myspacetv.com/index.cfm?fuseaction=vids.individual&videoid=26894752
Sunday, February 3, 2008
Wednesday, January 30, 2008
A view on onsite-offshore development...
The onsite-offshore development model is currently the cheaper, faster way to produce software. But at what cost...
Having experienced this over the last 7+ years, here's my take on it.
1. Estimation - There needs to be a very good estimation model in place. Without this, both teams (onsite and offshore) will be fighting a losing battle. The teams will be working against the clock, they WILL cut corners to meet deadlines. Code quality is compromised. More errors are introduced.
All these result in a longer testing and defect fixing cycle. The net result- the project goes over budget, and deadlines are missed.
2. Scope - This goes hand-in-hand with estimation. It is very important to only take on what you can chew. Most often, the onsite management are delusioned that the offshore team have more time and hence try to absorb scope. This too has the same result as a poor estimation.
3. Responsibility - It is extremely important that both teams; onsite and offshore, share the same level of ownership and responsibility towards delivery. If the onsite team have a "the offshore team will take care of that" attitude, then again this model is not going to work. The truth of the matter is that the onsite team have more perspective towards the issue/function. They should take it upon themselves to at least provide a sample solution towards the problem so that the offshore team can complete the job. Failing to do with will result in the offshore team working towards a solution which they "think" is correct.
The norm is that the onsite team will then reject the fix, or mark it as incomplete and this results in more cycles.
4. Skill level - In my experience, it is common to get into a consulting engagement where the client uses a few technologies that are unfamiliar. Being technologists, it is our responsibility to spend a little time ramping up on these technologies such that we are at a decent level to code and troubleshoot. Over time, it is inevitable that we will become experts in that technology. It is however important to allocate that ramp up time at the beginning of the project. True, most of the learning happens on the job. But the ground work, background reading, and the basics have to be right.
Failing to allocate that rampup time upfront will result in not being able to achieve the desired levels of productivity.
5. Communication - I don't know how this ended up so low on the list. But I can't stress enough how important communication is. Having daily sync up calls is very effective. It is important for both teams to be in constant communication so their each party knows exactly whats going on.
When i mean communication I mean,
- Daily calls
- Accompanied by an email outlining the tasks needed to be completed and a status email at the end of the day
6. Tracking - Along with communication and status updates comes tracking. This becomes an important tool to see how well you are achieving your targets and milestones. This information then feeds into your next estimation process so that you can estimate better (at least thats the idea - Learn from your previous experiences.)
Looking back, most of these are aspects of project management :). So far we've got estimation, scope and now tracking. It becomes apparent that for an onsite-offshore project to succeed, the project management has to be very good. Maybe I'm biased, the engineers and the architects are equally important but they generally take care of their business :). The bottom line is, the project management has to be pretty good to run a project smoothly.
Thoughts ??
Having experienced this over the last 7+ years, here's my take on it.
1. Estimation - There needs to be a very good estimation model in place. Without this, both teams (onsite and offshore) will be fighting a losing battle. The teams will be working against the clock, they WILL cut corners to meet deadlines. Code quality is compromised. More errors are introduced.
All these result in a longer testing and defect fixing cycle. The net result- the project goes over budget, and deadlines are missed.
2. Scope - This goes hand-in-hand with estimation. It is very important to only take on what you can chew. Most often, the onsite management are delusioned that the offshore team have more time and hence try to absorb scope. This too has the same result as a poor estimation.
3. Responsibility - It is extremely important that both teams; onsite and offshore, share the same level of ownership and responsibility towards delivery. If the onsite team have a "the offshore team will take care of that" attitude, then again this model is not going to work. The truth of the matter is that the onsite team have more perspective towards the issue/function. They should take it upon themselves to at least provide a sample solution towards the problem so that the offshore team can complete the job. Failing to do with will result in the offshore team working towards a solution which they "think" is correct.
The norm is that the onsite team will then reject the fix, or mark it as incomplete and this results in more cycles.
4. Skill level - In my experience, it is common to get into a consulting engagement where the client uses a few technologies that are unfamiliar. Being technologists, it is our responsibility to spend a little time ramping up on these technologies such that we are at a decent level to code and troubleshoot. Over time, it is inevitable that we will become experts in that technology. It is however important to allocate that ramp up time at the beginning of the project. True, most of the learning happens on the job. But the ground work, background reading, and the basics have to be right.
Failing to allocate that rampup time upfront will result in not being able to achieve the desired levels of productivity.
5. Communication - I don't know how this ended up so low on the list. But I can't stress enough how important communication is. Having daily sync up calls is very effective. It is important for both teams to be in constant communication so their each party knows exactly whats going on.
When i mean communication I mean,
- Daily calls
- Accompanied by an email outlining the tasks needed to be completed and a status email at the end of the day
6. Tracking - Along with communication and status updates comes tracking. This becomes an important tool to see how well you are achieving your targets and milestones. This information then feeds into your next estimation process so that you can estimate better (at least thats the idea - Learn from your previous experiences.)
Looking back, most of these are aspects of project management :). So far we've got estimation, scope and now tracking. It becomes apparent that for an onsite-offshore project to succeed, the project management has to be very good. Maybe I'm biased, the engineers and the architects are equally important but they generally take care of their business :). The bottom line is, the project management has to be pretty good to run a project smoothly.
Thoughts ??
Monday, January 14, 2008
Interview questions (3)
Here's an addition to some of the more interesting interview questions I have received during my job hunt
1. How would you write your own garbage collector ?
The crux of the question is how would you identify which objects need to be garbage collected. Here, they are trying to test your knowledge of the heap and call stack.
2. You've got an array of numbers. They are not sorted. How do you find the the first pair that sums to X (a given number)
They're looking for an optimized solution. The most obvious solution is an n^2 solution and thats not what they want...
Hint: Think about which data structure you could use.
1. How would you write your own garbage collector ?
The crux of the question is how would you identify which objects need to be garbage collected. Here, they are trying to test your knowledge of the heap and call stack.
2. You've got an array of numbers. They are not sorted. How do you find the the first pair that sums to X (a given number)
They're looking for an optimized solution. The most obvious solution is an n^2 solution and thats not what they want...
Hint: Think about which data structure you could use.
Saturday, December 29, 2007
Getting things DONE...
In my attempt to organize myself and somehow find a way to do the things I do in a more effective manner, I found myself buying David Allen's "Getting things DONE".
Here's what pointed me to it.
http://www.43folders.com/2004/09/08/getting-started-with-getting-things-done
Here's what pointed me to it.
http://www.43folders.com/2004/09/08/getting-started-with-getting-things-done
Wednesday, December 12, 2007
Vehicle Hunt...
Looking for the perfect used car is quite a difficult task. Here are some useful information
Some of the web sites that were very helpful were,
www.cars.com - very good used/new vehicle search. Very good search results. Most of the vehicles were good.
www.autotrader.com - fair decent search results
www.kbb.com - useful in getting a rough idea on how much the vehicle is worth.
www.carfax.com - extremely useful in getting the history of a vehicle (accidents, owners, emission tests, etc)
Here are some of the lessons I learnt along the way....
1. Do your homework on the vehicle you select (includes reading user reviews and carfax records)
2. Test drive it and see if it drives as well as it looks :)
3. See as many as you can. Having options is always a good thing.
4. Try your best to stick to your budget. (remember you have other costs as well; insurance, registration, inspections, car care stuff and other gadgets)
5. Always negotiate. You never know when you will strike the best deal. Dealers always talk the talk! Don't fall for it. Make your offer and walk away. They WILL call you back.
6. Get your vehicle inspected by the agents before you purchase it.
Some of the web sites that were very helpful were,
www.cars.com - very good used/new vehicle search. Very good search results. Most of the vehicles were good.
www.autotrader.com - fair decent search results
www.kbb.com - useful in getting a rough idea on how much the vehicle is worth.
www.carfax.com - extremely useful in getting the history of a vehicle (accidents, owners, emission tests, etc)
Here are some of the lessons I learnt along the way....
1. Do your homework on the vehicle you select (includes reading user reviews and carfax records)
2. Test drive it and see if it drives as well as it looks :)
3. See as many as you can. Having options is always a good thing.
4. Try your best to stick to your budget. (remember you have other costs as well; insurance, registration, inspections, car care stuff and other gadgets)
5. Always negotiate. You never know when you will strike the best deal. Dealers always talk the talk! Don't fall for it. Make your offer and walk away. They WILL call you back.
6. Get your vehicle inspected by the agents before you purchase it.
Sunday, October 14, 2007
Moving to Milwaukee....
I'm back in the US of A, and this time its going to be for a while. New project, new setup, new way of life.
So far I'm enjoying the transition from student life to work life. A few things are harder getting used to again. Like,
- The nightly calls with my off shore team
- The busy days filled with meetings
- Handling conflicting personalities
Whereas, I enjoy,
- Getting paid again !!! woohoo..
- Being in the midst of solutioning an enterprise architecture
- The challenge of constantly having to push to learn new technologies and methodologies
In addition to the work aspect, the whole experience of settling down is exciting. Starting from the search for a place to stay, buying a bed, getting my SSN, applying for my drivers license to buying a car... and many more to come..
So far I'm enjoying the transition from student life to work life. A few things are harder getting used to again. Like,
- The nightly calls with my off shore team
- The busy days filled with meetings
- Handling conflicting personalities
Whereas, I enjoy,
- Getting paid again !!! woohoo..
- Being in the midst of solutioning an enterprise architecture
- The challenge of constantly having to push to learn new technologies and methodologies
In addition to the work aspect, the whole experience of settling down is exciting. Starting from the search for a place to stay, buying a bed, getting my SSN, applying for my drivers license to buying a car... and many more to come..
Monday, July 23, 2007
Interview questions (2)
1. How would you write your own garbage collector ?
2. You've got an array of numbers. They are not sorted. How do you find the the first pair that sums to X (a given number)
3. Write an algorithm where given an array of numbers (ints) , find the number of pairs that sum up to a given number
4. Given a n by n matrix or integers, where each row is sorted in ascending order and each column is sorted in ascending order. Find a particular number in that matrix.
5. Write a basic compiler simulator
6. Given a sentence, write an algorithm that would reverse all the letters in teh sentence.
7. The same sentence, write an algorithm that would reverse all the words in that sentence.
8. When would you use a hashmap, hashset, linked list ?
9. Questions around serialization - why ? how to serialize, how to prevent serialization
10. Concurrency - dead locks, prevention of deadlocks, race conditions
11. Web apps - req/response, vs sessions, how do web servers keep track of sessions, why would you use pooling
12. Threads - whats a thread local, why would you use one, what do you need to be aware of when using threads
Other questions
- Why would you use materialized views.
- Joins, self joins, hierarchical queries
2. You've got an array of numbers. They are not sorted. How do you find the the first pair that sums to X (a given number)
3. Write an algorithm where given an array of numbers (ints) , find the number of pairs that sum up to a given number
4. Given a n by n matrix or integers, where each row is sorted in ascending order and each column is sorted in ascending order. Find a particular number in that matrix.
5. Write a basic compiler simulator
6. Given a sentence, write an algorithm that would reverse all the letters in teh sentence.
7. The same sentence, write an algorithm that would reverse all the words in that sentence.
8. When would you use a hashmap, hashset, linked list ?
9. Questions around serialization - why ? how to serialize, how to prevent serialization
10. Concurrency - dead locks, prevention of deadlocks, race conditions
11. Web apps - req/response, vs sessions, how do web servers keep track of sessions, why would you use pooling
12. Threads - whats a thread local, why would you use one, what do you need to be aware of when using threads
Other questions
- Why would you use materialized views.
- Joins, self joins, hierarchical queries
Subscribe to:
Posts (Atom)