John, do you have a reference for this? Thanks!

FYI you did not invent agility. The cave man sharpening his stick knows as much about process refinement as your “agile” buds.

Same goes for “pivots” and “build measure learn” loops. Do you think you’re the first person to discover a dictionary? I dare you to build anything WITHOUT process refinement.

To all “agile” aristocrats: I would be more impressed if you told me you could function for 5 minutes without learning anything, without pivoting, without build-measure-learn looping.

In other words, non-agile development is impossible. That’s why it’s called “development.”

You can do amazingly a lot with amazingly few lines, while still having easy to understand, simple code, in a bigger more complex system where you can re-use your methods a lot of times, with a good hierarchy and design on the system.

Sometimes even inexperienced coders produce easy to maintain, easy to read code, but they don’t usually function straight away, despite them thinking so, an experienced coder gets the functionality right in the first place, therefore, less time to spent on bug hunting.

But we have to remember that coder has to have the insight to produce a nicely written, easy to read and understand code, structured well. Many, even exceptionally skilled otherwise, lack this fundamental understanding. Way too often i’m hearing the excuse of “it works, and there’s nothing wrong in using 4 function in single line, and if you don’t know what that very obscure, unknown function does RTFM”.

Writing as few lines as possible is the worst excuse ever for complicated code.

And yes, someone writing short, easy-to-understand lines of code will produce actually more lines aswell, the difference comes from bug squashing time -> simpler code, easier to identify problems.

So sometimes lines per day is an interesting measure of programmer productivity (contrary to Freds statement above). We were using Extreme Programming, so had other measures like Velocity which is much more customer focussed. Maybe this was a special case?

I strive for clarity and succinctness in my code, as well as clean structures and object models to better reflect the problems at hand. I’ve written everything from operating systems to drivers to applications, middleware, and web apps.

It’s not just the code, but the algorithms, patterns, and data structures. One less experienced may not be as comfortable with certain algorithmic approaches, and may choose a brute-force method instead of something more elegant and time-saving.

But counting lines of code would miss all of this. It’s a silly idea at best. Do comments count as lines of code? Sometimes my comments are longer than the code itself, because I will go into as much detail as I need, so if I walk away for 6 months I’ll know what I had in mind.

True Productivity cannot be measured easily or quickly. You must include the business model at some point. How much overall time was saved, how much money was saved or made, how much maintenance or downtime was involved, what was the load on Customer Service, etc. These all become factors in True Productivity, and you can chuck the number of lines out the window.