It is generally a bad idea to call your boss an idiot, so my suggestions start with understanding and discussing metrics, rather than rejecting them.
Some people who are not actually considered idiots have used metrics that were based on lines of code. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan, and Steve McConnell all used them. You have probably used them even if just to say to a colleague, this God module is 4000 lines, it needs to be broken into smaller classes.
There is specific data related to this question from a source that many of us respect.
http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html
http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html
http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22
I suspect that the best use of line of code per programmer hour is to show that over the life of the project, this value will start pretty high, but as defects are found and fixed, new lines of code will be added to solve problems that were not part of the original estimates, and lines of code removed to eliminate duplication and improve efficiency will show that LOC/hr indicates things other than productivity.
- When code is written fast, sloppy, bloated, and without any attempt at refactoring, the apparent efficiency will be at its highest. The moral here will be that you must be careful for what you measure.
- For a particular developer, if they are adding or touching a high quantity of code this week, next week there may be a technical debt to pay in terms of code review, test, debug, and rework.
- Some developers will work at a more consistent rate of output than others. It may be found that they spend the most time on getting good user stories, turn around very quickly and make corresponding unit tests, and then turn around and quickly make code that is focused on only the user stories. The take away here is that methodical developers will probably have quick turn around, will write compact code, and have low rework because they understand the problem and the solution very well before they start to code. It seems reasonable that they will code less because they code only after they think it through, instead of before and after.
- When code is evaluated for its defect density, it will be found to be less than uniform. Some code will account for most of the trouble and defects. It will be a candidate for rewriting. When that happens, it will become the most expensive code because by virtue of it high degree of rework. It will have the highest gross lines of code counts (added, deleted, modified, as might be reported from a tool like CVS or SVN), but the lowest net lines of code per hour invested. This may end up being a combination of the code either implementing the most complex problem or the most complicated solution.
Regardless how the debate over programmer productivity in lines of code turns out you will find that you need more man power than you can afford and the system will never be completed in time. You real tools are not metrics. They are use of superior methodology, the best developers you can hire or train, and the control of scope and risk (probably with Agile methods).