Comment by Jach

I agree the slogan isn't very true. It's similar to another line of commentary that would suggest soft skills are more important than the hard skills of actually being able to program, i.e. the primary service being paid for.

There is some truth to it, like Brooks' Law (https://en.wikipedia.org/wiki/Brooks's_law) about how adding people to an already late project will just make it later. There are many factors in how long a software engineering task takes beyond pure typing speed, which suggests there are factors beyond code produced per day as well. But some typing has to be done, and some code has to be produced, and those can absolutely be bottlenecks.

Another way of looking at it that I like is Hickey's hierarchy of the problems of programming and their relative costs, from slide 22: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... If you have inherent domain complexity, or a misconception on how to apply programming to a domain, those are 10x worse costs than any day-to-day practice of programming concerns ("the code"), and there's a 10x further reduction for trivialisms like typos.

I think some of it must be cope since so many are in organizations where the more they get promoted the less they program, trending towards (and sometimes reaching) 0. In such an organization sure, code isn't the bottleneck per se, it's a symptom of an underlying cause. The bottleneck would be the bad incentives that get people to schedule incessant unnecessary meetings with as many people as they can to show leadership of stakeholders for promotion doc material, and other questionable things shoved on the best engineers that take them away from engineering. Remove those, and suddenly productivity can go way up, and code produced will go up as well.

I've also always been amused by estimates of what constitutes "good" productivity if you try to quantify it in lines of code. There's a paper from 1994 by Jim Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality, and Productivity". It's summarized in the free book by Richard Gabriel, "Patterns of Software". (https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf pg 135) They were making new spreadsheet software for Windows, and had a group of "very high caliber" professionals, with a core group of 4 people (2 with important prior domain expertise) and then 4 more team members added after a year. "The QPW group, consisting of about eight people, took 31 months to produce a commercial product containing 1 million lines of code. This elapsed time includes the prototypes, but the line count does not. That is, each member of this group produced 1,000 lines of final code per week."

Later on, Coplien was asked "what he thought was a good average for US software productivity", and the answer was "1000 to 2000 non-commentary source lines per programmer per year". Also: "this number was constant for a large in-house program over its 15-year lifetime -- so that original development and maintenance moved at the same pace: slowly". An average of 1k lines a year is 19 lines a week, or about 4 lines a day for a work-week. This was considered acceptable for an average, whereas for an exceptional team you could get 200 a day. Might not there be ways to boost the average from 4 to something like 12 or 20? If your organization is at 4, there is clearly a bottleneck. (For extra context, the QPW group was in C++, and Gabriel notes he had personal experience with several groups demonstrating similar productivity levels. "I watched Lisp programmers produce 1000 lines of Lisp/CLOS code per month per person, which is roughly equivalent to 350 to 1000 lines of C++ code per week." Of course language matters in lines of code comparisons.)