This is an interesting discussion. I agree that the current system of filenames is a somewhat broken experience for most users. I think MP3 music files are a good example of possible future directions. Most MP3 players these days don't even show filenames. They present files in a way that is intuitive to users and with multiple views: album lists, artist lists, genre lists, custom play lists, etc. Ideally the OS should organize files by file type with multiple sorts available based on metadata common for that file type, like MP3 players do. Generally the problem with photos is the lack of location data and event data (Jimmy's birthday). GPS in cameras will help fix the first problem. The second can probably be figured out by the date. Most of the photo organizing programs can show you a view of your photos by date, which I think works pretty well for most people. What we need the OS to do is to organize our files like the MP3 and photo organizing programs do. Windows Explorer sort of does this, but only on the folder level. And Windows tries to organize files by type with predefined folders like MyDocuments and MyPictures, but these are only superficial. I should be able to easily see a complete list of all my Word documents on my computer (along with excerpts) without a massive search of my hard drive. I think the other key ingredient is to distinguish user files from program files. When I want to see a list of my Word documents, I don't want to see every ReadMe.doc file on my computer. Same goes of image files, etc.

ZoiD: You ask an interesting and a somewhat controversial question. From what I recall from a couple of books I've read, the average lines of code per day is indeed somewhere around 10 lines. The number is surprisingly low, but probably accurate, especially for large projects. I was surprised too when I first read it. ZoiD wrote: Based on the above I believe that a project of a large enough size will turn out to be similar size if counted in number of lines of code whether it's done by good programmer(s) A or good programmer(s) B. As a result I think that average line count per day can be valid stat... as it is certainly possible that programmer A could finish this project in half the time that B would. This seems like a perfectly reasonable statement, but it is not accurate. As it turns out, given the exact same specs, two groups of programmers can produce programs of vastly different size. In one study, there was a 5 to 1 difference in the number of lines of code written for functionally equivalent programs. Lines of code is a way of measuring program size, and can only be done after the code is written. There is currently no accurate predictor for predicting the size of a program except to compare it with similar projects written by the same group. Lastly, even if you have a fair estimate of the project size in lines of code, and a reasonably accurate estimate of lines of code per day for each developer, and average that out over the project, there's a good chance you still won't end up with a realistic estimate because the time required to write a program is not a simple linear function. In other words, just because one programmer can write a 400 line program in 4 weeks, does not mean 4 programmers can finish the program in 1 week. There is an excellent book about this exact issue called, "The Mythical Man-Month" by Frederick Brooks. Steve McConnell also has several good books with lots of studies, facts, and background on software development planning, project estimates, etc. I highly recommend "Code Complete" and "Rapid Development".