Ravi Mohan's Blog

Friday, April 27, 2007

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.

Tuesday, April 24, 2007

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.



Thursday, April 19, 2007

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

A Rogue Researcher's Route Map

One of my resolutions for this year is to make the transition from coder to researcher. While the journey is still very much ongoing and the end point is very far away, I believe I have a sufficient number of bruises from falling into pits (and the callusses from digging myself out of them) to make a few notes that may help illuminate the first few miles for anyone attempting a similair journey.

One of the problems of "doing research" is that it is mostly undertaken in the context of somone undergoing a PhD or other academic program. There are really no guides for the non-academic researcher who wants to do research for the fun of it or as an adjunct to his day to day work. Most of the online 'guides for the perplexed' assume you have been admitted into a stellar PhD program. This advice is useless to someone who is not in academia.

What follows comes from my experience in trying to scale the walls of research. I believe that a formal academic program is the best way to acquire research skills. If you can manage an MIT PhD, go for it. But I also believe one can contribute to the sum of human knowledge without that background. I believe I can more or less do anything I want to. I am kinda stubborn that way. So take all my advice with a mountain of salt.

What follows is written for the non academic researcher, working part time. Those in a full time academic program have much better resources and don't need my ramblings.

With all those caveats in mind, here goes,

  1. Be sure you want to be a researcher. And why.

    The answer to "why" is intensely personal. You have to find your own answers.

    I want to be a researcher because I want my working life to be intellectually rich. Enterprise programming is too boring. Back when I was building the umpteenth banking/retailing/insurance/leasing app, I found I could coast too easily and work with maybe 10% of my ability and still keep up with some of the best programmers in that space (Most of them were working at 10% capacity too. This led to endless "losers club" sessions. Some of them sold out and became project managers. And got more frustrated. Others just got frustrated).

    The nature of the work (at least the variety that washes up on the shores of the Great Outsourcing Destination), is an endless repetition of a few mundane tasks. The complexities of enterprise software are in my opinion arbitrary. Too many snake oil methodologies, not enough deep thinking. Lucrative, yes. Stimulating, no. In a nutshell, I was bored stiff.

    I actually like programming. I enjoy reading technical books. I read technical (and these days mathematical) articles or books on a plane jouney or just before sleeping. I chose programming as a career because of the intellectual challenge inherent in it - that a good chunk of it ended up writing horribly boring enterprise software is a tragedy we won't delve into. At least in the future, I would like my working life to consist of wrestling with significant problems, not assembling api's like a jigsaw puzzle to create systems that I don't care about. (hey if you like enterprise software , good for you. I don't. Please don't fill my mailbox with whiney comments about how Banking apps are really uber cool).

    As Douglas Comer says in his article (after a lot of warnings about not getting into a pHd Program for a the wrong reasons),

    "If you have the capability and interest, a research career can bring rewards unequaled in any other profession. You will meet and work with some of the brightest people on the planet. You will reach for ideas beyond your grasp, and in so doing extend your intellectual capabilities. You will solve problems that have not been solved before. You will explore concepts that have not been explored. You will uncover principles that change the way people use computers."

    I want all of that. I'll probably go through a PhD sometime in the future but think a lot of what Dr Comer outlines is well within the grasp of a dedicated individual with good programming skills and access to the internet (well, perhaps not the "work with the brightest people on the planet" part, unless you consider collaboration over the internet "working with"). I can live with that.

  2. Do the groundwork.

    This is avery hard step for someone who is working in the industry vs in academia. There is almost always a substrate of very technical (and often highly mathematical) material you have to digest before you can comprehend (leave alone work in) research areas. My interests are (broadly) in Artificial Intelligence (more specifically Machine Learning) and Compilers and Programming Language Theory. The former calls for a good grounding in Calculus, Linear Algebra, Information Theory and Algorithmics. The latter needs a good grasp of things like the (typed) lambda calculus and Automata Theory.

    Theoretically if you've gone through an engineering or science Bachelors degree (BTech or Bsc, particularly in Comp Sci), you are supposed to know a good chunk of that. Anyone who has done a Bachelors in India (excluding the IITs and IIScs) knows that most people study this stuff 2 days before the exams (which are too often memory oriented) and forget everything two hours after the exams.

    For those who doubt this, I suggest the following experiment. First get a moderately tough problem in say Calculus or Probability. Find someone in your office who has graduated from an Indian university in Engineering or Science with a good GPA . Ask them to solve the problem. Enjoy the reaction. Contemplate the fact that an "engineer" (or "scientist") is ignorant about Calculus.

    Indian technical education very often consists of memorizing formulae without getting an intuition for the concepts behind the formulae. Un(?)fortunately ,to work in research one has to understand the underlying math or science.

    Working in Enterprise Software makes this situation worse. In spite of the Industry's endless thirst for Engineering and Science graduates the cold hard fact is that you very seldom use any science or engineering when you work on the typical Insurance or Banking web app. You end up endlessly churning APIs (ORMs, Rails, hibernate blah) and methodology artifacts (e.g uml diagrams or storycards) and (more often than not) fitting chunks of horrendous code together with spittle and prayer. Work on such systems long enough and you forget what little you retained from those years of education.

    It took me amost two and a half years (after leaving that "enterprise" job) to acquire the background skillset. It may take you less time. But it will take some time. And if this time is spent in adition to your 9 to 5 job, be aware that this part of the work is a very very lonely path.

    You've achieved the necessary skill when you can read a paper from a contemporary journal or conference in your field, like you'd read a news paper article or a requirements document. Another milestone is when you lose your fear for mathematical notation and proofs :-)

  3. Find interesting problems to work on

    This is the toughest step for a non academic. You literally have no starting point, no end point and no route connecting the two . As my friend Tejaswi (an MTech from IIT btw)confirmed in a private conversation, most Masters degree theses are suggested by the "guide" professors who oversee your work. Even for PhD students, who are expected to do a lot of unsupervised work and thinking, the input of these guides is a vital component of problem selection. Rightly so. You can save humungous amounts of time and effort if someone knowledgable points you in the right direction.

    But what do you do if you are not an academic but still want to do research? You have no "guides". Talented researchers have tonnes of work already and are too busy to respond to whiney emails from wannabe researchers, so how is a poor ex-enterprise coder to find significant problems?

    Here are some things that worked for me.

    1. (Once you've got a grip on the fundamentals) Work through the core textbooks in your chosen field with a particular focus on working through (and coding up) the end of chapter exercises. Every field has a set of "core books" written by the some of the best researchers in that field. Find a suitable undergrad text and get to work. (For AI, Artifical Intelligence , a Modern Approach is an excellent choice. For compiler theory something like TAPL or EOPL would be a good starting point).If you are diligent, you'll eventually go beyond these books and start working through graduate texts. Once you've got a couple of grad level texts under your belt, you are ready to find problems.
    2. Read contemporary papers.

      This is the KEY step to finding problems. Most (good) papers have a "work to be done" section which is a rich source of problems to attack. Most papers and conference proceedings are onlinethese days.All hail the Internet!

    3. Discuss your research with folks who are doing similair things. In a city like Bangalore, this is fairly tough, because most of the software "hackers" are doing cheap labor, not research, but maybe your uncle is a professor in one of the IITs or your cousin works in the ISRO (indian Space Research Organization, for those who don't know). Talk to these people. In my experience, they are glad to work with someone who is genuinely interested. If all else fails (shamelessly) tap your friends who are working on their Masters or Phd or post-doc degrees.
    4. Start a research notebook to record your thoughts and activities.

      I have found this practice VERY useful. As would a blog ( a private one is better imo) to record your daily progress(or lack of it). The habit of taking small steps daily (or biweekly or whatever) is very important.

    5. The essence of "finding a problem" is to ask a question that (a) hasn't been asked before and/or (b) has no answer yet. research is all about finding answers to these questions. Put like that, it doesn't sound *so* hard does it? (yeah well it DOES sound hard .. :-P )
    6. Be self directed.

      This is a KEY personality trait. In mosts corporate settings you always have someone telling you what to do, (by) when to do it and sometimes how to do it. This is similair to a Masters course. A PhD student has to be much more self directed , but he still has deadlines and guides and colleagues. Someone working alone, in his spare time has none of this. Unless you have iron discipline and can work steadily over long periods and tolerate boatloads of ambiguity, you might as well not start. Life is too short.

  4. Once you find a significant problem you need to solve it. And then publish the results. I don't have any advice to give on these steps because I am still working on my first research problem.

    However I am making steady progress. Some of the best people in the field have expressed interest in seeing how the results turn out. My research notebook is filling up nicely. I write code every day. So hopefully in about 3-6 months I'll have something to report. Watch this space.

Once you have some results you have to somehow publish them. I don't know how the academic publishing process works. I don't care. I am not trying for tenure. I just want to solve some problems and "advance the state of knowledge" . I guess I'll just publish my results on the web. I am not saying publishing and peer review are not important. I just don't know how a lone researcher can achieve this. No clue. Zip. Zilch. Nada.

So is it all doom and gloom for non academic folks who try to attack tough research problems? Not really. One weapon you have and most academics don't is your skill in programming. Most academic code sucks BIG TIME. Most of the code behind that brilliant thesis is an unmaintainable, horrible tangled mess (most academic papers don't have links to the underlying code for just this very reason). If you can use your computer as a power tool and write well designed, maintainable, tested, documented, industrial strength code, you will have an edge(a very very tiny one but an edge nonetheless) over folks who've never worked in the sofwtare industry. And if you have workd in a leadership osition in a commercial organization (think PM, Architect, Project Lead), your communication skills (both oral and written) are likely top notch. This should help tremendously.

And that's all I have. Hopefully some of that advice will help you to avoid some of the common pitfalls that beset the rogue researcher.

Sunday, April 15, 2007

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? :-)

Sunday, April 08, 2007

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.