One aspect of TDD that isn't often quoted is that it helps get a concrete measure of productivity (and it's one of the themes of Beck's book). If you can see that today you've knocked out 100 tests, that's some measure of progress. It's a running theme through agile-processes. Small iterations / stories / code changes with measurable outcomes.
We can't quantify it or inspect it. We can't corroborate it. We can simply ask a programmer whether they are productive or not and trust them to answer for themselves.
And if Alice meets Bob on the street and they disagree over what makes them productive, there is really no way to settle the question. If Alice says she is more productive using Ruby than Python, but Bob says the opposite, we must trust that they are both right, and furthermore we can't really draw any conclusion.
Because Charles may report that he is more productive with Ruby, or Python, or perhaps Arc, and again he is the only one who knows.
But then again, maybe if we drill down deep enough, we'd find common themes or aspects for why Alice feels more productive with Ruby and Bob with Python.
Programming isn't a natural mode of thought, and programming languages aren't a natural mode of expression. I think it's unrealistic to expect that we'll ever find a universal best practice.
However, when we use the word "productivity" in every other aspect of business, we are describing the production of output. We don't measure how the output is produced, or the subjective feelings of the producers.
So what output are we discussing when we talk about productivity? Or are we using the word in a special way that has nothing to do with productiviy as it is used elsewhere?
As to the rest, I dunno. Let's consider the following scenario: every time you wrote something down on paper, there was a chance the paper would spontaneously burst into flame. There are strict, reproducible rules governing when the paper would and would not catch on fire. People go to school to learn these rules, which are varied and subtle.
In this world I've described, is the best writer a person who can write the most essays that don't spontaneously combust? I feel like as programmers we think that because we can easily quantify whether something works, we can also quantify whether it's good. Or worse, that everything which doesn't burn away is essentially the same: just words on paper.
It's simply not true. The fact that writing a program feels more practical than writing a novel doesn't change that.
The first programmer has spent a lot more time in doing it (like 5x the second programmer) and carefully verified each line to make sure the code and algorithm are correct both conceptually and in practice, and tested that the code won't fail in any of the imaginable corner cases.
The second programmer wrote it over the weekend, didn't test much else but merely cross-checked the code with a few working test cases similar to what the program will be used with for starters. He maybe followed his intuition to guide how to write or let his creative flow dictate the details of the program but he really hasn't had time to verify why.
There seems to be no clear notion of which programmer was more productive. It all depends on what perspective the project is viewed. On the other hand, I believe there's always some absolute value underneath and productivity isn't entirely an subjective property.
(Mandatory car analogy: If you want a Trabant and I sell you a Mercedes-Benz for the price of a Trabant and you still treat the car like a Trabant, the Mercedes is still better built regardless of how you extract value out of it.)
When the project was deployed, both programs worked correctly as they are similar. The cost per line/token of the first programmer is five times the cost of the second programmer. On the other hand, had the second programmer undergone the same rigorous verification it would have taken 2x the time of the first programmer.
Apparently the first programmer's code has a lot more value simply in being well-thought, and the programmer knows exactly why he has arrived in the solutions he wrote in the code. If the code broke the programmers would be on very different levels with regard to how to start debugging. On the other hand, the second programmer produced the same program in 1/5th of the time which may greatly please the management. However, the second programmer might easily become a grand failure in the next project as in this project he already reached the same solution if not by accident then at least by luck. Both programmers produced the same comments as they wrote it mainly for the future maintainers, as usual, instead of as a record of the whole mental process they experienced.
Imagine that productivity was as simple as bug-free function points per iteration. In this hypothetical case it's entirely possible that Alice is more productive in Ruby and Bob is more productive in Python, and we can measure the productivity.
However, the problem as given is that we don't even know that Alice produces more in Ruby or Bob in Python. All we have is their subjective assertions. That is the question I have: What are Alice and Bob talking about, and do we even know whether there is a correlation between their self-diagnosed productivity and anything useful we can measure like project success?
I don't think so. Consider Charles the Arc programmer and Debbie the PHP programmer. They work on identical Ruby projects for the same amount of time.
Charles reports that he was horribly unproductive using Ruby's brain-damaged implementation of half of Lisp. Debbie reports she was way more productive in Ruby than she ever was in PHP.
But in reality, Charles accomplished far more using his knowledge of Lisp, while Debbie spent most of her time learning how a truly dynamic language worked. Nevertheless, she felt "flow" and "freedom" while learning Ruby.
Can we trust their self-diagnosis? According to them, Debbie was more productive than Charles.
Really, the only way to measure programmer productivity is how fast they can implement a perfectly detailed spec. If you have some unknowns in there, your measurements will tell you nothing.
Therefore, I might suggest a test whereby two programmers are told to implement a program with a spec that is completely known, in the same language, and with the same set of libraries, in their perfered (or an independently chosen ) working environment. What this comes down to is just a race, and some people have good days, and some have bad days.
If you run this test several times with different specs, you might be able to objectively tell whom is better given those environmental characteristics. Of course, these measurements will be nearly useless in a real project environment for the reasons cited in the first paragraph.
And it's pretty hard to quantify any unknowns. Somebody said that programmers do know when they're productive. I know when I am and that's basically whenever I write anything at all that I _know_ will contribute to the functional or algorithmic completion. Merely that constitutes productivity!
That means I know that "if I keep doing this I will finish the program at some point". Writing boilerplate doesn't count. If I keep slamming getters, setters, and a like into my source file twelve hours a day it won't make the actual program ever ready. All I'm typing in are effectively prerequisites.
Boilerplate doesn't count even if it's mandatory in the language I'm using: I'm not sure if I could ever feel productive with Java eventhough I know I would really, really have to write a hundred setters/getters in order to finish. The logical step that would make me productive on my own scale would be to scoop power from a better language.
You're correct, as taking that to it's end conclusion would imply it's impossible to improve (which I'm sure most would disagree with).
Perhaps the question "How do you measure improvement?" is relevant. This might be a roundabout way to yield the former.
I like to think that most programmers enjoy being productive, and strive for increased productivity (rather than working just for a paycheck). I therefore also believe that programmers expend great effort over the course of their careers optimizing their work habits to maximize productivity.
All programmers are different, but none of us is completely different from all others. There is much to be gained from examining what the others have learned in the process of programming. The danger in this is thinking that there is some objective Truth in programming productivity.
So, Bob disagrees with Alice over what makes a programmer productive. Assuming both Bob and Alice are effective programmers, what we should really be examining are the ideas they have in common.
For me, reading programming blogs from around the Internet gives me a giant mental Venn diagram--the ideas in the center are what I focus on.
At the end (maybe of 12 months to allow for maintenance) you'll have a quantifiable result saying that Bob is more productive than alice.. (for that task - and probably tasks like it)
* I didn't say that it was easy or that we should spend that much time on a pissing match.
Controlled experiments with human judges seem like the best answer.
But you know it when you see it. (Even if somebody else might not agree.)
What are you gonna do? All the halfway interesting concepts in life work like that.
Who's really tried?
There's been a few research papers here and there, measuring the things that are easy to measure in a corporate environment.
But who has both the incentive and the skills to measure a very difficult to quantify subjective experience?
It is absolutely a very complex subjective experience, but it ain't magic.
It IS very had to measure but it's not impossible just because no one's really tried yet.
That's not to say that programmers have no clue, just that our internal radar isn't exactly infallible. People tend to feel "productive" when they feel like they're "getting a lot done," but real productivity depends on whether you're doing the right things and whether you're doing them well.
And, let's face it, most programmers (myself included) really enjoy that feeling of just cranking on something and becoming so engrossed that they don't notice time pass. So I think that people are biased towards thinking that always corresponds with maximum productivity simply because it's enjoyable, and not because it's truly always optimal.
So true.
http://www.geekherocomic.com/2009/01/19/efficiency-and-compr...
> That's not to say that programmers have no clue, just that our internal radar isn't exactly infallible. People tend to feel "productive" when they feel like they're "getting a lot done," but real productivity depends on whether you're doing the right things and whether you're doing them well.
So, is it safe to say that if you 'feel productive', you're most likely not?