Do we need reservations?

India has awaken to the reservations debate again. Do we need it? Isn't it reverse discrimination to allot quotas to particular castes. Shouldn't reservations be based on economic conditions?

I think its pretty important to understand why a society/country would need reservations. To me reservations are needed when you have a social strata that is at a disadvantage to reap the benefits of progress. Like we have with our caste based system. For a long time some people have been brought up thinking their job is to clean, make shoes etc. They dont have the same level playing field as many of us. So as a society, as a country, we need policies to help such people rise and progress.

However reservations should not be forever. Or else it would be reverse discrimination. It should be time-bound (for say 50 years) and all efforts should be made to make it successful during this time. Creamy Layer (families that have some minimum earnings) should be excluded from reservations. They are at no disadvantage than anyone else in the society.

Some people would prefer having reservations based on economic conditions of a person. I dont agree with it. You would have people with varying income levels even in a society where all are equals. Imagine a person who is poor because he does not want to work hard and is not skilled/intelligent/, though he had a level playing field. Extending reservation to his/her progeny seems unfair. Not doing good in life shouldnt qualify you for a reservation.
What we should be doing though is providing scholarships/loans to deserving poor students so that they can continue their studies and their economic backwardness does not hamper their education.

How to get productive on a project quickly (joining midway)?

One of the things I have been thinking of nowadays, is how does one join and start being productive on a project quickly, i.e. projects that have started sometime back and you join inbetween iterations (maybe after some release(s)).

One way is what I would term as top-down approach, start with understanding how the system works at a high level. This might involve things like understanding what are the various layers in the system, technologies being used in each layer, testing framework being used, Automated Acceptance Tests, build process, understand the various tools used for testing, development and deployment. Once you have some understanding of these stuff, you can move on lower to the implementation details. One disadvantage I see in this approach is sometime has to be spent before you actually start contributing to the project. Also after spending time on this exercise, you do not have the satisfaction of doing something useful for the project.

Another approach might be a bottom-up approach. Basically you start working directly on some Usecases(UC)/Stories. A pair (who is experienced on the project) can be of great help in disemminating the knowledge of the system. So if the UC/Story you are working on involves, say, some EJB Component Implementation, you start off doing construction on this part of the system. While doing this, you observe how the system works/interacts and gain an understanding of that part of the system. Certain degree of criticality helps in bringing out why the system has been built the way it is. A pair ensures that you always have someone to clear any lingering doubts. However, this also means that you understand only the part of the system that you have actually worked on, and may not have the big picture about other things. This can be a great handicap.

I basically prefer a more hybrid approach, in that you start off constructing some UC/Story, but also spend some little time understanding how the total system works. For eg. while you are implementing a UC/Story, you might spend sometime understanding the big picture of the web services part of the system, another day perhaps the data layer and so on. So you start contributing to the application in some small way by actually constructing something, and also understand the system metaphor. The confidence you get by actually contributing to the system building is a big booster (helps more than just understanding the system interaction at a higher level), and puts you on a firm foot in the project.

Though I have primarily been thinking from a developer perspective (short-sighted vision :-) ), I think the same could be extended to business and quality analysts. Any thoughts?

First Blog!

Am new to blogging, and this happens to be my first blog entry!