Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cannot Measure Productivity

martinfowler.com

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Cannot Measure Productivity

#31

Post by epenn »

swombat wrote: post #29
foobarbazqux wrote: post #25

Earlier quoted context omitted.

> you are not a scientist unless other scientists agree you are Science requires one thing: making and testing falsifiable hypotheses. A priest is able to determine whether or not you are doing that. If anything, it's philosophers who decide what science is, e.g. Karl Popper.

Doing science does not make you a scientist.

Can you elaborate on why you believe this to be the case? Saying that a scientist is one who does science seems like a truism bordering on being tautological. I'm curious why you disagree.

Re: Cannot Measure Productivity

#32

Post by hcarvalhoalves »

ChuckMcM wrote: post #3

It has been more than 10 years, it has been at least 50 since there were moans about productivity in the early 60's. Feynman had some interesting thoughts on minimal computation that sort of paralleled Shannon's information complexity. As you know Shannon was interested in absolute limits to the amount of information in a channel and Feynman was more about the amount of computation per joule of energy. But the essenc…

> It has been clear for years that you can produce inefficient code quickly, and conversely efficient code more slowly (...)

That's not only false, but is often the opposite.

The symptom number one of an inexperienced programmer is to waste development hours reinventing the (square) wheel, while a good programmer is lazy (already knows which solution works best, and will probably just import it from a tested library).

So an experienced programmer not only doesn't waste computation power, also doesn't waste hours on the development cycle.

I agree with everything else you pointed.

Re: Cannot Measure Productivity

#34

Post by zrail »

matwood wrote: post #17
Jormundir wrote: post #8

It drives me nuts when programmers brag about their productivity, measured by how many lines of code they've written. You end up with something like feature 1: +12,544 / -237 lines. Done in 2 weeks. Then comes feature 2, 2 and a half months later, the stats: +5,428 / -9,845. Look at that, you had to tear down everything they wrote because they cared about amount of code over code quality. The more they brag, the more…

Nothing makes me happier than removing code. If I can find ways to deliver the same functionality in less code I get excited. Now, I do like to look at my personal lines of code because it gives me a gauge to compare features I implement on a relative basis. It also gives me a relative, rough measure how much effort a particular feature took to produce.

I have a friend who styles himself as a "professional code deleter" and who loves to post his diffstats when they're very large negatives.

Re: Cannot Measure Productivity

#35

Post by RogerL »

chromatic wrote: post #10
RogerL wrote: post #4

A very wise man said "there is no silver bullet". Yet we keep trying all these schemes to automagically solve what are hard optimization problems only amenable to heuristics and deliberate, intelligent introspection. Very simply, you cannot run some tool to measure the information density of a large project. Graphical programming isn't going to turn a bunch of marketers into programmers. Doing user stories and forcin…

Please excuse this small rant. If you're referring to Fred Brooks, he wrote "[T]here is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity." (emphasis mine) The surrounding context makes his comment a very specific prediction which means something different from what most p…

I'm confused. I was pointing out that you cannot do something simple like count LOCs, run a CASE tool that spits out cyclomatic complexity, or other things, and instantly measure productivity. How is that not what Brooks was saying? You don't bean count your way to better software, you manage the inherent complexity. Daily, hard work, understanding all of the parts, and so on.

Re: Cannot Measure Productivity

#36

Post by stonemetal »

So two teams build identical databases in identical time frames. One becomes popular and has sells in millions of dollars. The other flops, with sells in the hundreds of dollars. Sure there is a difference in business results but I fail to see how the two teams were not equally productive at creating software. Sure I don't have a good definition of software development productivity but this is open to so many non software development productivity elements as to be nonsensical.

Basically I see this as marketing. We may not be the fastest but who cares about that we have the special insight to build the hits that keep you in business.

Re: Cannot Measure Productivity

#37

Post by nadam »

You can quite well measure productivity if you set a task, write tests for it, and tell two independent groups to implement it. You give them the same amount of time.

Now the more productive / better group is which can do the task with smaller complexity.

Complexity measures measure size of code and number of dependencies between blocks in different ways. But even the most simple comlexity measure is quite good: just measure number of tokens in source code. (It is a bitmore sophisticated than LOC). You can then make competitons between groups, and measure their productivity. (I am writing a book now titled 'Structure of Software' which discusses what is good software structure on a very generic/abstract level. It relates to 'Design Patterns' as abstract algebra relates to algebra.)

Re: Cannot Measure Productivity

#38

Post by artumi-richard »

The book "Making Software: What Really Works, and Why We Believe It" (http://www.amazon.co.uk/Making-Software-Really-Works-Believe...) has a section on this.

Chapter 8 "Beyond lines of Code: Do we need more complexity metrics?" by Israel Herraiz and Ahmed E Hassan.

Their short answer is that, in the case they looked at, all the suggested metrics correlated with LOC, so you may as well use LOC as it's so easy to measure.

IIRC they believe it's only good to compare LOC between different employees if they are doing pretty much the exact same task however, but since LOC is correlated with code complexity, there is some measure there.

I recommend the book, as really focusing on the science of computer science.

Re: Cannot Measure Productivity

#39

Post by alok-g »

nadam wrote: post #37

You can quite well measure productivity if you set a task, write tests for it, and tell two independent groups to implement it. You give them the same amount of time. Now the more productive / better group is which can do the task with smaller complexity . Complexity measures measure size of code and number of dependencies between blocks in different ways. But even the most simple comlexity measure is quite good: jus…

Genuinely asking: Why not just stop at "tell two independent groups to implement it"? That is, why constrain to the same amount of time?

Re: Cannot Measure Productivity

#40

Post by RogerL »

matwood wrote: post #17
Jormundir wrote: post #8

It drives me nuts when programmers brag about their productivity, measured by how many lines of code they've written. You end up with something like feature 1: +12,544 / -237 lines. Done in 2 weeks. Then comes feature 2, 2 and a half months later, the stats: +5,428 / -9,845. Look at that, you had to tear down everything they wrote because they cared about amount of code over code quality. The more they brag, the more…

Nothing makes me happier than removing code. If I can find ways to deliver the same functionality in less code I get excited. Now, I do like to look at my personal lines of code because it gives me a gauge to compare features I implement on a relative basis. It also gives me a relative, rough measure how much effort a particular feature took to produce.

You will like this story from Apple, when they for a time required engineers to report LOC produced that week.

http://folklore.org/StoryView.py?project=Macintosh&story=Neg...

Post reply on HN