>We should all know by now that code is an input to the software development process and not an output: yet even the most forward-looking organisations still tactitly treat lines of code as a productivity metric

What exactly is this referring to? My thinking here is "code is a hypothesis", and you don't know if it's solid or not until it contacts the real world. (And ideally tests, and maybe a proof or two.) And what we're seeing lately is that the hypotheses often get disproven decades later (longstanding kernel bugs etc.)

Maybe because the actual work is done by the process, which may not even be the code itself, just its compiled form. In this code the code is both a communication tool (between humans) and the input that leads to the process. It's like a group of musicians collaborating on a music sheet. The final valuable form is a concert. The audience won't care about the music sheet.

The comments here gush about how they can write more code, but they don't say anything about the quality of the software being built and if they have improved on some points with it (cheaper maintenance, faster reaction to feedback, less bugs overall). Very much like a musician clamoring how he can write a lot more music sheets, but there's no concert in sight to listen to his music.