IIT Grads ! (necessarily) == Good Programmers Redux

When I wondered some time ago why the best programmers didn't come from the population of IIT grads, many people claimed I had all sorts of motives (ranging from jealousy to fear) for having such "heretical" thoughts.

Now some other folks seem to offer a degree of vindication.

From the latest Outlook magazine (You can read the first page of the article here - I am not sure how long the url will be valid). For those too lazy to click on the link, an excerpt

What has triggered the discussion within the fraternity is the concern expressed by two distinguished IIT alumni about the general decline in standards of excellence at the institutes in recent years. Their remarks have questioned the calibre of students who make it into the IITs by subjecting themselves to the killing rigours of coaching factories in places like Kota and Hyderabad. The alumni seemed to conclude that these products of coaching factories—who now form, according to Wikipedia, 95 per cent of students at IITs—had a blinkered approach to education, did not recognise new ideas and had lost the spirit of inquiry and innovation. In short, elements that had built Brand IIT over the decades had now gone missing

The first salvo was fired by Tata Steel MD and IIT Madras alumnus B. Muthuraman. Speaking at a Ruby Union meeting of the pioneer batch organized at his alma mater in January 2007, he said that tisco was "not likely to recruit" IIT graduates any longer. He based his opinion on a recent interaction he had had with a set of final year students, who he said did not even know the authors of books they were supposed to have studied. He made many other related statements suggesting that IITs thrive only on their "past reputation" and that he actually preferred other college students who were amenable to company training.

Now before the frothing-at-the-mouth defenders descend on this blog, I am not saying that IIT grads are poor programmers. What I AM saying is that in India there is no correlation between programming ability and the school of the programmer. Any company that hires only IITians AND (boolean AND - do read this sentence carefully before sending off that hate mail) hopes to recruit impressive programming talent by doing so is asking for disaster.

An IIT is *not* Stanford or MIT or CMU. Not even close. If you doubt this, first take a look at a typical PhD paper (in say Robotics) from any IIT you choose vs say Stanford. Then tell me I'm wrong. Thanks in advance.

Learning From Sudoku Solvers

Ron Jeffries attempts to create a sudoku solver - here, here, here, here and here. (You really ought to read these articles. They are ummm...{cough} ...err.... enlightening.)
Peter Norvig creates a Sudoku Solver.
Compare. Learn.
Update: Discussion on reddit
somewhat peripherally related but similiar (this about the bowling game) discussion
The devgrind post
Update 2:
(Oct 2009) Peter Norvig spoke about this post in Peter Seibel's book, "Coders at Work". My reaction..
Update 3:
Peter Siebel author of "Coders at Work" weighs in. Some gems there.
"One thing I noticed, reading through Jeffries’s blog posts, was that he got fixated on the problem of how to represent a Sudoku board. He immediately started writing tests of the low-level details of a few functions for manipulating a data structure representing the 9×9 Sudoku board and a few functions for getting at the rows, columns, and boxes of the board. (“Boxes” are what Sudoku players call the 3×3 squares subsquares of the 9×9 board.)
Then he basically wandered around for the rest of his five blog postings fiddling with the representation, making it more “object oriented” and then fixing up the tests to work with the new representation and so on until eventually, it seems, he just got bored and gave up, having made only one minor stab at the problem of actually solving puzzles.
I suspect, having done a small amount of TDD myself, that this is actually a pattern that arises when a programmer tries to apply TDD to a problem they just don’t know how to solve. If I was a high-priced consultant/trainer like Jeffries, I’d probably give this pattern a pithy name like “Going in Circles Means You Don’t Know What You’re Doing”.
.....
(Norvig has) 7 definitions in 12 lines of code and he’s done with data representation. I’m not sure how much code Jeffries ended up with. In his fourth installment he had about 81 lines devoted to providing slightly less functionality than Norvig provided in the code we just looked at. In the fifth (and mercifully final) installment, he started adding classes and subclasses and moving things around but never presented all the code again. Safe to say it ended up quite a lot more than 12 lines; if he’s lucky it stayed under 120.



" Siebel's post is worth reading in its entirety.


Update 4:
Andrew Dalke's Problems with TDD (and the comments, some by eminent TDD proponents) reveal TDD's feet of clay.

Restored Comments

A quick perusal of blogspot's comment moderation page showed me that some comments were pending. Generally I get a notification in my gmail account, but for some reason these didn't make it.

Sorry.

All the comments have been restored. They are scattered across many posts. The best was Ryan Cooper's comment on "If Toyota outsourced .. ".

Ryan, I agree with most of what you say. I still think the Poppendieck's books are worthless. But reasonable people can disagree. :-)

Asok's Own Country

Recently, a friend (we'll call him M) invited me to his company's annual day party. First the CEO made a speech about how they (the folks who work at the company) were "creators of history and not just passengers". People clapped. Then the party proper started.

Well, sorta kinda. The Mistress of Ceremonies declared that "the bar is now open". One small problem though. You couldn't just walk up to the bar and get a beer. First you had to locate a "coupon distributor", get a "beer coupon" and then walk over to the bar and hand over the coupon and the bartender would hand you a beer. If you wanted another beer, you had to rejoin the line. (I am NOT kidding. This really happened. I was there, as were 200 or so others, so I have plenty of witnesses).

M, (by now thoroughly embarassed) joined the long line, and after inching forward for about 20 minutes, arrived at the head of a line and asked for "two coupons please". The person dispensing the precious scraps of paper. The Person Behind the Counter -PBC from now-, took a long and incredulous look and then said frostily "Only one coupon per head. sir".

M: "so, if a party of four want
 beers,all four have to line
 up and get their beers"
PBC: "That's right"
M: "ok... if they want another
 beer, they need to join
 the line again."
PBC: "That's right sir!"
M: "All four of them"
PBC (beaming) : "That's right, sir!
 Here is your beer coupon"
M(handing it back): "Do me a favor friend,
 Have a beer on me" 
(walks away).

Creators of History? :-)

Scribes and Programmers

A long time ago, there weren't too many people who knew how to write. So if John Ancient wanted something written he would visit the local scribe and pay a fee. I am not sure if the scribes ever formed a guild but I wouldn't be too surprised.

These days, if Joe Modern wants a program written, he needs to hire a programmer (or a bunch of programmers) who'll translate his needs into the appropriate incantations.

Imagine a world where a majority of people know programming - perhaps not enough to write an operating system kernel but enough to write a basic Rails application - say a ToDoList application. (I did say "imagine"). How would programmers evolve?

I think they will become largely "post technical" - a term used, sometimes pejoratively, to describe developers who've moved away from code-centric jobs. The term is mostly applied to folks who go on to become managers, an idea which is looked down upon by some developers.

In a world where most folks could program, post technicalism would be the norm. A large chunk of present day programming jobs would simply disappear. You can't get a job these days if you "know all 26 letters of the English alphabet and can form grammatically correct sentences in English", which is the level at which a large majority of "professional" developers "program". Knowledge of writing is required but not sufficient for a paying job today. A doctor needs to know how to write but he also needs to know much much more. Musicians, biologists, teachers - all could do with a basic knowledge of programming. Perhaps basic programming skill should be taught just like reading and writing are. Then the idea of writing a quick script to generate a graph from a database wouldn't be some kind of exotic skill , but a basic competence expected from educated people.

Would this disappearance (or submergence below the awareness level) of programming skills be a bad thing? Not really. Technological progress has rendered many jobs obsolete over the centuries and humanity has coped very well.

Also, there would still be a need for people having extremely high levels of programming ability, just as there are professions that need extremely high levels of writing/communication ability - think copywriters or diplomats. The folks who focus on algorithms and networks and compilers and other 'deep programming' would probably survive just fine.

Of course the writing analogy can't be stretched too far. Documents are created by one person or a few people at most, over fairly short periods of time. Most significant programming projects involve large groups of people working on the same codebase for significant amounts of time, sometimes decades. The main challenges (as measured in terms of completion and impact of the project) are about people issues - how to hire them, how to retain them, how to make them work together.

And this organizational difficulty of managing large groups of people and getting them to build something coherent is the space in which, at present, many snake oil vendors (think "lean " or agile") thrive. The presence of snake oil is often an indicator of a fundamental and intractable problem. So even if a large number of people knew how to program, the organizational aspects will need hands on resolution. Thus the "project manager" type person would be alive and well. The VB/j2ee/dotNet folks are the ones who'd disappear.

But is the "manager dude" the only evolutionary path available to code jocks? I think not. For example, the world of science and engineering (modulo software "engineering") would still be open. Yes, there would need to be a lot of study - mathematics and statistics and the sciences and particular engineering domains - you won't be able to grab a book called "Java X.Y in 24 hours" and get a well paying job. People wouldn't be able to make money doing the equivalent of writing other people's letters for them. But I suspect there will be a lot of fascinating problems to solve, even in our imaginary world.

Even in a world where everyone codes, the "path of the suit" would still remain the Dark Side. You would still need to think long and hard and try to balance gain and loss before setting out on that path.