4 ms·
You've made an assertion, but not provided any evidence for it. That doesn't seem, to me, to add much to the discussion. Would you like to back your statement
by AndrewDucker 9y ago
You've made an assertion, but not provided any evidence for it. That doesn't seem, to me, to add much to the discussion.
Would you like to back your statement up?
- renesd 9y agoThey don't need to back it up. It is up to the person making the original claim to back it up. There's half a century of research and practice into this topic. Anyone in the industry _should_ know about this. Anyone who doesn't can find it on a search engine within 30 seconds.
- Retric 9y agoNo, it's a well known problem. The old lines of code joke still applies. You can introduce metrics, but those will just be gamed because software is a multidimensional optimization problem with complex trade offs. So, you can't translate that to a single measurement and call it productivity.
- renesd 9y agoYes, it's a well known problem.
- deleted 9y ago[deleted]
- AndrewDucker 9y agoThere's half a century of research - and yet, no clear way of measuring productivity, that I am aware of. If you're aware of one then a link to an article about it, or even a wikipedia page, would be awesome.
- vmateixeira 9y agoIn software, productivity can pretty much be measured through time spent on a task, while mantaining same quality.
- lucideer 9y agoBefore which you have to figure out how to measure quality. There are countless ways of course, but choosing your metrics is subjective and pretty much arbitrary.
- vmateixeira 9y agoI 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 agoI 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 agoOne 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.
- mi100hael 9y agoI find Agile velocity to be a fairly useful measure: 1. Break your workload into small-ish units of work 2. Before starting a unit, assign it a number value based on how complex the task is. 1 is absolute easiest, 2 is twice the work, etc. 3. Compare how many points of work you complete over periods of time