Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Per the article, what managers often actually want to know is "How do I detect when a developer is so unproductive that they should not be retained?".

What are some behaviors that developers have when they've "checked out"? Not showing up to work or logging in is an obvious example. Lines of code might be a poor metric, but maybe the bottom 1% of coders in that metric is a sufficient detection for poor performance?

...at least as a detection mechanism to highlight for further investigation?

But if the case is that the developer needs to be "managed out," you need to build the case as a manager. This is where those metrics help.

For a manager there is no universal metric other than the hard work of understanding what your employees are actually doing.

The story goes, a Turkish company sells a software to a British client for a few hundreds thousands GBP and has to go though the bureaucracy for the accounting purposes.

Turns out, the clerk in the customs doesn't understand how software works and says he cannot certify the export of a few hundred grands worth of goods delivered by press of a button(the delivery was done through 28kbps modem connection). They bring him a disk but this is not good enough, there is no way this piece is worth that much he says and rejects the application.

They end up putting the software on a tape and declare that they've sold 2000 meters of fine Turkish software to the Brits. The clerk likes that, so the first software export from Turkey ends up being measured in Meters!

[0] The sources are in Turkish but the guy who was involved in this is Ali Akurgal.

Also the same story highlights the roots of the term "Tape Out".

Since the designs of ICs were stored in the tapes at the time, you write the final design to a tape and send it out to fab, hence you Tape out the design.

Cheers!

Turns out if you base the pay on that ... why create a function and call it repeatedly when you can just copy and paste the same code block over and over again

https://en.m.wikipedia.org/wiki/Campbell%27s_law

If you know a thing or two about evolution, it should be obvious how these shortcuts will play out.

And still, you hear about similar metrics being used all the time... All over the place.

I suspect, in most cases, it's actually bad metrics stacked and really the manager trying to putting a metric on their own "contribution". (Parasitic isn't even the word, but rather viral or prionic...)

In the end, truly and reproducibly recognizing individual contribution is probably beyond human comprehension for any non-trivial tasks. Maybe your product actually benefits a lot from that one guy, who is just very good at promoting a good spirit, being fun to work with, rather than being the most proliferative coder. And how do you measure how hard a problem is? Does is matter who perceives it as hard in your team?

I think, it's one of those things, where trying to be clever will most likely make things much worse because the manual labor and personal involvement of the past actually was already best fitted for the task, by utilizing the human brain where it excels. Humans doing human things with humans, without being willfully ignorant about the complexity at hand.

1. There is no objective measure of productivity that can be applied to software development.

2. Accurate estimation of development times is impossible (not difficult, actually theoretically impossible). All estimates of development times are wrong, some by more than an order of magnitude.

The second one is especially hard to grok for non-techies. I have to explain that if you insist on accurate estimates, you will get grossly padded estimates [0]. And the work will expand to fit the time available (sometimes resulting in the task exceeding even the massively padded estimates because the work expanded with the estimate). I've had many entertaining conversations attempting to explain this.

[0] Because every developer knows that an estimate will magically become a deadline.

Personally now-a-days I care more about velocity. If the team can deliver the smallest value added to the system within a week, we are good. The more constant velocity the team has, the more Management trusts you to produce value and get their things done without the need to have massive estimation parties that almost always end up being wrong.

The sad thing is, once the velocity gets bogged up or waving (Org change, contantly changing directions,..) the estimation parties are here to stay and it's quite hard to get back to where the team was.

Some are useful. The goal isn’t to be right in that there’s no award for perfect estimates, that would be stupid. But having an estimate, especially with relevance to multiple features is helpful.

At one time a team I worked on used “story point cards” and each person would estimate blindly and the discuss. It was interesting hearing people’s reasons behind their magnitudes.

Over time the story estimates got pretty good. But the number was completely useless objectively and made no sense when comparing teams or different projects.

The real pain is turning estimates into deadlines. "About this big" doesn't equate to "it'll be finished on Thursday".

“This story is 4D6, that one about a D20”

Sounds like Hofstadter's law.

"Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law."

[1]: https://en.wikipedia.org/wiki/Hofstadter%27s_law

If you give a bug to a software developer to fix, the good software developer will probably rewrite some code and in the end the LOC count will be the same or less. The bad/lazy software developer will glue some fix on top of the bug and add additional LOCs.

The problem is that this is a theoretical scenario which rarely comes up in reality. The developers operating at the skill and maturity level where tracking their individual productivity and quality can be done well, generally are not the developers who really need these types of measures, and they usually aren't left grinding on the same domain for the years required to have enough data to do anything useful with it.

It is kind of a catch 22. The situations where tracking and gaining insight from KLOCs would help (mature/skilled devs working on the same thing over and over for years...doesn't happen much), are not the situations where it is most needed (projects with hundreds of relatively inexperienced/immature developers and managers)

The result is it is applied to disastrous effect in situations where immature managers glom onto it as a silver bullet for managing the unmanageable.

I’d rather have an employee that spent three days, optimizing a single 100 LoC method, than one that churned out 2,000 LoC that does the same thing, in two days, that will need to be maintained, forevermore.

I sometimes have to go back, and put code back in, to make it maintainable (often, by Yours Truly).

There are many scientists who have very high standards for proof and evidence in their professional life, but accept other theories as truth without a shred of evidence in their personal lives.

I don't know much about Jobs, that's why I asked. From what I got, he was rather a charismatic leader with a good intuition, but I wouldn't call those attributes intelligence per se. Is there any evidence for a particular intelligence of his?

He is just not old enough for working in a time this was new.