Ankur's world

Kisaan Mandis at Chandigarh

2010-04-28T13:05:00.000+05:30

Sameer seems to have discovered the kisaan mandis recently: he's on a twitpic spree of late. That made me go back and think about my days in Chandigarh, and the mandis.

If you've never been there, it's very difficult to describe them. In all the other places I've stayed at ( and there've been quite a few), there's absolutely nothing like them.

The kisaan mandi is basically a travelling mandi: on different days of the week, it goes to different sectors in the city. Spreads out over a large ground, very well organised into a grid, with two sections: one sitting on the ground, another on thelas.

The experience shopping in these mandis is fantastic. Shopping for veggies and fruits in all other places in India is pathetic by comparison. Everything is very fresh, and quality is very high: one can blindly pick up any pieces, unlike other places where one has to carefully pick and choose each individual piece. In fact, for some vegetables, the vendors won't allow you to pick and select, and you don't mind it!

You'd wonder why I'm getting so excited about something as mundane as vegetable shopping, but it is so good. Every week, we would come back with a couple of big cloth bags completely full, and would run out before the week was over. Later, in Noida and Mumbai, we would buy half, and would still last more than a week.

The freshness, quality and variety on offer made sure we ate quite a bit of the wholesome food. Unfortunately, that no longer happens with us, and I hate going veggie shopping now.

Longing for Chandigarh now... there were so many things perfect about it. Sigh...

Email sins: Discussions over email?

2010-01-25T15:53:00.000+05:30

While email has been around for a while, they haven't been around enough for us to really get a sense of it as a communication medium.

There are lots of communication blunders people make on email. Most are just irritating, but some can be disastrous!
The irritants are themselves the subject for another post.

The one I want to talk about right now is the dangerous one: managing by email.

In my view, email's good for:

sharing information: this could include status updates, documents etc.
recording conversations: summarising discussions, ensuring everyone's come out with the same understanding etc.
basic transaction workflow: leave applications, expense reimbursements, other transactional flows where ambiguity doesn't exist.

Email's not good for discussions. Discussions are best done face to face. Even phone's better!
There are so many aspects of communication that are absent over email, nuances that completely get missed. You're dependent only on what text can give you: italics, bold, bullet points etc. Body language's missing, facial expressions are missing, voice and tone are missing! You're basically guessing at what's the objective of the message at the other side.

It's asynchronous, so you can't control how the recipient receives the message: they can choose to skim through the message, or read only the first few lines, or read it backwards, basically any way other than the one you intended! You might structure it as much as you want, but you can't control how the reader's going to read! Add the complexities of inlining comments, and it gets messier!

It's not interactive, which has big limitations of it's own. You basically have to guess at how the conversation would go, and put a lot of content out there.

Add to that the fact that people's attention spans are very short for email: often, they are in a meeting or a conversation with someone else when they read an email: or working on some other task: so their mind is really elsewhere! Big chance that they would take away bits and pieces of the message, ending up with something far different from what you intended to convey!

And finally, the fact, at least in India, that people are not very perceptive about the use of the written word: try and add nuances and tones in your email, and it will be lost on most people. If you point those out later, you'd be branded as being guilty of splitting hair...

I've been in situations where relationships have gone bad over time over emails. And because most discussions would happen over emails, there was very little need or occasion to talk in person, making things even worse.

So, my proverbial two cents: don't do any important discussions over email. No. Never. Not once.
Push it out to a face to face meeting. If not possible, pick up the phone. If still not possible, delay responding: perhaps that'll give time for a call or in-person meeting.

The only situations when it might be ok to do it are where you're sure that you've got very strong understanding with the other people involved, and be careful there as well!

If you're a manager, find time to meet your team at least once a week. Mark 30 minutes on your calendar every week for each of your direct reports.

Don't leave it to email or phone.

Don't let it slide: it will come back to hurt over the long run.

Use those 30 minutes to bring up all concerns and review all discussion items, even if you've gone over them via email.

Try and do the same with your manager. If they are unable to find time, be even more careful about email.
If your manager can't find 30 minutes a week for work related discussions with you, you're better off elsewhere!

Fifteen movies I've seen that will always stay with me

2009-09-09T21:26:00.000+05:30

On Hari's request, the first 15 that came to mind...

1. All About Eve
2. Lekin
3. Seabiscuit
4. Forest Gump
5. Main Meri Patni aur woh
6. Sujatha
7. Requiem for a Dream
8. Crash
9. The Green Mile
10. If Only
11. The Englishman who went up a hill but came down a mountain
12. Amelie
13. Chocolat
14.Life is beautiful
15. Malena

Change needed to drive change!

2008-12-17T08:27:00.000+05:30

You Can't Get Different Results Doing the Same Thing

The first paragraph sounds so familiar!
This makes so much sense, one wonders why we don't get it.

Good leadership

2008-11-30T21:14:00.000+05:30

Good ones:

http://karyng.typepad.com/soaking_in_samsara/2008/11/what-i-have-learned-about-leadership.html

I specially like #2,3,4.

White box, black box: people

2008-09-13T11:08:00.000+05:30

I have this mental model of people at work. I divide them into two categories:

White Box: People who's style of work and thinking is clear and transparent. People who can tell you how they think, how they do what they do, how did they fix that problem, and why did they take a particular decision.

Black Box: People who's style of working is thinking is not clear. When they deliver, you don't know how and why they did. When they fail, you don't know why they failed.

You'll find both kinds of people around you. And there will be 'good' people in both categories: people who deliver consistently.

Software development is full of both kinds of people. I've seen a few that will be able to quickly resolve a crisis or a weird bug. But if you ask them how they did it, or why, or sometimes even what(!), they don't have an answer. Their motto often is " Just tell me what to do, then go away, don't bother me. Come back to me in 2 days, and this thing will be done". These are the black boxes. Very scary, because you're always wondering: will it be solved this time?

I also think that the white box box people have a better sense of self. They are less likely to be surprised at such workplace events as the performance appraisal.

I strongly believe that in roles that have ambiguity, you must have the white box variety. The trouble with the black box variety is that you don't know why they succeed. When the situation involves a large number of variables, the environment is changing all around you, I feel safer if I can feel confidence in the inherent ability of the people, rather than their history of success. Because in a changing environment, history is not a good predictor of future. But inherent ability is!

Perhaps my white box people are the people with strong analytical skills, and the black box people are the ones with weaker analysis? Maybe. But there might be more. For instance, the ability to communicate the analysis is important. As is the ability to understand your own mind!

Letting go...

2008-09-13T10:51:00.000+05:30

I've now been part of three startups. One of them as a founder, and the other two as a part of the management team.

I often compare the other two founders in my mind. One of the big differences between the two has been that one is more than happy to let go... of control. He's believed enough in his team to delegate and forget. Of course, there are some checks in terms of discussions, reporting etc., but by and large the team has the ability to take decisions.

The other one has not found it easy to do that. Most decisions flow from the top, the team feels constrained. He is involved at a very minute level of detail, when perhaps he needs to leave those to the team and concentrate on other things. This inability to believe in his people, I think, is costing the company dear.

In our own case, perhaps we did even worse. We believed in the team too much. Not that the individuals were not capable enough; but you need to balance delegation with reporting and monitoring. Otherwise, you're dependent on the capability of only one person. In a startup, that can be fatal, as processes don't exist to catch mistakes, and the environment is too fluid.

One of these companies can be considered a clear success. The other one, a little early to decide.

Here's another take on this issue, from an entrepreneurs.
Building an open culture

My own thought, as an entrepreneur, is that the way to do this right is to hire people that you can rely on in a white box (more on that in another post, but basically someone you can rely on because of the way they work) mode.

Once you've got those people, delegate like crazy, and allow them to take decisions. Let them be entrepreneurs in the garb of an employee.

I like to think I did that well in my own company. Will I call my company a success? Not in the financial sense, but I think the reasons were elsewhere. Did we hire the right people? Absolutely yes. If and when I start another company, quite a few of them would be the first set of people I'd look to hire.

Writing unit tests will delay my project... really?

2008-09-09T19:58:00.000+05:30

Don’t Stop for Gas… We’re Already Late! » 6th Sense Analytics

Great post. Love the thought about confusing activity and progress.

Tell us how it can be done, not why it can't!

2008-08-29T09:07:00.000+05:30

Support functions in all organisations: I think they have got it absolutely wrong.
Most of them are so utterly fixated on rules and processes, one wonders if they leave their brains at home!

Their existence itself is to 'support'. That's the nature of their work. But all of them, without fail, across almost all organisations, take upon themselves a 'higher' meaning: as if their existence itself is the reason for their existence.

IT support, finance, payroll, admin... Does any of them not do this? HR, sometimes, is one exception.

On top of that, they will not hesitate from using regulatory or technical reasons to avoid answering the question Why can't it be done? Hoping that most of the people will get deterred by it. When actually almost all the time, there is no underlying technical or regulatory reason at all!

Some recent examples:

We have to deduct both income tax and FBT on your allowance. Because that's how the government wants it. Real reason:I can't be bothered to take the effort to track your allowances.
We can't deduct extra tax from your income, even if you give us a written request. We are not allowed to do it. Real reason: I don't have any idea how this works, no one's asked before, I can't be bothered to go read up the rules.
I need an urgent salary advance. It is approved by the head of HR AND my manager. Oh, well, oops. Needs approval of the CFO too. By the way, we will send you a check for the advance, not deposit it directly to your salary account. And did we mention, the check will be on a different bank, so that it will take 3 days after you deposit the check for money to come in? Of course, it's the 29th already, so your normal salary would probably have come in sooner!

These were the finance guys. The other ones, some other time.

If only they could change from Why it can't be done to Let's find out how we can make it happen!

Affirmative Action and Muslims in India

2007-01-06T14:17:00.001+05:30

In political or social discourse, or even in the drawing rooms of our country, a mention of Muslims flares up emotions. In most cases, they are extreme emotions: it is rather difficult to carry out an intelligent, rationale conversation based on arguments.

Of course, the polity of the nation has become such that things are completely polarised and false notions and data abound.

Recently, when Manmohan Singh talked about the need for affirmative action for Muslims, once again there was a big hoopla.

But do people stop for a moment to think about the Muslims they see around them?

I have two instances of blatant discrimination around my day to day life.

We bought a flat at one of the hot new real estate destinations in NCR, Indirapuram, a couple of years back.

And this was at the most professionally run of all the builders out there at that time. They were telling us about the kind of people who will inhabit the apartment complex: professionals: doctors, senior executives etc.

And here's the part that shocked me:

We are not selling to any Muslims. When they come asking, we tell them we're all sold.

Another one:

We just moved to a new home last month, and were looking for maids. The rates were way higher than at other places. One girl came in, started out asking a rate that was already 20% lower than the others, and looked clean, earnest and honest. But we didn't hire her. Reason? She was a muslim.

We really wanted to. Believe me, we did. But half of our parents and grandparents would probably refuse to visit us, because a Muslim had touched the kitchen. Perhaps they would have been ok if she did not enter the kitchen, but the response would have varied from " Oh my god, a Muslim" to "what's the urgency to hire a muslim? Aisa to h nahin hai ki hindu bai nahin mil rahin? Phir kya jaroorat hai"?

What is a muslim to do in the face of such discrimination? Don't they deserve some help and push from the people who can?

Crash:

2006-12-30T12:56:00.001+05:30

Saw Crash recently. It was mesmerising. Every scene was a revelation. It captures a couple of days from the lives of a few people living in Los Angeles. The main characters are from different parts of the world: white americans, black americans, first generation arab immigrants, second generation arab immigrants, mexicans...

And mixes them all up: throws them together. They meet at various times, in varying contexts, with varying results. World view changing results. Your view of racism and race relations goes all topsy turvy. You learn of the complexities involved in the social lives of a multi-ethnic society. Real nuances, real detail.

At first, a lot of the characters seem to be from your regular movie, caricatures: the racist white policeman, the young black thug,... And then the twists start. The racist policeman is not. And the white anti-racist partner is.

Couples coping with their different ethnicities and what it means to the world. Racism is multi layered and not unidirectional. Layers get peeled, and new insights emerge.

There are some incredible turn of events, but they are all completely believable. And they all open new lines of thoughts.

Bottomline: 5 stars. Must watch. And tell me what you thought about it.

Will Mohali get to watch the match in Mohali?

2006-10-05T19:38:00.000+05:30

The office had a day long powercut today. They were testing the floodlights in the Mohali Cricket Stadium, in preparation for the Champions Trophy. And Mohali doesn't have enough power for both the city and the stadium, apparently. So we ran through hoops trying to keep our service up for customers, while the lights shown on the already bright grass.

If that's the situation in day time in test, what will it be like when the lights are on at night during a match? Chirag Taley Andhera? People all over the world watch the match, but someone with a home across the road can't?

Company culture: what do we think of employees?

2006-06-06T17:33:00.000+05:30

Animesh » Blog Archive » Who is your employee?
Animesh has an interesting post on it. I've added my thoughts here:

I think the family model is very well suited to a startup, mostly
because it is almost a necessity: in a startup, the boundary lines
between work and home and not well defined. In my experience, it is
true even if not all employees are white collar workers.

But keeping the same model as the company evolves into a bigger
organisation is probably not suitable and not feasible. You *want*
people to clearly delineate their professional and personal lives for a
better balance. And the returns to all stakeholders from the family
model become much lower.

Treating employees as customers is definitely the way to go. To me,
there is no other option. At least for the support functions, it should
be obvious that the rest of the organisation is their customers,
because, well, what else are they supporting?

Unfortunately, at least in India, that is often not the case.
Support functions often run as their own fiefdoms, and I think that
often goes on because the executive team doesn’t pay much attention to
them. I think the way to resolve this is to measure performance based
on customer feedback, as for the ‘core’ function. (But that’s
digressing…)

Automation

2006-02-17T17:38:00.000+05:30

We did some bits and pieces automation on one of our projects over the last few months. It impressed some managers at our customer, who then asked to start a separate project to do end-to-end automation.
We just finished the first iteration. Now, once you have stuff set-up and configured, the following things happen every night:

the application is built and packaged.
The install elements: war, database dump, sql scripts, install instructions, release notes get copied to a release folder. The release is named by the timestamp.
The application is installed and configured on a remote machine.
The application is started on the remote machine.
Some automated code review tools are run, and reports generated in a nice consolidated format.
Junit tests are run on the deployed application, and code coverage reports are generated.

So, the next morning, when the team comes in, they know if some things broke. They can also spend 15 minutes running through the code review reports and test the application for sanity.

If a formal release needs to be made, that is also a single command : you just specify the tag name, and all of the above happens. In addition, source also gets tagged.

What's next: integrating canoo web test or some other similar tool with the deployed application, so that the nightly build can also do the sanity tests.

Finally, we are getting close to becoming the cool dudes of automation!

Great Places to Work at

2006-02-15T15:04:00.000+05:30

Just read the cover story of Business World of 6th Feb. They have rated the top 25 places to work at in India. Across industry sectors. Here are some excerpts I found interesting ( in that I've been trying to get some of these through at my workplace.) Here's some validation that these things do happen in India.

Many of the organisations in our list have unlimited sick leave, no attendance recording system and self-supervision as the norm.

True collaboration goes beyond employees setting the menu for the canteen… It requires an ability to share 'real power', as is reflected in RMSI's decision to empower employees to calculate their own performance bonuses.

Sasken prides itself on its 'single status' policy… All employees, including the co-founder, and eligible for the same travel benefits.

Amex… shares details of the salary ranges, how these were evolved and what comparator companies were used to determine them.

There is a direct relation between great places to work and superior financial performance…. During the period 1998-2002, an annually updated index of Fortune's 100 best companies to work for would have yielded a return of 9.86%, compared to -0.56% from the S&P 500.

(This one, of course, is US data)

At RMSI, when negotiating with those who leave, managers are forbidden from offering higher salaries as an incentive to stay back. At best, they can offer a different assignment or more responsibilities.

At JW Mariott, revenue and profit and loss figures are shared with all employees across levels, eve dishwashers.

At Aztec, to engage employees, CEO… sends out regular emails to them that are presonal, inspirational, and at times, even philosophical.

Sapient's senior-most bosses, its two managing directors, do not have their own rooms. Seriously. They do not even have their own cubicles or work stations.

At PSI Data Systems, employees were constantly kept updated of the company's true financial picture, orders that were in the pipeline and stragies that would change the company's performance. ( Even when the company was in the red.)

What IS asap ?

2006-01-05T09:02:00.000+05:30

Really.
What IS it ?
People all over the place keep throwing it at you.

I need two loadrunner resources asap.
The customer wants to see the plan asap.
What's the priority of this task ? "asap".

Well, OK, I know what they really mean. They mean to say that it is urgent and pressing. Maybe I'm just nit picking on language. But indulge my language issue for a bit: ( BTW, I'm no grammar expert)

Start Nit Picking:

As soon as possible. As if anyone ever plans any differently. Have you heard of any plans that use the as late as possible principle? Of course I'll do it asap. That's how I do all my stuff.

End Nit Picking

OK, understood. They mean urgent. But that's still little help. That helps little when planning stuff. If I have 10 things to do on my task list, maybe this will take away 3 of them, the 3 that are just nice to do. But what about the other 7 ? Should I just drop them and spend all my time on this one? Or spend half my time on it? Should I spend more money to get this done?

Well, yes, I can find the real urgency by asking the right questions, but doesn't it help if some are already answered ?

To end, here's a customer who regularly sends us tasks over emails that start with " This is urgent as well as important". :-)

Bugs that are difficult to reproduce

2006-01-04T07:35:00.000+05:30

An excellent post on how to investigate these most tricky of bugs: ones that take place once in a while, and you cannot figure out how to reproduce them. Basically for testers, but very useful for developers as well.

Be the best place to work at ?

2005-12-11T21:36:00.000+05:30

A few days back, in an internal management forum, we were talking about the increasing attrition and importance of retaining people. One of the PMs talked about how a few people in his team asked him " Why should we stay?"

That's really it. That's what we need to answer. If we don't have an answer to that (besides the nonsense about it being a challenge, and a fast growing oganisation etc.), then we don't have much of a chance.

What are the reasons for people to stay? Or, what do people look for? Here's the regular list:

Compensation: includes salary and stock options
Quality of work
Role
Quality of life ( relates to work life balance and the city you work in)
Brand

Let's consider a small services organisation that does not have the best pay scales, does not have much to offer in terms of work content, and where teams often come under schedule pressure. Is obviously not a recognized brand, and is located in Chandigarh ( Great quality of life, but not very relevant to most of the target employee group.)

What does such a company do ? Does it have no hope?

I think it does. It can do one thing that is relatively easy for a small organisation to do, and which can potentially make a big impact on employees, (although probably none on prospective employees.)

Try and be the best place to work at.

That's it. Everything else pretty much follows. I think one can start by putting together a few guiding principles. Use them to check each action and policy: if they don't fit into the principles, then they are acceptable. Here are some that I believe would be good ones:

The small guy always wins: Whenever a decision can go both ways, err on the side of the employee. When creating a policy, use one that leans towards the employee.
Believe in people: Create policies based around faith in people. Assume that people are honest. In most cases, they are, and the few dishonest instances will be far outweighed by the benefits of faith. For instance, don't count leaves from attendance on a daily level: just inform the manager on a monthly level, and let the manager take a call. If an employee asks for the ability to make business calls from home, accept that she needs it.
Be pound wise, penny foolish: Don't bother with small expenses. A 200% hike in a shoelace price means nothing compared to a 1% hike in the shoe price. Don't put a tight control on RAM purchases while not controlling PC purchases.
Don't always be an accountant: Not everything needs to fit exactly. If a team party budget is Rs. 300 per person per quarter, it is OK for it to go above 300 once in a while: it will balance out on the whole. (Other projects will use less. If everyone is using more, perhaps the budget needs to be increased.) If a little above 300 is not OK, people will ensure they never let it be a little below 300 either: they will use all of it!
Communicate: Provide people information. Where are we, where are we going, how are we doing. Perhaps revenue and profit numbers. Definitely new accounts, new initiatives. Have executive management address people once in a quarter, send out mails regularly. Ask for feedback. Act on feedback. Keeping people informed encourages the belief that they matter.
Empower: Involve people in decisions. Allow them to suggest and take ideas to completion. For a small company, having entrepreneurial employees is essential. You will keep them only if you empower them.
Be open: Believe in transparency. If you have a cost constraint, admit it. Share with people the logic of decisions.
What others do is not important: Don't look at what other companies are doing: that will at best make you the average. Do what fits in with your guiding principles. If you must compare, compare with the employers that top the employee satisfaction charts!

0 to 100 in 2 months

2005-12-11T19:43:00.000+05:30

Obviously, I'm not talking about motorcycles or cars :-)

I was having a chat last week about setting up a new office, and I was asked if a software services firm could go from 0 to 100 in 2 months in Chandigarh. I said no, and that 4 months was possible, adding that it might be possible in Delhi.

This was all on a hunch. Later, I started thinking about what would it take. Let's see. First, let's start on the less ambitious goal of making 100 offers in 2 months. I'll make the following assumptions:

We pay at the 60th percentile
We do at most 2 rounds of tech interviews, and most people who get to the 2nd round are selected.
We work only weekdays.
1 in 5 candidates who get to round 1 get selected.
1 in 5 candidates the recruiters talk to get to round 1.
1 in 5 resumes recruiters look at are called up.

Here are some numbers:

100 offers in 2 months mean 2.5 offers a day.
2.5 offers a day = 3+ 2.5*5 = 16 interviews a day = 80 screenings a day
16 interviews daily mean at least 7 interviewers
80 screenings mean at least 7 recruiters
In all, over 2 months, talking to 3200 candidates, and sourcing 16000 resumes!

If the recruiters can generate this sort of number, it doesn't look so bad.

Now let's see how this converts to offers accepted and joinings.

Not more than two thirds of the people you make an offer to will join. This includes people who reject the offer and people who accept but do not turn up.
To end up with a pipeline of 100 joinings, you need to therefore do about half as many interviews more than you needed to for 100 offers.
That takes the total interviewers to 11, and recruiters to 11 as well.

If you're starting from zero, it gets worse, because it takes a while to recruit your interviewers! But let's say you already have 100 employees. It would be a scramble, but you just might be able to make 11 interviewers out of them.

Take the target to 4 months, and things start to look a little easier: you need only 6 interviewers and recruiters, with the time lag also providing bandwidth to do other stuff, like running the business, training people, building the brand, etc.

Do the numbers sound feasible ?

Life Insurance in India

2005-11-28T12:16:00.000+05:30

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...

Checked exceptions

2005-11-27T18:08:00.000+05:30

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?

Types of load tests

2005-11-27T16:00:00.000+05:30

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?

To invest in real estate or not

2005-11-19T18:34:00.000+05:30

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.

What's with pro-rating salary revisions?

2005-11-17T12:49:00.000+05:30

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!

Culture issue in the Indian services industry ?

2005-11-15T17:50:00.000+05:30

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!

Why blog ?

2005-11-15T17:41:00.000+05:30

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!