4 ms·

I will oversimplify my response. Let's imagine that I wrote some test cases. To me, If my piece of code passes those tests, I will consider it of being of X qu

I will oversimplify my response. Let's imagine that I wrote some test cases. To me, If my piece of code passes those tests, I will consider it of being of X quality. I won't care about any other quality than this X one. If I write/build/test two different pieces of code, both passing my tests, and happens that I took less time to write the second one of them, then I would consider I was more productive writing the latest.

hn_throwaway_99 9y ago
I think your example shows exactly why measuring software productivity is so problematic. With your scenario, probably the easiest way to "improve productivity" would be to not write any documentation comments, heck it would probably be faster to just stick it all in one giant method. I think many of us have known software developers who are incredibly fast, but who write "rat's nest" code that's impossible for anyone else to decipher, or which is very difficult to modify when new requirements come along. Quantifying those attributes is incredibly difficult, but as most time in software is actually spent on maintenance, it usually ends up being more important than a simpler assessment of initial output.
- vmateixeira 9y ago
  One can assume writing documentation and comments is covered by both approaches. Still, the fastest scenario would be the most productive one. I agree with your view regarding maintenance cost, but I don't think that's what's at stake here. We can go further and try to compare the amount of time needed to fix rat's nest with the amount of time needed to write the software all over again. Covering the rat's nest is in many occasions faster (on which I'm considering more productive) than rewriting.
  - hn_throwaway_99 9y ago
    You're never going to get around the fact that most of these things are qualitative assumptions. Is your documentation good? There's really no completely objective way to measure maintainability, because maintainability is often about how easy it is to handle unknown future change requests. Years ago "function points" were bandied about as a truly objective measure of software output and value. It turned out to be trivially game-able and added 0 value to software development estimation.
qwer 9y ago
I think you really did oversimplify it. Writing a piece of code once obviously affects your speed at writing it again.
- vmateixeira 9y ago
  As you clearly understood, that's not what I meant.
lomnakkus 9y ago
Ok, so now you "just" need to factor in long-term maintenance. Besides, how often do you write code twice just to see which way is better? What you have is a comparative measure that is completely useless for measuring new code, i.e. code which implements a new feature.
lloeki 9y ago
Where is your metric? By how much will you be declared more productive? Is it just time to achieve a result? Because that is obviously wrong. How are you accounting for quality, or even measuring that X? Do you account for readability? maintenance? documentation? factoring? over-engineering? There are so many visible as well as hidden factors that attempting to measure any (let alone all) of that is a pipe dream. Also, by writing the second one you are not accounting for second version effects since it is a reimplementation of something you know, and if someone else develops it for you then you just changed a major variable. I get that you said "oversimplified", but this is just like saying "thought experiment", yet as soon as you confront that to the real world, it just doesn't realistically fly.
- vmateixeira 9y ago
  > Why is time for achieving a result a wrong metric? We're paid per hour of work. Also, on today's market, the first to release wins. I know there are some exceptions but whoever wins the market first has clear advantages. So why is time not a good metric? And I didn't account for second version effects, that was not my aim.
JetSpiegel 9y ago
Even it you just hardcode the tests cases in a giant lookup table? Tests can prove the presence of bugs, but paying doesn't mean the software is bug free.

hn_throwaway_99 9y ago

I think your example shows exactly why measuring software productivity is so problematic. With your scenario, probably the easiest way to "improve productivity" would be to not write any documentation comments, heck it would probably be faster to just stick it all in one giant method. I think many of us have known software developers who are incredibly fast, but who write "rat's nest" code that's impossible for anyone else to decipher, or which is very difficult to modify when new requirements come along. Quantifying those attributes is incredibly difficult, but as most time in software is actually spent on maintenance, it usually ends up being more important than a simpler assessment of initial output.

vmateixeira 9y ago
One can assume writing documentation and comments is covered by both approaches. Still, the fastest scenario would be the most productive one. I agree with your view regarding maintenance cost, but I don't think that's what's at stake here. We can go further and try to compare the amount of time needed to fix rat's nest with the amount of time needed to write the software all over again. Covering the rat's nest is in many occasions faster (on which I'm considering more productive) than rewriting.
- hn_throwaway_99 9y ago
  You're never going to get around the fact that most of these things are qualitative assumptions. Is your documentation good? There's really no completely objective way to measure maintainability, because maintainability is often about how easy it is to handle unknown future change requests. Years ago "function points" were bandied about as a truly objective measure of software output and value. It turned out to be trivially game-able and added 0 value to software development estimation.

qwer 9y ago

I think you really did oversimplify it. Writing a piece of code once obviously affects your speed at writing it again.

vmateixeira 9y ago
As you clearly understood, that's not what I meant.

lomnakkus 9y ago

Ok, so now you "just" need to factor in long-term maintenance. Besides, how often do you write code twice just to see which way is better? What you have is a comparative measure that is completely useless for measuring new code, i.e. code which implements a new feature.

lloeki 9y ago

Where is your metric? By how much will you be declared more productive? Is it just time to achieve a result? Because that is obviously wrong. How are you accounting for quality, or even measuring that X? Do you account for readability? maintenance? documentation? factoring? over-engineering? There are so many visible as well as hidden factors that attempting to measure any (let alone all) of that is a pipe dream. Also, by writing the second one you are not accounting for second version effects since it is a reimplementation of something you know, and if someone else develops it for you then you just changed a major variable. I get that you said "oversimplified", but this is just like saying "thought experiment", yet as soon as you confront that to the real world, it just doesn't realistically fly.

vmateixeira 9y ago
> Why is time for achieving a result a wrong metric? We're paid per hour of work. Also, on today's market, the first to release wins. I know there are some exceptions but whoever wins the market first has clear advantages. So why is time not a good metric? And I didn't account for second version effects, that was not my aim.

JetSpiegel 9y ago

Even it you just hardcode the tests cases in a giant lookup table? Tests can prove the presence of bugs, but paying doesn't mean the software is bug free.