I've been looking around to buy some life insurance: about time one thought of financial security for the family....

Here's what I need: insuring my family and perhaps me against loss of income. That includes any event that impacts my earning in my profession.

As I'm doing my research, I found some interesting points:

• There is a huge variation in premiums between companies. For a 25 year term, 20 lakhs coverage at 30 years of age, it varies from Rs. 6000 to 12000! In this kind of business, why would anyone go for the higher premium? All companies are well established, and all have similar contracts. When asked this question, the costlier ones have little to say except the vague 'our service is better'. That means nothing: anyone can claim that!
• The concept of disability insurance does not exist. When asked about that, people offer the ADD (accidental death and dismemberment), which hardly covers disability.
• Riders: Generally, they offer three: ADD, critical illness, and WOP-(withdrawl of premium, I think). I don't quite understand any of them.
• ADD: In this case, you get double the face amount in case you die in an accident. If the idea is to cover death which comes without warning, it probably makes sense. But I think they don't cover all such cases, for instance, terror attack or natural calamity. If that's the case, what's the point of buying a higher cover for accidental death?
  
• ADD: Moreover, why not allow me the option of buying dismemberment insurance without being forced to buy accidental death as well?
• critical illness: This one seems to have wandered into the wrong business. They pay out the cover if you suffer with a list of pre-defined illnesses. This includes non-systemic ones such as heart attack. You might not have lost your income. This sounds totally like a health insurance product! Actually, not even that - they are not covering treatment expenses: just paying out the cover!
• WOP: Ensure that your cover remains if you stop paying premium. Now why would anyone need this? The only situation where you will stop paying premium is if your income stops. And if your income stops, life insurance is meaningless to you!
• It is extremely difficult to get insurance agents to understand that I'm only interested in risk cover: they keep throwing investment cum insurance policies at you! Some even insist that in their plan, risk cover is 'free'!!! A lot claim that in a given investment plan, I would get minimum 10-12% returns. And the way they say it, one would reasonably assume that it is guaranteed return, and that's what they want you to assume. But mention that word, and the truth comes out.

All of these suggest to me that the insurance business in India has a lot of growing up to do - it is still very early days.

And I'm going to have to live with the risk of a long term disability...

Of late, as I've started reading blogs, I've seen a number of discussions on checked v/s unchecked exceptions, including in the context of C# v/s Java. Some well known people thinking Java, such as Bruce Eckel, also think checked excptions bring more trouble than they are worth.

Yesterday I was talking to my new colleague who comes from Microsoft, and he pointed me to an interview with Anders Hejlsberg, who created the C# language. Here he talks about why they chose not to include checked exceptions in C#. A number of other major arguments are similar. ( I'm too lazy to go back and find the links to all of them, so believe me, or search yourself :-) ). Here is a summary of my understanding of the argument, which is essentially a practical rather than conceptual argument:

• As you move up the hierarchy of methods in an app, or if you are building a huge system, the number of checked exceptions you need to catch keep increasing.
• You don't care about most of these exceptions.
• As a result, writing catch blocks for each of them irritates one no end.
• Therefore, most people just write

catch(Exception e){
\\ error handling
}
with the intent to come back later, which never happens.

• Therefore, checked exceptions serve little useful purpose, hence they should go.

If that's really a correct summary, (which I hope it is not), then I don't think I need to state where they are wrong. But let me do it anyway:

• If it's a feature that most people ignore, that doesn't mean it is not useful. Without the feature, those people won't do a better job of handling exceptions. With the feature, at least some people are doing a good job. Even they will not be able to do a good job with unchecked exceptions.
  
• If your methods are throwing a large number of exceptions, and/or you catch them with the block above, you are doing sloppy programming. Sloppy programming can't be used as a reason against a feature. ( Yes, it can be used as an argument to try and improve that feature.) Moreover, if your programmers are sloppy, they will probably do a worse job without checked exceptions.
• If people won't use exceptions properly, which the compiler partly forces them to, they certainly won't document their code properly, which is the only thing you can rely on when you don't have checked exceptions.

Having said that, the point about the empty catch block is one that I can identify with - have seen lots of people do that. But I think the solution is rather simple, although one that cannot be enforced by the compiler:

• for your application, create two base exceptions: MyAppApplicationException as a checked exception, and MyAppSystemException as an unchecked exception.
• subclass MyAppApplicationException when you have a new handlable error situation.
• subclass, or use MyAppSystemException when you have a new non-handlable error situation. Also use it to abstract out all lower level system exceptions.
• Client code: catch the specific instances of MyAppApplicationException that you can handle, and then, if there are any more, catch MyAppApplicationException. These two together mean that you catch only those that you care about, and can ignore the rest.
• Enforce this through the use of automated and manual code reviews.

Another argument Anders used is that checked exceptions break versionability - that is, if I need to add an Exception in a later version of my API, then I will break backwards compatibility.
I'm a much lesser programmer than Anders, so I'd take it as given, except that I don't see his point at all. Checked exceptions are part of your method signature, because they are part of your contract with client code. If you come across a need to add or remove a checked exception, you are altering behavior of your method. How is that conceptually different from adding or removing a parameter?
Let's assume for a second that there might be situations where you can alter the Exception list without altering behavior. You are probably doing it based on complaints from your users, so they will probably need the change anyway. Of course, they will need to modify code, but that would be for a real pressing need, right?
Even if you do need to add Exceptions that should not require changing client code, using the BaseException approach allows you to do it: all client code only needs to always have caught the BaseException.

Assuming that we use the BaseException approach, are there still any problems with Checked Exceptions?

I got into a bit of an animated discussion at work last week about Load Testing, and what it means. The other people involved were senior QA and delivery folk. We couldn't agree on a common understanding of the concepts, forget terminology. A search onWikipedia also failed to provide a clear explanation.

Here's what I think about it. To me, there are three concepts, and between them, they cover all aspects of testing a system under load. Everything else is a combination of these. The terms I use for them may not be the same as the terms other people use, or perhaps they use other terms for these concepts, but let's focus on the concepts. (I'm using web based application terminology here, but I guess it should be similar in other situations.)

• Performance or Throughput: You load your server to various number of users, and measure the throughput, or response. Again, normally done in pages served per second, or average page response time.
  
• Scalability: Define the lowest throughput that is acceptable to you. Then load the server (for instance, by increasing the number of users) till the throughput starts going below the defined one. The number of users logged on at this point define the scalability of your system in terms of users.
  
• Reliability: Let the system run under extreme load ( same as above), for a large number of computations. In the webapp world, use a scenario that visits all your pages, and let it run for a long long time: time really meaning pages served in this case. Look at two different measures:
• number of faults occurred. This gives you a reliability measure by the standard definition.
  
• amount of server resources consumed. ( RAM, disk space, DB connections, file handles etc.) This should stabilise after some time, and stay there. If any of these keep growing, there's a resource leak.
  

Here are a couple of (horribly drawn) pictures. But I hope they are allowing me to put my point across:-)





These are the basic concepts. A number of variables vary based on your goals and your application, but the concepts remain the same. Here are some examples of things that will vary:

• number of pages in reliability: for an intranet performance review app for a 200 people company, 50,000 requests would probably be a lot. For an amazon.com type of application, we're probably talking hundreds of millions or billions.
• the server resources you measure.
• the metric you use to measure througput.
• How do you measure 'concurrent users'. For instance, you might have your users wait 1 minute between actions, or not wait at all.
• Your acceptable throughput threshold.
• Number of concurrent users you want to measure throughput for.
• Server configuration
  

When executing these tests, typically you will do multiple iterations, across multiple installations, and do all of these at the same time.

One of the item the others did not agree on was the y-axis in the reliability test. They didn't agree that number of pages served was the right number there. I believe that number of pages is the only term one can use there - the x-axis is upto you. And here's why:

Ultimately, all your measures are relative to the agent driving the application, because the agent is responsible for getting your functions called. In a webapp where everything is done via a web page, this agent is your end user, who only makes page requests. Hence the only true measure of 'life' of the application is the number of pages served.

I find quite a few people talking about load testing, including our customers, without really being clear about what they need. In this particular case, they started saying 'load test'. I put across this definition, ( or rather, had the on-site guy do it) and they came out with: well, we can do those as well, as long as they are useful! I doubt he had any better idea of what he wanted even then.

At one of my previous jobs, at an enterprise product development organisation, we did all three - for reliability, we ran through 500,000 pages, which took us a couple of days. For throughput, we wanted at least 0.1 seconds of page response time. Scalability we just measured in throughput terms.

Does this sound like a reasonable definition of load testing? Am I missing something?

These past couple of months, the wife's been talking only one thing - invest in real estate. And she's not alone, with backing from both sets of parents. We already have a flat, and are currently paying the EMI for the loan for it. Currently, we are looking at 3-4 opportunities, and she actually wants us to invest in two of them!

All of them have the firm belief that in real estate, one never loses. This belief, along with the same belief for gold, seems totally unshakeable and firm. It seems to be etched in stone, with metal cast into the etching, and a force field put around the whole thing.

All efforts to show them the other side seem meaningless. But there ARE a lot of arguments against investing too heavily in real estate. Here are a few, in random order:

• Real estate doesn't have a secular upwards trend. This rediff.com article mentions some previous crises in UK and US. But why look outside - we have had bubbles in our metros as well - I've seen one in Delhi around the year 2001.
• With easy and cheap credit available, and tax concessions, a huge number of people are investing in real estate - very often in more than one property. That's speculative investment, which means it becomes a zero-sum game.
• In my parents' generation, for some of the reasons mentioned above, and due to much lower purchasing power, most people were lucky if they could purchase a home before retirement. Result - relatively little speculation, and a largely secular upwards trend.
• Real estate is a product that has little inherent value - it is driven purely by supply and demand, and it's inherent value doesn't change with time. Combine this with the fact that things are changing very fast these days in India, specifically infrastructure. For instance, there were no takers for Dwarka in Delhi till the Metro line was announced. It took the Dwarka market onto a totally different graph. In the NCR, the metro is and will continue to strongly impact real estate. Similar arguments hold true at other places - four laning of highways, expressways, the hype around IT parks and SEZs in various cities.
• Unfortunately, there are no means available today to invest small amounts in real estate. Even for the richer category of salary earners (in the software industry), a single home is often at least 2-3 times the gross annual income. A second, or third investment therefore, takes you out to almost 10 years of gross income. I agree that actual investment is much less, because it's all on loan, but you are screwed if you get caught in a bubble, because you will need to hold on much longer to recover from the loss! If only they had real estate mutual funds for the small investor!
• While multiple EMIs might not make a huge dent on your monthly savings, the loan duration would definitely be long in that case, increasing risk for you all around - risk of rising interest rates, as most loans are floating rate; but more importantly, liquidity risk. If you end up needing a biggish amount of cash in a hurry, you will need to hurriedly sell off your property. Given the relative lowe liquidity of real estate investment, you could end up losing. Finally, the more loans you take, the bigger the impact on your family in case something happens to the earner. Very few people end up insuring their home loan against loss of life of the earner.
• Someone told me a good rule of thumb to find if real estate prices are out of whack - rental income should give you 5% annual return. At that rule, my under construction flat in Indirapuram near Delhi probably just about makes it at my purchase price, but the current market price is way out of line! The same seems to be true in a number of cities in the country today.
• As of today, we hear warnings almost every day - fom the RBI about banks' exposure to housing sector lending, to chairmen of housing finance companies and so on about a possible bubble.
  

Having said all that, probably will end up investing in two more properties, keeping in mind the following:

• Ignore the metros, and look at tier 2, upcoming cities. Examples for me: Jaipur, Chandigarh ( though these two have had huge price increases in the last year), Agra.
• Diversify by investing with others: invest in two places, with a 50% share in both, with close relatives: parents or siblings picking up the other part.
  

I've seen this in a lot of organisations: they 'pro-rate' salary revisions. The latest, of course , was an internal policy about pro-rating increments based on when the employee's anniversary appraisal took place. Here's what it means:

Say the salaries are revised every Decemeber. If I joined in March, and in December the company decides that I should move to a 10% higher salary, I actually get a 7.5% hike. (10%*)9/12.

To me, this makes absolutely no sense. I can see that you would want to do it for bonuses that are linked to company performance, project success and individual performance, because the employee's contribution was limited by the period she was there.

However, for salaries, the same does not apply. After all, what is a salary revision exercise? It is about revising salaries to make sure that they are in-line with your wage bill goals, keeping in mind the following factors:

• market rates, and your company's positioning
• the wage bands for various levels in your organisation ( which would have been redefined by the new hires in the last year)
• review of the employee: past performance, future projections, potential
• the employee's value to the organisation.
• and perhaps, where the employee is currently at.
  

So, a salary revision, in my mind, is not about deciding a percentage hike: it is about deciding a target number. You first get to that number, and then work out the percentage from there.

If you do it that way, which I think is really done everywhere, where's the logic for pro-rating? At any point that you are revising a salary, you revise it to the 'right' number based on the factors listed. The fact that the employee has spent only 9 months with the company, or that he had got a revision only 6 months back, is of no relevance to the number that is 'right' today.

Following a percentage hike approach also results in communicating it the same way to the employees, which has the following problems:

• it fosters and shows a mindset where salary hikes(revisions) are treated as perks/rewards, rather than adjustments.
• it encourages comparisons between employees by employees. People can compare in any case: converting into percentages is easy. However, with the percentage approach, you are inviting them to compare.

There's only argument I've seen in favour of pro-rated revisions. I consider it a weak argument, for reasons outlined below, but even then, it works only in situations where you're on a secular hike path - that is, ALL revisions are hikes. Which is mostly true today, but doesn't make for a good policy because it is a temporary situation.

Here's that argument:
- people who joined or got a hike less than a year back, got the 'advantage' of a revision early, while the other employees wait till the next revision.

And here's my counter:

• How do you know what part of this person's 'higher' salary is due to change in market, and what part is due to his skillset?
  
• The right number today does not change by that fact. Remember that this person would then also be 'below' the right number for a full year. So if you have to pro-rate, the right approach would be to ensure that the 'gain' this person got is dissipated in the next 12 months. If you just pro-rate it, this employee ends up losing over the total period to next year. But doing this kind of math is probably impractical.
• If the salary situation is changing at such a fast clip that you are think pro-rating is needed to balance it, then you should think about doing salary revisions at six monthly intervals rather than annually. ( You probably anyway end up doing that on a ad-hoc basis, for reasons such as managing attrition.)
• If the new person is getting this extra advantage, remember that he is also losing because of the switch - he will need to invest in establishing himself again at a new place, with new people.
  
• Even if you want to pro-rate, don't present it as such. Use that as one more factor when calculating the number, and tell the employee the number along with the various factors.

So, my plea: Don't talk of percentages when revising salaries!

Here are some thoughts I shared with my development teams yesterday. ( I work in a software services firm based out of Chandigarh, India). Some of these might be unique to my organisation, but some are definitely very common in the Indian services industry, specially the first one.

These few thoughts, to me, are the undercurrents beneath a number of issues and problems that we keep getting into at work.

Does this sound familiar ?

The customer is better than us: (also known as the customer is happy with this)

To me, there really is no basis for this, other than perhaps that we are giving the customer what they have done in the past, or what they are happy with. But there are lots of pitfalls in that reasoning. The badly designed code supplied by the customer could have been written by a fired employee/contractor. It could have been written by employees new to the technology when they wrote it. Current team at the customer could be replaced by people who know better. Any customers expect us to be masters of our technologies. At , we have had a customer who knew nothing about junit, so there we no requirements to write junit tests. But he heard about it in a conference, and was rather angry at us for not having suggested its use ourselves. This customer had been very happy till then!

Ultimately, in today’s world, most often, most ideas can be argued. And with google, you can also add references to support your position!

2. Everyone here does it this way, so this is right: (also known as: in all my jobs, everyone has done it this way): Your universe is too small here. Try google to find a bigger universe.

A lot of this is also related to #1: most places that you have worked at probably also suffer by number 1, specially as most work in India is maintenance/support work, where you live with what you get.

3. The app already has it this way, so we should continue doing it the same way: Consistency of implementation is important, but not in all situations. Think through whether consistency brings you some advantage beyond just consistency. In most cases, it does not, specially if the existing approach is just bad. Having a consistent style of braces is useful, because it is only a matter of style. But eating up exceptions is plain wrong. I can present other reasons, but I think this should be enough.

4. Ctrl-C Ctrl V, (also known as: I’ll copy this design without understanding its context): Sort of self explanatory. We look at a design/implementation approach at one place, and copy it blindly into other contexts. When confronted with a why?, we often only have the answer that this is being used at place x. That’s no answer. If you agree with it’s use at place x, AND you can argue that x and your place are similar, ONLY then is it a valid answer, otherwise not.

5. Google does not exist (also known as: we can’t look for other opinions/ head in the sand/ how do I validate this): Fortunately, google does exist.

6. The problem will go away if I ignore it (also known as: no one else will notice it): unfortunately, someone always does!

Things have been rather quiet at work for a while. So I started looking around, and read a few blogs. When I did, I realised that a lot is being said that is close to my heart, and/or needs to be said. And a number of well known people are saying stuff that I thought was not relevant to people outside my context.
Now that I know that my troubles (and my ideas ) are not mine alone, I'm going to talk about them!