What... what are those "development effort estimates"? They seem to assume an average rate of approximately 11 lines of code written per day which seems a bit too low if you ask me.

Besides, once a C compiler is written for one platform, porting it to another one takes significantly less time than writing from scratch (especially if the compiler is written with portability in mind).

> They seem to assume an average rate of approximately 11 lines of code written per day which seems a bit too low if you ask me.

I didn't calculate it but if you're just dividing one number by the other then you're assuming the final code arrived fully-formed in one go - don't forget about refactoring, debugging, testing, etc. etc.

Yes, 11 lines of debugged, delivered source lines of code written per day is within the normal range. The basic COCOMO model used by David A. Wheeler's "SLOCCount" estimates person-months as 2.4 * (KSLOC**1.05), which was calibrated with painfully-won experience on a variety of software projects in the 80s. If you approximate that as 2.4 months per kSLOC, it works out to 13.7 lines of code per calendar day, or 18.5 lines of code per workday. Other studies found lower speeds. Like 10: https://softwareengineering.stackexchange.com/questions/4506...

Every programmer thinks this is stupid the first time they see it, because we can all remember times we wrote 50 or 100 or 200 or 300 lines of code in a day, and that code worked. But other days we write zero lines of code, because we spend them in meetings, or debugging code, or arguing about the protocol design, or testing hardware we need to support, or testing our code. And sometimes we'll spend a week refactoring the codebase to reduce the number of lines of code (https://www.folklore.org/Negative_2000_Lines_Of_Code.html) so those 200 or 300 lines of code may not end up in the delivered product—if they were ever intended to, since test stubs and test scripts also don't count as delivered code.

And that's how we get to Peter Naur's "Programming as Theory Building": https://ratfactor.com/papers/naur1 because writing the code clearly isn't the bottleneck. It's figuring out how things have to work that bottlenecks us. It's more like proving a theorem than writing a novel. The code is a product of the process, but it's more like the exhaust of an engine than its power output.

And that's why the exponent of kSLOC is 1.05 instead of 1: bigger systems are harder to add to.

We had a discussion of this here 17 years ago https://news.ycombinator.com/item?id=333650 and maybe see also Forth authority Phil Koopman's take at https://betterembsw.blogspot.com/2010/05/only-10-lines-of-co... and Brian's take at https://blog.ndepend.com/mythical-man-month-10-lines-per-dev....

> Besides, once a C compiler is written for one platform, porting it to another one takes significantly less time than writing from scratch (especially if the compiler is written with portability in mind).

Why would you think that's different for any other language, like oh for example Forth?