I totally agree. The “lines of code” graph was put up not so much to highlight quality or features, but more as a crude measure of “rate of development”. It refers to my post last year highlighting that PaperCut is always under active development. A graph is a visual measure – just something to make the post pretty – but I suppose ultimately the best measure is the release history and list of new features!

I also agree with your statement on maintainability. For example, a few months ago we refacted our popup authentication code – arguably one of the most complex and security focused areas of our application. The change took almost a man week, and resulted in next to no functional improvements. The code line count in this area however dropped by half and more importantly it was easier to understand. The driver for the change was to fix a small bug, but we took the opportunity to refactor to minimize the possibility of accidentally adding new bugs in the future – that is an investment.

Pidgin is a good example of a software project which recognise this; they’re currently playing with the idea of bounties for contributions which reduce code size without reducing functionality. See http://developer.pidgin.im/wiki/IdeasForBounties for more.

37Signals have a nice section on the issue of over-coding in their book, which can be found at http://gettingreal.37signals.com/ch10_Less_Software.php