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

71–77 of 77 posts

Re: Cannot Measure Productivity

#71

Post by lifeisstillgood »

benched wrote: post #56
seanmcdirmid wrote: post #52

Earlier quoted context omitted.

Scientists must pass peer review to publish, and peer review can be very harsh. Double blind helps winnow out political bias. Coders must get jobs to continue coding if they are not independently wealthy. Bias abounds in this case, as other coders with influence must vouch for you, and...in this case your projects can influence their opinion of you. We are social creatures: we don't live as hermits (most of us anyway…

It was still an inflammatory thing to say, given that there's nothing stopping a person who does live as a hermit from learning to write working code. In the days before the Web, I created two good-sized adventure games without ever having interacted with another programmer (save maybe 2 book authors). Nobody vetted me. I just made and released them. The lone wolf programmer has always been a thing.

I think there is a confusion between trying to define the line between scientist / non-scientist or coder / Non-coder (Which is difficult to the point of impossible) and the ability for someone who is already a scientist to look at the work of another and decide if it is the work of a scientist

This is why I use the term software literacy. My son is learning to read. He can write is own name and letters, read some words phonetically. All of those things are necessary but not sufficient. But he is not (yet :-) literate. Will it be at ten words ? A hundred? A thousand? Those are silly arbitrary cut offs.

Anyone of us here can tell the difference between literate and illiterate because we have passed through that gateway.

The same goes for scientist or programmer.

But actually trying to write down the exact definition, the point one passes from being able to write a line of executable code and becomes a real programmer? Becomes software literate? Can't do it. Which is also why you can't measure productivity (plus all the reasons Robert Austin has)

Re: Cannot Measure Productivity

#72

Post by wciu »

Most performance indicators are imprecise. P/E ratio is one of the stupidest measure of value, but it is widely use in finance. No one(at least no value investor) would invest based on P/E ratio alone though, there is a lot more due diligence that's done before investors put their money into a stock. (At least that's what you hope happens.)

The problem with productivity measures, is not how they are measured but what they are used for. Most managers want to use productivity measures to evaluate individual or team performance, however, performance is tied to incentives, so you always end up with a lot of push back from the team or someone gaming the system. (IMO, this is because of lazy managers wanting to "manage by numbers", without really understanding how to manage by numbers.)

Rather than using it as a performance management tool, productivity measures, however imprecise, can be used alongside other yardsticks as signals of potential issues. For example, if productivity measure is dropping with a particular module/subsystem, and defect rate is increasing, then one might want to find out if the code needs to be rearchitected or refactored. In these cases, it is okay to be imprecise, because the data are pointers not the end goal. When used correctly, even imprecise data can be very useful.

Re: Cannot Measure Productivity

#73

Post by foobarbazqux »

luism wrote: post #70
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.

Ludwig Boltzmann was a very important scientist (or perhaps I should say that his scientific contributions were significant). However, if I recall correctly, his peers didn't agree with his theories and, I would assume, they wouldn't have called his theories scientific -seeing how they basically assumed atoms in a time when that was controversial. So, I too consider that agreement from others isn't a prerequisite for…

Oh, I think it's okay if the hypotheses are falsifiable in the future, as long as the models are not presented as experimentally verified.

Re: Cannot Measure Productivity

#74

Post by abc_lisper »

__--__ wrote: post #49
lifeisstillgood wrote: post #5

I am going to get my drum out and bang on it again. Software is a form of literacy - and we measure literacy completely differently. In fact we measure it like we measure science - you are not a scientist unless other scientists agree you are, and you are not a coder unless other coders say you are. What Fowler wants to measure is not the top echelons of productivity but the lower bounds - presumably to winnow out th…

you are not a coder unless other coders say you are Not everybody needs the approval of an external entity. I couldn't care less what other coders think of me. What I ship speaks for itself. What I write speaks for itself. What studies scientists publish speak for themselves. The rest is politics.

> The rest is politics.

Really. No reality check? Spinning a wheel doesn't cause anything in particular, unless it meets the road.

Now I am not saying what you are saying is totally false. The truth is more nuanced, or say, more qualified.

The qualification comes from achieving something in the real world. If you can achieve something by talking to someone instead of writing code to work around it, both are equally valid.

I think of it like this. A pure function does not do any real work. The real work comes from the side effect it causes, the global variable it sets, the file it writes to, the program it talks to on the other end.

So yeah. You can cocoon yourself saying lalalalala, but you don't want to be the thread that spawned, did something to its local variables and exited. Whats the point of such a life anyways?

Re: Cannot Measure Productivity

#75

Post by dredmorbius »

Software productivity management (as an end in itself) fails to account for another fundamental axiom: that software itself isn't the end-product, but itself is a tool or defines a process by which some task is accomplished.

Count lines of code, function points, bugfixes, commits, or any other metric, and you're capturing a part of the process, but you're also creating a strong incentive to game the metric (a well-known characteristic of assessment systems), and you're still missing the key point.

Jacob Nielsen slashed through the Gordon's knot of usability testing a couple of decades back by focusing on a single, simple metric: does a change in design help users accomplish a task faster, and/or more accurately? You now have a metric which can be used independently of the usability domain (it can apply to mall signage or kitchen appliances as readily as desktop software, Web pages, or a tablet app).

Ultimately, software does something. It might sell stuff (measure sales), it might provide entertainment, though in most cases that boils down to selling stuff. It might help design something, or model a problem, or create art. In many cases you can still reduce this to "sell something", in which case, if you're a business, or part of one, you've probably got a metric you can use.

For systems which don't result in a sales transaction directly or indirectly, "usability" probably approaches the metric you want: does a change accomplish a task faster and/or with more accuracy? Does it achieve an objectively better or preferable (double-blind tested) result?

The problem is that there are relatively few changes which can be tested conclusively or independently. And there are what Dennis Meadows calls "easy" and "hard" problems.

Easy problems offer choices in which a change is monotonic across time. Given alternatives A and B, if choice A is better than B at time t, it will be better at time t+n, for any n. You can rapidly determine which of the two alternatives you should choose.

Hard problems provide options which aren't monotonic. A may give us the best long-term results, but if it compares unfavorably initially, this isn't apparent. In a hard problem, A compares unfavorably at some time t, but is better than B at some time t+n, and continues to be better for all larger values of t.

Most new business ventures are hard problems: you're going to be worse off for some period of time before the venture takes off ... assuming it does. Similarly, the choice over whether or not to go to college (and incur both debt and foregone income), to to learn a skill, to exercise and eat healthy.

It's a bit of a marshmallow experiment.

And of course, there's a risk element which should also be factored in: in hard problems, A might be the better choice only some of the time.

All of which does a real number in trying to assess productivity and employee ranking.

Time to re-read Zen and the Art of Motorcycle Maintenance.

Re: Cannot Measure Productivity

#76

Post by __--__ »

abc_lisper wrote: post #74
__--__ wrote: post #49

Earlier quoted context omitted.

you are not a coder unless other coders say you are Not everybody needs the approval of an external entity. I couldn't care less what other coders think of me. What I ship speaks for itself. What I write speaks for itself. What studies scientists publish speak for themselves. The rest is politics.

> The rest is politics. Really. No reality check? Spinning a wheel doesn't cause anything in particular, unless it meets the road. Now I am not saying what you are saying is totally false. The truth is more nuanced, or say, more qualified. The qualification comes from achieving something in the real world. If you can achieve something by talking to someone instead of writing code to work around it, both are equally v…

You need to stop putting words in my mouth.

The context of my statement is in regards to self identification vs community identification. I write code, I release apps and I get paid. Why do I need a community to call me a coder before I can be considered one? What other people think of me, what image I put forth, etc is all marketing and politics. The only real evidence of me as the coder is what I ship. Does it scale? Does it have bugs? Does it work? That's the reality check, not whether Steve from SuperFrog Backup Solutions saw my code on github and thinks I write an elegant monad.

If you can achieve something by talking to someone instead of writing code to work around it, both are equally valid.

Nothing I wrote disputes that.

So yeah. You can cocoon yourself saying lalalalala, but you don't want to be the thread that spawned, did something to its local variables and exited. Whats the point of such a life anyways?

Consider this: a man spends a lifetime writing novels. He thinks of himself as a writer, he identifies himself as a writer and he introduces himself as a writer. He never publishes, but he's always producing. One day, his house burns down, killing him and destroying everything he's ever written. Do you think his life was wasted? Do you think he thought his life was wasted?

Re: Cannot Measure Productivity

#77

Post by chromatic »

jacques_chester wrote: post #62
chromatic wrote: post #10

Earlier quoted context omitted.

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…

You missed a key point of the essay, which is that no matter how much progress we make in accidental complexity, essential complexity does not go away.

Of course that's the key point of the essay, but I've never observed that anyone who says "There's no silver bullet in productivity" has made it past the desire to misuse the title of a Fred Brooks essay to support a middlebrow dismissal to the nuance of distinguishing between accidental and essential complexity.

After all, much of programming culture is stuck on the idea that the clarity of syntax of a programming languages to novices is more important to maintainability of programs written in that language than domain knowledge, for example.

Post reply on HN