May 13, 2003

Hackers and Painters

Paul Graham's latest article is so intriguingly astute that all I can say is that you should alot an hour and read it -- Hackers and Painters.

Some interesting quotes:

If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don't win by making great products. Big companies win by sucking less than other big companies.

One theme of the paper is that hackers should identify themselves more with "makers" like painters, rather than with scientists or mathematicians.

... [I]dentifying with the makers will save us from another problem that afflicts the sciences: math envy. Everyone in the sciences secretly believes that mathematicians are smarter than they are. I think mathematicians also believe this. At any rate, the result is that scientists tend to make their work look as mathematical as possible. In a field like physics this probably doesn't do much harm, but the further you get from the natural sciences, the more of a problem it becomes.

He ends with:

When you meet someone now who is writing a compiler or hacking a Unix kernel, at least you know they're not just doing it to pick up chicks.

[Thank to the AccordianGuy for the pointer.]

Posted by Eli at 05:48 PM | Comments (1) | TrackBack

May 03, 2003

Cringely on Open Source and Refactoring

Robert X. Cringely has an article up on PBS' site discussing the different types of open source projects that exist today. He's pretty much on the money -- not all projects are created (or exist) equally. Some are big projects with big money behind them and are as slick as their commercial competitors. Others are projects of hobbyists. That is the main point of his article.

But then you can see him begin to speak about things that I'm guessing he's not as familiar with:

"Cleaning up code" is a terrible thing. Redesigning WORKING code into different WORKING code (also known as refactoring) is terrible. The reason is that once you touch WORKING code, it becomes NON-WORKING code, and the changes you make (once you get it working again) will never be known. It is basically a programmer's ego trip and nothing else. Cleaning up code, which generally does not occur in nature, is a prime example of amateur Open Source software.

He's right in a lot of respects, especially for huge existing projects that have a lot of code. Refactoring is dangerous. But refactoring code, when done properly, especially code that is backed by decent automated unit and functional test suites, gives significant advantages in the ability of the project to quickly add new features and fix new bugs. I'm not saying anything new here -- XP advocates have been expressing these claims for years.

Posted by Eli at 07:17 PM | Comments (0) | TrackBack