Hacker News Reader

Comment by JackMorgan | Hacker News Reader

Here's the thing, there's no way to measure programming productivity at all, so, no, there's no valid studies about anything ever. The studies that try always suffer from this inherent flaw. They count bugs, lines of code, function points, all metrics that aren't actual business value.

Pair programming vs code review, Nodejs vs Ruby, React vs Vue, Vim vs Atom, etc etc etc are all 100% emotional and subjective decisions. Therefore they are subject to fashion, being cool, and herd mentality.

Accepting this is an essential step on the path to become a well-rounded engineer.

View on HN

That's not really true. A better formulation is that there's no way to manage programming productivity cheaply and/or non-intrusively.

I agree that the bulk of X vs Y comparisons are emotive and subject to what Alan Kay calls the "pop culture" but that in no way demonstrates that measurement is out of reach. It's just in most contexts we don't care to do the work to measure it out of personal preference or economic reality.

Good point, productivity measurement is probably possible, but so vastly expensive enough that it's not happened yet.

I really like this post and the one about managers programming btw. Your common sense explanation to why most new managers end up coming back and reporting that they shouldn't code is exactly what I've seen as well.

There was an old Tom DeMarco article I'm a fan of: http://www.systemsguild.com/pdfs/DeMarcoNov2011.pdf

In it he has a pretty interesting insight about late projects. "If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster."

I imagine as our field matures measuring productivity and hitting estimates will get more important once software has finished eating the world. The unlimited (or close to) upside dev projects will be largely behind us and we'll need to hit tighter economic targets. I'm just glad I'm working in the era where I don't need to measure it :D

Glad you like the posts. Thank you!

I think that DeMarco is wrong about that already in the corporate world. The budgets and schedules that I work with are organised around knowing what is going to arrive when, crudely 10x -> 5x means that 5x is not available for the next round of projects, which means that 5 projects get canned. Any project running 2x will result in a big change of "staff responsibility" basically because no one trusts anyone involved any more.

You are the first person I've talked to who also thinks the "eating the world" will come to a natural end! I think the natural conclusion is that in X years there will be only a fraction of the number of working programmers as today. The margins will get tighter, and the gains smaller.

It is sad in a way, but also exciting as you say to be in the golden age.

Mind you, the maintenance burden and the dependency of the users on the legacy will be ever larger. Also - as things are digitized the opportunity for more and more digitization grows.

Reply on news.ycombinator.com