Automated Testing and Programming Skills

Joel Spolsky's lecture at Yale university makes some interesting points about the dangers of automated testing. Joel is good at latching on to the unintended consequences of latest trends, especially the kind that nerds with Asperger's typically overlook. He speculates that 'automatic testing religion' was what did Vista in. There is an interesting bit about the fate of testers without programming skills at Microsoft:

Microsoft has had a long term policy of eliminating all software testers who don’t know how to write code, replacing them with what they call SDETs, Software Development Engineers in Test, programmers who write automated testing scripts.

I can sympathise with this, having interacted with testers without programming skills myself. If Microsoft's policy were to be adopted in India, there would be quite a few unemployed testers. Joel's article is a helpful reminder of the dangers of overdoing automated testing. But I think the situation in India represents the other extreme - we have lots of testers without any real skills just trying to fill up bug trackers and warming chairs in head-count based projects. Automation is the last thing that concerns either testers or software companies in India. After the dot-com bust, testers have become an overvalued commodity in Indian software companies with clueless managements.

John Gilmore's test of a good programmer

John Gilmore suggested to me a test of a good programmer: one who has written a piece of software that at least 1000 people have downloaded from the Internet.

- Arun Mehta

OLPC Laptop Application Virtualization

I was listening to a fascinating presentation (video)by Ivan Krstić, the director of security architecture of the One Laptop Per Child (OLPC) project. What struck me most was the extent to which virtualization is being used. Unless you have been living under a rock, you know that virtualization is a 'hot' area now. But this must be one of the few attempts to use it to provide desktop security (Incidentally Anti-virus tools routinely use virtual machine containers) The Bitfrost security model involves running each application in its own virtual machine container. As the Wikipedia entry explains,

Every program, when first installed, requests certain bundles of rights, for instance "accessing the camera", or "accessing the Internet". The system keeps track of these rights, and the program is later executed in an environment which makes only the requested resources available. This is implemented by a fully-fledged, container-based virtual machine.

By default, the system denies certain combinations of rights; for instance, a program would not be granted both the right to access the camera and to access the internet. Anybody can write and distribute programs that request allowable right combinations. Programs that require normally unapproved right combinations need a cryptographic signature by some authority. The laptop's user can use the built-in security panel to grant additional rights to any application.

Running each application inside a virtual machine is a scary idea, especially given the hardware configuration of the OLPC laptop. Krstic explained that the Linux kernel VServer patch had been extended to do OLPC specific tasks. Perhaps, the most fascinating piece of information that I learnt from the whole talk was the low overhead associated with such Linux VServer virtual machines. Quote from Krstic's presentation:

"The interesting thing about this, by the way is you know people are terrified of how are you going to do virtualization with 466MHZ CPU - turns out with Linux Vserver that the overhead you pay is 32 K per task struct, but there is 0% measurable CPU overhead with up to 65,000 Virtual Machines running ."

I have mixed feelings about this approach. Having done virtualization related work for the last two years, I find this approach fascinating;but, it could also start a disturbing trend of people opting for this approach instead of trying to solve security problems at a more fundamental level. But I got to admit that the clever Copy-on-Write approach of the VServer just blew me away. As Krstic said after explaining the low overhead associated with the virtual machines,

"I will let that sink in for about two seconds"

It's not as bad as the Sendmail configuration file

But the Apache web server configuration file is pretty close. I once heard one of the founders of the Apache project confess that, the only configuration file worser than it was the one used by Sendmail; I mean, that's not saying much, is it ? I wasted the whole afternoon yesterday wrestling with the VirtualHost directive. Finally, I threw in the towel and got it working in five minutes with twisted web. It's httpd.conf that's twisted. All I wanted was a couple of web servers on my laptop to test my program. The worst part - it makes you feel so stupid for no fault of your own.

The Glorious History of HR in Software Companies

Mitch Kapor's wife Freada was in charge of HR at Lotus in the early years. (As he is at pains to point out, they did not become romantically involved till afterward.) At one point they worried Lotus was losing its startup edge and turning into a big company. So as an experiment she sent their recruiters the resumes of the first 40 employees, with identifying details changed. These were the people who had made Lotus into the star it was. Not one got an interview.
- Paul Graham in a footnote to his essay News from the front

Extreme Pair Programming - Guy Steele and Richard Stallman

"We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type.

The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it."

The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life."
- Guy Steele on a hacking session with RMS in the 1970s.

Beautiful Code - The Paris Hilton Connection

The odds of finding truly beautiful code in most production systems seem to be on par with the odds of finding a well-read copy of IEEE Transactions on Software Engineering in Paris Hilton’s apartment. Furthermore, enterprise software, which represents the bulk of code in existence, deals mostly with forms, reports, etc., which – one might argue – seldom require much thinking or cleverness.

- Albert Savoia in a post on O'Reilly's Beautiful Code blog

It's not just enterprise software - you find bad code in lots of startups, where there is an exclusive focus is on getting things done rather than doing it correctly. In fact, even lots of open source code bases are full spaghetti code. A great hacker even recommends FreeBSD code over Linux code.

Sadly, a lot of Linux and Gnome open source is poorly written.

- Trevor Blackwell in response to 'How can I become a better programmer ?'

Startups are not Democracies

If you are not one of the founders of a startup, you really need to aware of this. I wish someone had reminded me about this :-( .

Startups are not a democracy. Want a democracy? Go run for class president, Bueller.
- From Mark Fletcher's 15 Startup commandments

The Dirty Secret of Blogging

That's one of the dirty little secrets of blogging: the discussion in the comments are often better than the original entry. - Jeff Atwood

Simplicity, a feature

Recently, at work, I had to use the XML-RPC.Net library and couldn't help smiling at this tongue in cheek answer in the FAQ section.

Why use XML-RPC instead of SOAP?

If your clients and servers are all running in the .NET environment there is no point in using XML-RPC: .NET provides excellent support for SOAP and XML-RPC doesn't have any features not provided by SOAP (other than simplicity).

- XML-RPC.NET FAQ

Why Developing Software for Indian Companies is Not Easy

I was reading an article Indian IT biggies losing out to MNCs, when I came across a very interesting and insightful comment by Chanakya. Yet another instance where a comment on an article is far more interesting the article itself. A couple of years back, I quit my job since I couldn't not handle the irrational pressures involved in developing for certain Indian customers - I quit even without having another job in hand. I know of a very idealistically motivated software company that had created a great ERP product for the SMB market - the last I heard, they have stopped trying to sell to Indian customers and were focusing their sales efforts mainly on the US and Europe. It's not for want of idealism, or lack of technical competence, or domain specific competence that you find very little serious software development work targeted at the Indian market. Most of the the fine folks who have tried are suffering from Indian IT market burn-out, for the reasons for which are so eloquently explained by, Chanakya:

It is very true that the Indian IT companies are failing to corner big deals in the domestic market. Both the IT companies and the domestic clients are to be blamed for that.

Let us first start with the Indian clients. Their IT awareness is quite poor. Their business processes are also not very much IT-dependent. In fact most of them view computerization as an additional burden - a sort of necessary nuisance. The business processes of those companies are so non-standard that it becomes rather difficult for them to get the real benefits of IT. Today's well evolved softwares require clearly defined and standard business processes and, most important, discipline as pre-requisites. For example, to get the optimum performance out of a Merc you need proper roads and disciplined traffic. Otherwise its high costs of acquisition and maintenance seem to be unnecessary burdens on the owner.

With the exception of banks, telecoms and a few Indian pharmaceutical companies, almost all other Indian companies across the sectors have those inherent problems. So when they do not get tangible returns from their IT infrastructure they tend to pay substantially less for the same. That is the root cause of all the problems. The Indian IT companies focus mainly on the application development side with a distinct bias for manpower intensive projects. For them the earning per employee - or 'billing rate' in the industry jargon - takes precedence over everything else. Indian clients do not pay more than one-third of what an international client would pay. Add to that the inevitable delays associated with the domestic projects due to various reasons like unavailability of proper infrastructure, stiff resistance from the middle and lower management levels who see IT as a source of extra work load, erratic payment schedules etc.

Instead of staying away from such messy, low-profit (often loss making), difficult to manage projects the Indian IT companies - with the exception of Infy - have been systematically exploiting the Indian clients for training their freshers. The domestic projects are known as visa factories. Because of the strict regulations against import of cheap labour in most of the developed countries, visa / work permit applicants need to have a couple of years of experience as a pre-requisite. How do the fresh engineering graduates get that experience? Mostly through the domestic projects!

So how the MNCs are making money out of the Indian clients? Hardware supply is the key. They make enough money from hardware components - like storage devices, PCs, servers, routers etc. - to be able to cross-subsidise the application software. Indian clients - thanks to their great IT awareness - are very reluctant to pay for something intangible which they cannot touch and weigh! Software is such a component. Hardware, fortunately, does not suffer from that bias.

Before I end this post I want to share a funny but real story of an Indian client with the readers. Around ten years back one of my friends used to work as a free-lance developer. One of his many clients was a typical Lala-type trader. After making big money in trading, he wanted to add some class to his business. So he wanted my friend to develop a software for his company. After toiling for a couple of months and bearing with the paan-chewing, gaali-spewing Lala he finally delivered the software in the form of two floppy disks. The installation and the subsequent setup went off smoothly. The bill of twenty thousand gave the trader a big shock. "Bees rupiya ka floppy de ke aap bees hazar rupiya maang rahe hai? Sharm nahin aati?", he said. It proved to be rather difficult to convince him. My friend tried to educate him first. Then only could he hope to convince him! Finally he gave up. He settled for five thousand. Last couple of years the same friend of mine is in US. He is still a free-lancer. He never goes near any client whose skin colour is even vaguely brown.

BTW, don't take that last line too seriously, I am pretty sure he just forgot to add a smiley ;-)

Open Source Development - The Perfect is the Enemy of the Good

Subversion developers Ben Collins Sussman and Brian Fitzpatrick in a talk titled How Open Source Projects Can Survive Poisonous People (And You Can Too) (Google Video) stress the need to avoid analysis paralysis . One of the ways paralysis is caused, explain the developers, is the attitude of perfectionists that makes them indulge in endless technical discussions on mailing lists - this includes seemingly interminable discussions on even minor details; The 'Painting the Bikeshed' analogy by Poul-Henning Kemp illustrates this point. As Ben and Fitz put it in the presentation, "The Perfect is the Enemy of the Good".

I wonder if that's the reason they have put up with WebDAV for so long ;-)

Dreaming in Code - Andy Hertzfeld Quotes

There are some great quotes from Mac hacker, Andy Hertzfeld in Scott Rosenberg's book Dreaming in Code.

• "My style is to get something going really quick and then turn it into the great thing that is the reason you're doing it. You're not working to have it be run-of-the-mill. You're working on it to do something great. But you need to get it started! The key is getting exciting work going; the rest of it will take care of itself. You're sparking off each other - a virtuous cycle - once you're doing the thing you're there to do."
• "There's no such thing as a typical software project. Every project is different."
• "And in this meeting, we kill the snake - we don't just make plans to kill the snake."
• "I'm the kind of developer who likes to throw lightning rods around. To make a great program there's got to be at least one person at the center who is breathing life into it. In a ferocious way."
• "My way of writing code is, you sculpt it, you get something as good as you can, and everything is subject to change, always, as you learn. But you climb this ladder of learning about your problem. Every problem's unique, so you have to learn about each problem, and you do something and get a better vantage point. And from that vantage point you can decide to throw it out."
• "Code is cheap. But often it tells you what to do next."
• "We all need more glory as designers - to show we can design another great thing. Everybody who has a first success, especially when it's young, wonders: Was it luck, or was it skill ? Well, it's a little of both. If you can do another really great one, it shows the world something."

Mary Lou Jepsen - Inspiring

At age 29, Jepsen found herself suffering from blistering headaches, confined to a wheelchair, and sleeping 20 hours a day. She was just about to drop out of school when an MRI revealed a tumor on her pituitary, a small gland at the base of the brain central to hormone production. She underwent surgery to have the tumor removed and emerged from the ordeal ready to move on with her life. “There’s a stigma when you undergo brain surgery: are you still smart or not? So afterwards I tried to challenge myself to find out.” She finished her Ph.D. in the next six months and then cofounded MicroDisplay, a Fremont, Calif.–based company that manufactures liquid-­crystal-on-silicon chips for high-definition TV displays. She left MicroDisplay in 2003, citing “creative differences” with its chief executive, but within days Intel was recruiting her.

Her health problems weren’t quite over, though. As a result of the operation, Jepsen’s body now makes no hormones, requiring a rigid schedule of twice-daily hormone supplements to keep her alive. Now that she’s a globe-trotting computer executive for the OLPC venture, the regimen can be tough to follow; last March she went into adrenal shock on board a plane, forcing it to make an emergency landing. (On the bright side, Jepsen reports that as a result of her hormone deficiency, she is unaffected by jet lag.)

That's Mary Lou Jepson, CTO of the 'One Laptop Per Child' (OLPC) project.

Writing vs. 'A Real Programming Job'

Financially, writing science fiction is to writing technical books as writing technical books is to having a "real" programming job.

- Leonard Richardson, co-author of Ruby Cookbook and Beginning Python,
in an interview.

How Come ZeroConf is Not Yet Wildly Popular

I have always wondered why Zeroconf adoption has been so poor. Stuart Cheshire of Apple who pioneered this technology, briefly explains one of the reasons in a presentation introducing zeroconf(6:16-7:30) at the 2006 Emerging Telephony Conference.

I imagine a number of people are thinking, well, if it's so great, how come I haven't heard of it ? And, that's an unfortunate history of marketing mistakes - I called it Zeroconf, but Steve Jobs thought that was a dull name. So he called it Rendezvous which is a really good name. But, some other company thought so too and they had registered the trademark.

Then we had a couple of Years of the marketing people and the lawyers doing their stuff. And meanwhile we had a technology without a name. So, in that two years every single printer vendor adopted it. But they didn't have a name to call it, which is why you won't see it on the box. But if you have a printer on your network, an ethernet printer, or a 802.11 wirless printer that you bought in the last couple of years, then it has bonjour in it. And, on the Mac you go File->Print and it's right there in the print dialog; No setup assistant, no wizard. On Windows we can't make it quite that easy. But you can download from www.apple.com/bonjour and just run the setup assistant and it will find all those printers on the network, and configure them for windows for you.

FOSS.in 2006 Notes

Notes from some of the talks/discussions, that I attended at FOSS.in, held in Bangalore between 24-26'Nov 2006.

Suparna Bhattacharya, the Linux kernel contributor who works for IBM talked about how kernel hackers are obsessed with making the code simple and the minimalist spirit that pervaded the entire kernel development. She also drew parallels with Buckminster Fuller's idea of ephemeralization - doing progressively more with less. I have noticed that this obsession with internal simplicity and cleanliness is something that is noticeable much more with the better open source projects than in corporate development environments. While it's disconcerting in the beginning, after a while you wonder how development could have been done in any other way. Interestingly Suparna also mentioned that she had used a BBC Micro at school - this tallies with my theory that a lot of good programmers are folks who have had early exposure to computers.

Aaron Seigo, the KDE guy, talked about the planned features for KDE 4 . The Tapioca project aims to make VOIP integration with the linux desktop a reality; SVG support is maturing; The threadweaver project hopes to make writing multi-threaded apps easier; Project Strigi will make desktop search seamless and has a DBUS interface; does meta-data search as well. Aaron also mentioned working with HCI teams to make KDE more usable to regular users - I personally like this idea. The KDE project's UI ideas have always seemed juvenile to me.

Luke Kanies talked about Puppet - a server automation tool that comes with it's own declarative language. Puppet is written in Ruby and is the result of Luke's frustration with existing tools. 'Developers do not think about manageability', feels Luke. He also added that there are many opportunities to add small pieces of functionality. Puppet has a central server, a portable resource layer and agents on the network that do the actual automation work. The custom configuration language can be versioned and changes tracked easily, since it's plain text. The author of Puppet is very interested in building an open community around this GPL'd software and said that it might take many generations to make the tool great, and he would help create those generations. Resources in Puppet could be anything - Packages, Users, Groups - just about any low level system object. Resources can have multiple low-level providers. The platform specific details are abstracted away. Clients or Agents provide the server with facts about the hosts every thirty minutes or so. Puppet uses SSL everywhere. Though it's been around for only a little while, it is already in production in a couple of places in Europe and US. Stanford Univ. is a paying client. There is no windows version yet and I could not help feeling that the lack of a GUI might be a disincentive to most admins.

This is one area in which I have lots of personal interest, and my current job also involves similar work. I chatted with Luke a bit. I think it's high time we had a good cross platform (*nix, Linux, Mac, Windows)open source tool in this area. It's time to kick the pricey vendors out - they waste our time and money, and have no clue about real requirements. Good luck to Puppet and Luke Kanies. Google videos of his talks elsewhere.

PHP man Rasmus Lerdorf gave a great talk on how to build a good community site and optimizing sites to handle high traffic; even though he used PHP as the example, I thought it was quite general. Rasmus appeared to be a bit upset with the loads of criticism levelled at PHP these days and pointed out the people making negative blog posts about PHP do not realize that Wordpress was a PHP application. I am not sure if this is a good defense of PHP, the language has real problems. But I think it's helpful to remember that for a long time and even now, it's a great way to get things done quickly. As he himself put it, PHP is for weekend warriors. Rasmus actually began his talk by hypothesizing about why geeks are so motivated to work on open source software or even do non-programming community work. He mentioned the case of some users on Yahoo Answers who answer 500-1000 per day questions some times and attributes it to oxytocin, the hormone that gets released during human interaction. Even geeks who rarely see daylight and live in their mom's basement, have the need to connect with other humans, and hence the motivation to take part in net communities. Rasmus feels that it's not what people think about you, but rather what they think about themselves that matter.

Rasmus observed that people should be able to improve a community site by catering to their self interest;he mentioned that no worthwhile community can be built without giving up ownership - if you don't give up control, you will never build a decent community of users. I personally think this works for some categories of software/communities and not for all. Dan Bernstein, the author of Qmail maintains total control over the direction of the project, Napster was Shawn Fanning mainly, and I could go on and these were projects that were so useful that the community ignored the idiosyncrasies of the owner. PHP is now mainly community driven, and became so around 1997; Rasmus' code in PHP is less than ten percent now.

He took apart a small PHP app with the help of Valgrind and showed how profiling an application can be counter intuitive. It was extremely interesting to hear this portion of the talk and I was unaware that valgrind could be put to such use; http_load was used to load test the site. He also mentioned the XML support in PHP5 including Simple XML, Yahoo'd geocoding api, and cautioned against using participation gimmicks like paid blogging. Solve one problem, a clean and intuitive UI were other tips from Ramus. Surprisingly he said that he finds programming to be boring and tedious, and his main interest is in solving problems. Slides here.

Christophe Hellwig, a linux kernel hacker tried to motivate contributions to the linux kernel. Among other things I learnt that one doesn't have to sign over copyrights when submitting code to the Linxu kernel. In contrast contributions to FSF projects need to sign over copyrights to the FSF and do some paper work as well. Christophe said that for result-oriented people there are lots of interesting problems to solve. Lots of modules need help. He explained how corporate contributors to the Kernel were often at conflict with the kernel developers due to pressures from the boss. There was a Sardarji in the audience who asked how many years it generally took to become a kernel developer - the audience laughed for no apparent reason ;-)

Andrew Cowie made an energetic presentation about the structural problems facing open source projects. He outlined at length the problems with centralized version control, build systems, bug tracking systems, and how they all combined to make collaboration between projects difficult. He made the very interesting observation about the committer/non-committer divide created by centralized version control systems. I wonder if DVCSs really solve the problem - you could have your own repository, but what if your changes are never merged into the main repository - C'mon stop pretending that there will be no 'main' repository with distributed version control systems. Besides the problem is how do you discover these repositories - DVCSs do not address the question of discovery at all.

The penultimate day of the conference saw a panel discussion by Sudhar 'Thaths' Chandrashekar; the panelists included Atul Chitnis, Kishore Bhargava, Karunkar Guntapalli, Arun Sharma, Frederick Noronha, KDE developer Sirtaj Singh Kang,and another bloke whose name I didn't get. Atul Chitnis who incidentally does not have too much by way of actual contribution to FOSS projects was predictably the most vocal about young people these days, yada, yada and the death of curiosity. He even made some vague connection between the ability to take apart devices and the ability to hack. In fact there is no such connection. Check out Karl Fogel's excellent article . Only in India do such vague assertions fly without fear of contradiction - it is no better than corporate software environments where the 'get things done' types and 'Excel gymnasts' are regarded as being more useful than good programmers. One recent college graduate finally got fed up with 'oh-young-people-these-days' rants and explained some interesting work they had done at college, that helped reduced the cost of the implementation. He explained that they customised the software extensively and the proprietary choice was very expensive. He also felt that Rs.500/- was a little high for college students. Instead of patiently explaining to a newbie, Atul lit on to this poor chap. One of the panelists was very honest and admitted that he had failed in his MCA exams, unlike lots of pretentious desi FOSS folks who are still enamoured of pedigree. The questions were all predictable, but the answers were better even though the pessimistic tone was a tad too much for me. I can't figure out how Atul arrived at the conclusion that things were going downhill - In fact there have never been so many Indian contributors as now. Atul and co seem to think that being well informed and following every single mailing list out there, and latching on to every passing tech fad is what contribution is all about. Well Atul, with my limited experience in open source projects I can tell you that working on nontrivial patches is real work - the kind of work that requires you to put down your head and do real hard work. Next time you feel like making a claim like this, please do some honest research and go through the commit mailing lists and actual dev lists. I know that you are playing to the gallery and pretending to be the sole saviour of open source in India. Just as life is what happens when you are planning, real open source contribution is what happens when non-programmers who are over the hill are talking about the glorious days of tinkering with modems. Honestly I don't know what the OSS contributions of the panelists other than Sirtaj, and Karunakar are.

It was funny that while one the very visible participants who is a Google employee did not miss an opportunity to let everyone know that he was working with the world's largest organized cult, I heard from another participant at the conference that a very respected open source contributor and O'Reilly author had resigned from Google after spending just three months there. A few days back news of another very respected oss contributor quitting Google trickled in. I know this guy and he is not the one to go around advertising his coolie status even if he works for google. Integrity and self respect count for more than grovelling before the benevolent master.

I attended this event after six years. The first time I met RMS. Nat Friedman's behaviour during his presentation was extraordinarily juvenile - he used the F-word so many times during the presentation that I got irritated. I didn't get a good impression and the many twists and turns of the GNOME project since then have only confirmed the fact that it is run by a bunch of juvenile delinquents. The recent Novell-Microsoft fiasco only serves to confirm my initial impressions.


Best comment/observation of FOSS.in 2006
When a member of the audience, strangely enough a Novell employee, asked if it was not possible to enjoy the freedom without getting into license wars, someone from the back (either Luke Kanies or Andrew Cowie) shouted:

That's a fan club - not an open source software project.

Indian Code contribution to FLOSS

There have been some discussions about why there is so little code contribution from Indian programmers to free software/open source projects following the recently concluded FOSS.in conference. Linux Weekly news has some interesting observations to make:

Even if only 10% of those attendees were truly active in kernel development, one would expect to see a significant amount of code from Bangalore working its way into the mainline kernel. And there are some Bangalore-based kernel hackers who are active on the mailing lists and who are contributing code. But their numbers are far smaller than one would expect after seeing how many people are interested and knowledgeable in this area. India is, as one developer put it, "the world's biggest consumer of free software," but it is not a huge contributor.

The usual suspect, the much maligned (and rightly so) educational system in India:

By several accounts, the problem starts with the university system. The Indian universities are strongly oriented toward the creation of employable graduates in large numbers; a number of FOSS.IN attendees described them as "assembly line" operations. There is a strong emphasis on passing tests and getting through the system on schedule, and, it seems, little interest in encouraging creativity and curiosity in the students. The universities were described as a conformist environment with little love of those who have their own ideas of how things should be done. The end result, as expressed to your editor, is that most students have had any love of hacking beaten out of them by the time they graduate.

The fact that the universities are, for the most part, hostile to Linux and free software does not help either.

The problems with the typical corporate developer in India are outlined:

Neeti's talk described Indian developers as needing to have their jobs laid out to them in great detail. They want to know where their boundaries are, and are uncomfortable if left to determine their own priorities and approaches. Your editor's initial reaction was that this claim sounded like classic talk from a pointy-haired boss who does not trust his employees to make decisions. Subsequent discussions backed up Neeti's claims, however. A few Indians told me that Indian employees require a high degree of supervision; perhaps that is why the pizza stand at the site required two-levels of necktie-wearing bosses who apparently did little to actually get pizza into the hands of conference attendees. It is not that Indians lack the intelligence to function without a boss breathing down their neck - that is clearly not the case - but all of their training tells them to work in that way.

So if one were to construct a stereotypical picture of an Indian software developer, it would depict a person who sees programming very much as a job, and not as an activity which can be interesting or rewarding in its own right. This developer is most interested in getting - and keeping - a stable job in a country where an engineering career can be a ticket to a relatively comfortable middle-class existence. Keeping that job requires keeping management - and coworkers - happy, and not rocking the boat.

There is also speculation about potential problems caused to a corporate developer due to participation in an open source project:

For such a developer, the free software community is not a particularly attractive or welcoming place. A developer who contributes to a free software project may earn a strong reputation in the community, but that reputation is not appreciated by that developer's employer or co-workers, and is not helpful for his or her career. Criticism from the community - even routine criticism of a patch by people who appreciate the developer's contributions in general - can be hurtful to a career in a culture where open criticism is not the normal way of doing things. Developers who expect to have their job parameters laid out to them in detail may feel lost in a project where they are expected to find something useful to do, and push it forward themselves. And these developers, while being possibly quite skilled in what they do, often have no real passion for programming, and leave it all behind when they leave the office each day.

LWN's take on the issue is mostly correct. I am stunned at how close the article has come close to diagnosing the problem, and if all of it is from a one week visit to Bangalore to attend foss.in, it's the all the more impressive. But there is very little input from developers who have actually made headway in sending patches and becoming committers in FLOSS projects and that makes the article a little bit shallow, as also it's failure to consider socio-economic reasons. Regarding the latter, I think the best explanation comes from Thaths from mailing list thread:

Based on a sampling of my White geek friends, I would say they are predominantly children of white collar baby boomers. Many of them were exposed to computers their dads brought home from work at an early age. I think similar conditions exist in India today for the kids of today.

I came to the same conclusion a couple of years back and have noticed that most of the American hackers whom I have read about, or have worked with, have had very early exposure to computers and programming and their comfort level is consequently very high. I am starting to notice that a bit with the generation born in the 80's and 90's in India as well. They tinker around with hardware with relative ease, play more games, and seem to know their way around computers much better than their parents, who incidentally slogged it out to create this improved environment for them. However I think even the socio-economic reason is only partial, and no one really knows. There is a real need to put on a web page the Indian code contributions and collect the experiences of Indian hackers.

Marc Canter on Chandler

Marc Canter says about Chandler:

Three years later and at least $5M Chandler hits version .6. Man oh man what we could do with that sort of money!

The Best Program according to Don Knuth

The Nerd TV interview with Andy Hertzfeld contains another interesting bit. According to Don Knuth, MacPaint was possibly the best program ever written:

I have another anecdote that has to do with Open Source and the Macintosh. In January, 2004, the Computer History Museum had a little presentation about the marketing of the Macintosh with all the original Macintosh marketing team up on the stage. And a large percentage of the rest of the Mac team in the audience. They had a Q&A toward the end and an older guy got up and said he thought MacPaint was probably the best program ever written. Was it possible for him to see the source code? It turns out the person asking the question was Don Knuth - another one of my heroes. He came up to me afterwards.