Sunday, September 16, 2007
Bad enough the accident happened but what was shocking is that the injured in the accident were able to get to a hospital barely a kilometer away from the accident spot only after 2 hours due to the traffic blocking the traffic. Why is that if a politician is coming on a road they can clear it in a matter of minutes but when it comes to clearing the roads for an ambulance does not evoke the same response. We need to learn how to manage disasters - it is not that the police can't do it, they just don't do it.
I have seen ambulances stuck in traffic for precious minutes - neither the cops manning the traffic junctions or the people in the way show any inclination to give way to the ambulance. The traffic was once stopped for a VVIP and there was an ambulance blaring in the stopped traffic and the cop who stopped the traffic just did not care about the ambulance he just made it wait till the VVIP passed. The public need to understand that one day it may be one of them in that situation losing precious minutes in an ambulance stuck in traffic.
Another thing that distressed me is seeing the hundreds and hundreds of people at the accident spot doing nothing but just standing around and gawking at the scene. As part of disaster management we should learn to clear out the effected area so that the people who can help can do their job efficiently and quickly. The politicians should learn that they visiting the spot soon after the accident does not help anyone. Neither do they have the specialization to deal with the situation and they also throw everything out of whack due to their own security and the hundreds of people that follow them everywhere. When will we learn and improve and understand that in an accident the most important people are the victims and we should be doing everything in our power to help them.
What I have realised is that we are not learning from incidents that have happened and improve on it. Every time we have a disaster its the same story.
Saturday, September 08, 2007
It is the ratio of the quantity and quality of units produced to the labor per unit of time.
As we all know productivity is the measure of units produced in unit of time. But as you see in the definition above there is also quality involved in the units that are produced. So we can never calculate productivity only using quantity without quality.
When we think of productivity in software everyone goes for the easiest measure - number of lines of code written in unit time usually a man day. This is a very very dangerous metric to use for the following reasons
- A lot of code is written by code generators and by copy pasting existing code and modifying it to suit ones needs. So there can be a large amount of code written in a very short span of time.
- A good design may cause a lot of code reuse - thus reducing the amount of code that is written but in turn improving performance and maintainability. Does this mean that the productivity has come down.
- Tough technical problems may have a lesser amount of code that is written than easier problems - but tough technical problems involve a lot of thinking and usually take longer to do. Does this mean that the ones working on the tougher problems are less productive.
Let me tell you typically what happens in a project that involves development of a business functionality.
- The initial framework and prototypes are developed - usually takes sometime and there is not much code that is written.
- Once the framework is proven junior developers are taught the framework and given the functionality to replicate using the framework - short phase when a large amount of code is written.
- Parallel activities go on to do the parts of the framework that are plugged in on top of the functionality such as security, error handling and so on - does not result in a great amount of code but achieves a large part of the functionality. Usually done by the senior developers in the project.
If you look at the above scenario it will come out that the junior developers that worked on replicating the functionality using a similar kind of an architecture are more productive than the senior developers that worked on the tougher defining parts of the application. So as you can see above the traditional LOC/Man day definition never works. What is more flawed about this definition is that it does not even take into consideration of the quality of the code. One may write a lot of crappy code generating a large amount of code base but the stuff does not even work.
At the end of the writing software is different from manufacturing - productivity is a concept from manufacturing. It is easy to use productivity in manufacturing for the reason that it is the same article that is being produced again and again each and every time. Hence you can either go fast or slow in producing that article and productivity is an apt metric there. The same cannot be said of software. In software we are not producing the same functionality over and over again.
More dangerously productivity tends to be used to evaluate the performance of the person and I hope that by reading what is on top no one in their right mind would use it.
Let us hypothetically say that we want to calculate the productivity in software - how would you do it?
In order to calculate productivity we need a measure of size or quantity. This is the hardest thing to calculate in software the reason being the easiest measure Lines of Code (LOC) can be very misleading. There can be code that is never used or called in the program. They can be code that is absolutely messed up and should never have been written that way. There can be code that can be written on the same line but is written on multiple lines or the other way around. There are hundreds of such issues with using LOC as a size measure. Which brings us to the only other measure and that is trying to count the functionality that is implemented. For this FPA (Function Point Analysis) does a pretty decent job but the catch is that it is not easy to use by everyone. One needs to have experience using it.
Provided you have the FPA count of the project - then comes the next challenge of getting the time to divide it by. One should never add the full duration of the project and use it. This is a big mistake. Each phase of the project has its own challenges and the outputs are different out of each phase. Productivity should be calculated on items where the output is similar if not same. Hence one needs to count the productivity for each of the phases - planning, design, development, Testing and Release (provided we go with the waterfall life cycle) separately.
Now comes to the third measure and that is quality. Quality can be calculated by the amount of functionality that is working with no defects or defects accepted with a work around.
Hence I would say a decent productivity metric would be FPA count/Time in x phase where y% of the functionality is working.
Tuesday, September 04, 2007
This is the entrance of the resort and on the right is the reception.
This is the walkway leading away from the reception. It has a lot of greenery and it is quite beautiful.
Swimming pool. It is not deep but there are a lot of slides. Careful if you are big made as you tend to roll over and your head hits the base of the pool.
A nice ground to play cricket. A must do if you are in a big enough group.
The portico around the swimming pool. Just cool to hang around. There are pool side rooms on top of this area but I can't seem to find the pictures. Will upload them as soon as I find them.
This is the outdoor restaurant. This place has 2 restaurants. One is indoor and the other outdoor. The indoor restaurant doubles up as a bar so is not very conducive to families having food there as it is smoke filled and noisy. The outdoor place tends to get very dark in the night. The restaurant overlooks a pond that have ducks in them and so it is quite a nice place to hang around.
Saturday, September 01, 2007
I had a kenstar washing machine and the spin on it stopped working so I called up the service center and was promptly given a complaint number. I did not have a technician come to my house for 48 hours and only after numerous telephone calls and a lot of frustration. He then told me that he had to take the washing machine to his workshop to repair it and it would be gone for a further week that's when I decided to buy a new washing machine since the machine was anyway getting spoilt every 8 months or so.
So I went and bought a new washing machine. The machine was delivered promptly and efficiently. I then called up LG to set up a installation and demonstration and I was promised that someone would be here in 24 hours. Its been 72 hours now and all I have got is a call from the technician telling me that unless they get 2 or 3 installations in my area they are not going to come to my place. He then went on to tell me that since I had already waited for 2 whole days I should wait for another 2 days before they come. If this is the standard of service it looks like all that the company is bothered about is to sell the consumer the product and not care about after sales support. I have gone on to install the washing machine myself having got fed up waiting for them to come.
Another instance of their pathetic service was when I bought an LCD TV. I had the TV sit in a box for two days till I escalated it to their area manager and only then was the technician sent to do the installation. Unfortunately in this case I could not do the installation myself as I needed it to be wall mounted so that my DTH connection could be plugged into the TV.
I have a broadband connection from Hathway. There are times when this connection just goes off and even if you call up the call center they have no idea when it is going to come back up even though the problem is at their end. The answer that they give is that what is your problem it is not working for anyone in your area. It will come when the problem is fixed but we dont know when it will be fixed. They have no sense of ETA's and care of the difficulties that the customer may be going through.
Companies should understand that to retain a loyal customer base selling a good product is not enough - they also need to ensure that the customer is happy using the product. They should give realistic estimates of when they can service a request. If companies do not take service level agreements seriously then they are only losing customers that they managed to get with their good product.
Professional servicing is a new concept in India and there are few companies with whom I have had good experiences such as Tata Sky and Eureka Forbes. But this needs to percolate to all the other companies.