Ravi Mohan's Blog

Thursday, August 04, 2005

Light In Dark Corners

Updated to include an opinion on Google India

Joel Spolsky has written an excellent article where he explains why it makes no sense to hire mediocre programmers for Product Development.His thesis is that mediocre programmers just cannot hit the "high notes" that top grade programmers can (read the article) and since the cost of reproduction of software is essentially zero , software products live in a winner take all environment .

He also points out that this does not apply to non product software development . I quote ..

"Sadly, this doesn't really apply in non-product software development. Internal, in-house software is rarely important enough to justify hiring rock stars. Nobody hires Dolly Parton to sing at weddings. That's why the most satisfying careers, if you're a software developer, are at actual software companies, not doing IT for some bank. "

The programmer who is in the top 1% and prefers to create enterprise software vs product development (almost ) doesn't exist .

But beyond that there is one more factor that ensures that companies which create mostly enterprise software accumulate mediocre(and worse) programmers over time . And this is the "per hour" billing model, which immediately puts the goals of the consulting organization and the client organization at loggerheads .

The client organization gains by reducing the total number of developer hours (and the dollar per hour rate of the individual developer) . The consulting organization gains by increasing the number of developers and the dollar rate(which is mostly done by hiring people with greater "number of years of experience , there being no objective way to measure "goodness of value delivered" ) . Thus sheer economic logic dictates that client and consultant pull in opposite directions. Most of the dysfunctionality of enterprise software development arises from this fundamental anomaly .For example the relentless pressure most consulting oranizations face to add "resources" comes from this "increase the number of people on a project " (rather than "deliver more value " ) mentality. And this pressure eventually translates into terrible people getting entrenched in even the finest organizations . Then of course you need more "committees" to manage the mess that results, and new games come into existence , all resulting in the more talented people fleeing or giving up.

This downward pressure forces the client to outsource the work ("You say it takes 20 developers , 3 managers and 5 QA guys? ok but i want 15 developers,2 managers and the QA folks in India at India rates" ) .

Product development work (not maintenance!) is almost never outsourced.Product development companies do the initial development of projects wherever the really good programmers are (and pay them really well . The money involved would give most "enterprise" developers heart attacks) and then outsource the bug fixes, operations etc .(the spiels of "India/China/--insert cheap offshoring destination here-- has top grade talent and so we started an office in Bangalore/Shanghai/wherever" are trotted out to make sure the offshore developers feel happy and often have no basis but the decreased "dollar per hour" rate for mindless repetitive work) .

So the best programmers in developed countries have nothing to fear . The average devloper who can churn out endless jsp/xml/ejb etc needs to be terribly afraid. And rightly so .

The one possible point of satisfaction in enterprise software comes from really understanding a deep clientside problem and writing good code to fix this. Alas, even this is denied to offshore programmers who have to play many games (see Eric Berne's "Games People Play") and fight amongst themselves like dogs to get one of the coveted "onshore" assignments and get anywhere near the real clients(where they are still paid less than the local developers) .The only strategy(in the Game Theory sense) that has a positive payoff in the offshore developer's world is to join the ranks of management as soon as possible and leave "lowly" work (and most of the work is terrible) behind . Then you can enjoy a "money for nothing" existence (at the cost of having a "meetings, committees and paperwork" life and losing your technical skills, if any ).

There are some efforts going on to change the basis of payment from the insidious "dollar per hour" concept .But so far nothing has been very succesful because changing the game would mean that both clients and consultants would have to actually think of what they are doing and calculate the ROI of every feature they add(and God forbid that such heresies come to pass :-) ) .

Meanwhile developers , if they are hell bent on developing enterprise software, should probably join one of the better companies around and pray (very, very hard) you get a greenfield , challenging project.

But the question remains.If you want to work with the best people and have a satisfying life working with technology why flirt with Enterprise Software at all? Do you really (really really) get your kicks writing Banking Software ?

And even if you do, it may make sense to constantly re evaluate your commitment .Here is a simple way to do this .

When you get up in the morning, knowing you have to go to work , do you smile or grimace? And when you finish the average working day ,are you happy, having learnt something new and created good features ?Or has the daily grind just chewed up another 8 (more likely 12, if you are in Bangalore) hours of your life leaving you drained and exhausted ?

Update : Apparently Google does things differently (Why am I not surprised? ). I say "apparently" because I have no confirmation yet.I was told that Google's India Office is really about hiring only top notch talent and not outsourcing for cheap labour.Apparently anyone who makes it through their (very tough obviously) interview processes can select which office they want to work for .In other words at the end of your interview process you can choose to work out of,say California or Zurich . If true , this is absolutely incredible and needs wider publicity in Bangalore!

Anyway this blog entry was mostly about the yuckiness of most outsourced enterprise projects and not about product companies,although it remains true that most product development is done abroad . Google is about as far from "yucky" as you can get .

9 comments:

Bijoy said...

A good post again. I have a question - how do you identify, strictly mathematically - who are good programmers and who are mediocre - given that you have a chance to interview the person say for 1 hour. What - if he is not on his high-tone at that time?

Ravi said...

Bijoy,
You raise two different issues. I will address them in order .

I am not sure what you mean by "strictly mathematically" :-)

If the question is "Is there a completely objective (as in the human element can be totally removed) way of identifying a good programmer? " , my answer is " I am not aware of any " .If there were a mathematical way of doing this, we could probably program it into a computer and let it take care of hiring.

As for the second issue of a candidate not being at his best on the interview day , I would guess this is a smaller problem than it looks like .

First . most interviews these days don't depend on a single evaluation or even a single day's interview .Most interviews, esepcially when the company explicitly targets "elite" programmers,have mutiple sessions spread out over go on for days , if not weeks .

Second , i would think that programming ability woul be at certain high level for the truly gifted programmers , even on off days .If a candidate can't answer basic algorithms/design/domain questions (which are the riule for most interviews) even on your off days,there is somethng seriously wrong !

Thirdly if a programmer is a top grade hacker it is immediately obvious to the seasoned interviewer , just because an interviewer sees so many many mediocre candidates .

As an illustrative example, out of the 200 or so interviews i conducted for Thoughtworks, I reccomended just 3 people (two of whom accepted the offer and went on to be outstanding em[ployees ).It was obvious after 10 minutes of conversation that these guys were way above the average. Tthe greatest pleasure for an interviewer is to wrte "unreservedly reccomended" on the feedback forms .But alas, this is an opportunity that comes rarely

Fourth ideally the technical candiadte would bring along a laptop and show code that he is particularly proud of and/or is a conributor to a significant open source project so that the "quality" factor can be assessedmor objevtively than by just answers to questions .

Having said all that , there *is* a small posibility that a combination of evil factors can result in an outstandng candidate being rejected(very) occasionally . There is , in my opinion, nothing to be done about these extreme cases .Life is like that !

Rajesh Babu said...

I don't understand what Bijoy means by "strictly mathematcially". May be Bijoy will clarify.

In my experience, I have always been able to find whether a programmer is better than the rest.

My experience and theory is this as follows. When you ask questions to someone the answer is not the only thing. The way the answer is delivered and the way it is explained can give good clues.

A programmer I would love to have with me is one who keeps learning new things, new ways of doing things and practices it. The programmer also will be an "experienced rookie".

I have been working with ThoughtWorks for the last two years. There are at least 3-4 interviews, along with coding and pairing sessions.

Also I would suggest reading Blink by Malcolm Gladwell.

Ravi said...

There is no way to edit a comment on blogger. So I had to delete a comment to remove one word. Anyway here it is, with just one word (the company name) removed.



Manoj said...

I would like to add something what Ravi and Rajesh said: good programmers must be involved in the hiring process if you want to hire good programmers. From my experience I would say that:

1) A reasonably good programmer is far more likely to be able to tell who is a good programmer and who is not compared to a mediocre programmer. Case in point: a programmer I know who is quite good at what he does was rejected by "Company X" after being interviewed over the phone. I am 100% confident that the interviewee in question could not be failed on the basis of a phone interview alone.

2) Mediocre interviewers often approve of others of similar or lesser skills while they actively discourage interviewees whom they find "elitist". "Elitist" being a perception that derives out of the fact that the person being interviewed is better than them and cares little for what they hold dear to their own heart.

bijoy said...

I'll try to elaborate what i meant by "strictly mathematically". Obviously, i agree that human element and judgement is the single most important differentiating factor in selecting good people. But, what my instincts suggest would not be the similar to what someone else's instincts suggest. So what i am looking for is an objective way to define good programmers. As far as the process is concerned - in most cases - that i have come across - you are required to make a decision at a spur of a moment, many times - just by talking to the candidate on the phone (while he is travelling) and asking him some questions that rarely give you any idea of his real skills.

In most of the interviews that i went through - i have seen people asking me questions about syntax of a language!!! I simply can't understand this. Whenever i have taken interviews - i have always concentrated on as Rajesh babu said - how has he answered the question - has he touched that "core" thing in the question.

But my fear has always been - getting the wrong people because people have learned to fool on interviews so much. I know people who almost can crack any interview - not by the virture of their knowledge - but by the virtue of experience. In IT, it would not be difficult to find find people who give on an average one interview per month!

Ravi said...

Bijoy,
I will first separate out your concerns .Then I will post my opinions . Hopefully Rajesh will post his insights as well.

Your concerns seem to be

1.If a developer's skill is primarily judged subjectively by the interviewer(s), then what if these subjective decisions are wrong? Wouldn't an objective method be better ?

2)If decisions have to be made with incomplete/insufficient information(your example of a phone interview) then how does one judge correctly especially since many people can 'game 'an interview (your example of people who can "fool" interviewers)?

3) the apparently trivial natuire of many interviews ,especially asking syntax and such .


Well my answer to the first question is that

1.Many companies do not judge *purely* subjectively .There is often some direct testing of coding ability or other skills(logical thinking) having (or being seen to have) a direct correlation with coding ability.

2.The decision is not as "subjective" as it may look *given competent interviewers* .The interview after all is not about some subjective topic like the meaning of a shakespeare play . Assuming the interviewers are competent the whole conversation would be about very hard core technical issues (at least for a technical position).It is very hard to bluff your way through *if* the interviewer is competent . And s Rajesh pointed out a competent interviewer knows in 5 minutes if he has an exceptional candidate on his hands .(fwiw , I interviewed Rajesh for TW and i knew in the first 30 seconds that he was waay above average even given the high standards at TW) .

Now the big IF here of course is the matter of teh competence of teh interviewer .Unfortunately one does run across various tupes of incompetent and semi-competent interviewers.

An easily recognized type is that of a person who has solved a specific problem in a specific way and will not accept anything else as a possibly correct answer .Thus the entire interview becomes a "guess what i know ,ha ha you are not telepathic enough " session.

Good interviewers expect to be (and like being )challenged . Not so good interviewes get defensive .

Well an inter-view means you are judging the company just as much as it judges you . When you get an obvious fool like this you can decide what to do all the way from smashing the interveiwer flat, to manipulating him , to playing along hoping to get through this round etc etc .(Ihave done all the above at varius points in time) .

As for me personally I treat interviews as a fun game. You go to a new comany, meet some interesting (one way or another) people , maybe geta free lunch and maybe a job .

Most good developers have no problems cracking any decent interview without "gaming" it . so why not treat the whole process as fun ?

The next point is what to do about people who "game", for example by knowing anwers to frequently asked questions .

Again assumng competent interviewers it would be extremely hard for someone without genuine knowledge to get through .

If the interviewer is not particularly clever or has outdated knowldge, throwing around "buzzwords" might help .But a company that hires such people is not worth working for anyway .Life is too short for that .

Having said all that interviewing has aspects which need to be learned by interviewers .

Yuor concluding thought was
"But my fear has always been - getting the wrong people because people have learned to fool on interviews so much. "

The easy way out of this would be to ask extremely competent,patient people with exremely high standards to interview your candidates .

The HR people in TW for example, used to be happy enough to go ahead and hire anyone i said was at least "fairly good " because i was known to give that judgement very (very) sparingly , and as mentioned earlier every single person i have reccomended was way above average .

And the whole premise of the post was that you shouldn't hire anyone not well above average (unless you are some kind of body shop/cheap offshoring company ) .

The making a decision on the basis of *just* a telephone call looks very alarming .Maybe you had some very specific situations in mind ?

The only justification for asking trivial syntax questions is (perhaps) as an initial cutoff question to filter out people who have great cvs but know zilch .

I personally don't use syntax questions but have an array of simple questions that filter out 90 % of the fakers . A good interviewr gets "deep" very fast .If (s)he contniues to ask simple questions , one after the otehr then one of the parties involved in the interview is clearly incompetent!

and lastly , the most objective test i have found for developers is to ask them to write code .As a mental experiment,if a candidate regularly contribute patches to the linux kernel or mantain some open source code I can look at before talking to him, I don't have to dig very deep for the technical skill !

I would focus on other aspects instead.

Bijoy said...

Cool!

Can i request you to write an short article on this to sum up the discussion and post it atleast on your blog if not - send it to few HR and IT journals.

Also, can i request your email-id. Would like to forward you a mail that i got just now. Mine is bijoysr@yahoo.com.

sundar said...

hi ravi,
i disagree with you stmt that good ppl would always prefer product dev over enterprise sw, if this is what you mean. i work in the world leader is enterprise management software and i work on product dev. this has been hapenning for two years now. at some point of time you do get bored with the same stuff being done and wish for variety in your work.
regards
~sundar
http://techgossip.blogspot.com

Ravi said...

Sundar,

Please read the article carefully.
I said "The programmer who is in the top 1% and prefers to create enterprise software vs product development (almost ) doesn't exist ."

See the "almost ". If you prefer enterprise software over product development AND are a top 1 % programmer ,(If you are, i'd like to meet you ! ) then you are part of that miniscule minority of great programmers that form the exception to the statement above ,iow exceptions that prove the rule .

I am curious though . what product are you developing ? and who is this "world leader in enterprise management software"?

Are you located in India ?

Are you maintaining a product or developing one ?

And did your company start a branch in India to develop this project from scratch ? or to use cheap labour to maintain/extend it ?

If this "world leading enterprise management software" was conceived of and developed in India then you are certainly an exception and i would like to know more about it .

After answering all these questions, you may want to re look at what I have written and see what exactly i said wrong ?

And as for disagreeing with me don't worry about that ! Out of disagreement comes wisdom.

If you want to continue this conversation by mail instead of commenting here , please mail me at magesmail@yahoo.com !

Thanks for your comment .