Um, I have a question (about programmer productivity)

Joe paints a three bedroom house in three days and gets paid $300.<p>Jim paints a 5 ft by 3 ft watercolor landscape in three days and sells it for $1,000.<p>They both get their job done in three days. One covers far more area with paint than the other. One gets paid more than the other. Both of their customers are happy with the result because they paid for it. Who is the most productive?<p>Is it even meaningful to ask that question?<p>Doesn't it depend upon WHAT it is that is produced? Doesn't the WHAT have to be the same in both cases to be able to say which is more or less?<p>Perhaps before we talk about being more or less productive we need to identify what it is that we are producing. We should make sure its real, meaningful, and relevant to our purpose and that we are all talking about the same thing. Then finally, we must measure something that can't be easily inflated or faked. Only then can we talk about more or less comparisons and be saying something other than words without real meaning.<p>As I see it we have two questions to answer:<p>What is it that we are actually producing when we write software?<p>How can we reliably measure it?<p>We don't have good answers for either. Actually, I don't think we even have moderately good bad answers.<p>Isn't it interesting that a large and increasing fraction of the world's economy is based upon something we don't really know what is and can't actually measure?

Programmers know when they've been more productive because they feel it. This is not the kind of measurement that is accessible to metrics and formal studies, but that doesn't mean it isn't real. It does mean that the measurer and the measured have to be the same person, or people working closely together.

Programmer productivity can be measured.<p>In Peopleware DeMarco and Lister explain the Gilb Measurability Principle by what they call Gilbs law: "Anything you need to quantify can be measured in some way that is superior to not measuring it at all."<p>That does not mean that it will be easy, cheap or perfect, only that it will be better than not measuring.<p>Tom Gilb: "Sometimes, it seems difficult to identify satisfactory scales of measure. Often, the only ones that can be found are indirect, imprecise, and have other problems associated with them. From my point of view, these problems can be tolerated. The specific scales of measure, and meters for measuring, can always be worked on, and improved over time. In all cases, an attempt at quantified specification is better than vague words."

My personal measure is that I'm most productive when I'm least aware of time passing. The longer the day felt, the less productive I was. This doesn't give me any insight into the relative productivity of the guy sitting next to me, but if we treat this as a personal quest for productivity rather than an institutional one, it suffices.<p>The trouble starts once we get the idea that our personal quirks are somehow universal.

You never will know just how productive you are or were, and you're best just accepting that. I learned from playing poker that when the quality of your work and your results (in the short term at least) have no provable correlation, it's easy to fool yourself into believing one way or another, but in the end you can only look back and guess in hindsight.<p>The nice thing about programming (or writing, or tons of other creative endeavors) is that feeling you are more productive will likely actually make you more productive. If you're frustrated because your tools are holding you back, that's going to spill over into your work and make you unproductive. If you feel like you're getting things done, you're more likely to get things done later. So you just use the ones you like best, and assume you'll be more productive because they're the ones you like best.<p>The only time when you're certainly not productive is when you're arguing on the internet.

Sometimes I think that success is all about luck, and so the most productive team is the one that manages to expose themselves to as much luck as possible. Perhaps that takes the form of number of crazy ideas thrown out per unit time.<p>Then again, other times I think that success is all about luck, and so the most productive team is the one that manages to avoid blowing it when they do happen to get lucky. Think of Digital Research, Yahoo, or Netscape. Maybe productivity here is measured in disasters avoided.<p>I know for sure that productivity isn't something as mundane as effort expended or lines of code written. Because really, the vast majority of features you implement won't matter to anyone.

Is it worth measuring the granular "how productive" or is it enough to measure the binary "productive or not"?<p>I'd argue that the biggest battle is preventing people from being unproductive. Measure how often people have a productive state of "true", but don't measure them against each other.

Here's how I track my own productivity: I take notes. I'm using Freemind these days. I have my code at the top of the screen and a mindmap at the bottom. One of the nodes in that mindmap is a "ToDo" node that contains various tasks. As I work on a task - whenever I ask myself a question, or hit an error, or whatever, (usually around every 1-5 minutes) I'll make a note in the mindmap. I have another node called "Done" where I keep a log. Whenever I complete a big task, I move the node and all it's children from the ToDo node to the Done node. The child nodes in the Done node are organized by date.<p>How you do it isn't the important thing. The important thing is that you can look back later and review your work.

Part of the problem is that people talk about productivity in the abstract, which is like measuring your height with an invisible ruler and saying "I've gotten taller." Once you define a metric, it's easy to measure yourself against it. Lines of code? Easy to measure. Weeks taken to ship something? Easy to measure. Number of features completed on your checklist? Easy, if you made a checklist.<p>None of these metrics are perfect, but they're a heck of a lot better than nothing, or "I don't know". You can iterate, and refine the estimates as you go along. Just make a conscious effort to measure <i>something</i>. Getting actual data trumps all these endless arguments.

Comparing productivity between two methods or environments is easy. You have a programmer read and judge the quantity and quality of code produced one way, then read and judge the code produced the other way, and decide which you'd rather have.<p>Want a number, rather than a subjective judgement? Too bad. Want a manager to make the determination, rather than a programmer? Too bad. Want to compare two coders without showing both their code to the same judge? Too bad. Experienced programmers know what works for them, but don't expect any good studies.

Terrible title but a great question. The obvious metrics are lines of codes or tasks completed. At our startup we have a Trac setup and make lots of little tickets and check them off. Maybe 2 or 3 major tickets get completed per week per developer. More than that and you are making the tasks too granular and are wasting time doing admin overhead, less than that and they aren't specific enough a la GTD.

Scanning this thread, everyone is looking at this question on a personal, introspective level. If you really want to know if you are productive, look outside yourself. Ask your employer. Or your colleagues.<p>Pointy-haired bosses notwithstanding, your employer has a stake in your productivity, and in my experience, they typically have a pretty good idea of who is productive and who is not.

I personally use Pivotal Tracker's velocity feature. I write a one liner to describe a feature, and assign it a 1, 2, 4, or 8 point value, depending on estimated difficulty. Tracker will then graph points/time, which is productivity. This lets me keep track of myself over time, but points vary person to person.<p>It's hard to get an exact measurement of productivity, unless you have multiple people do the same sample problems. There is no standard unit of programmer production, because in the real world you should be solving an unsolved problem every time (or using a library).

I measure my productivity in a way akin to the ratio of time spent adding features added + fixing other people's bugs over the time fixing bugs I create and rewriting my own code.<p>Granted I am an "engineer" in a small company, not just a programmer, which I guess means I do things like write requirements, evaluate new platforms etc. IE lots of things not directly tied to implementing new features or improving existing ones. Not sure how that factors in.

I would say when one writes less buggy code in a short time he is in the ZONE and that would depend on the problem domain, technology and programmer's passion towards it.