I'm not the user you're replying to, but I found this question interesting.
> Do you think programming productivity is possible to measure and if so how?
For the purpose of discussion, I would propose that a team of developers are given a simple task with highly specific and explicit functionality requirements. This team of developers should Ideally have no experience with any of the technologies used. Experience with the problem domain is acceptable. These developers would then be tasked with building out the solution with various different technologies (languages, frameworks, libraries). We then compare the time it took for the developers to complete the task relative to the amount of bugs present in the solution. For example, the team could be tasked to build a gui calendar with Haskell and then Python.
The issues with the above proposed experiment are as follows:
* We would need to find some way to adjust for problem domain familiarity. The developers are going to get better, and thus more productive, at the task after they have completed it the first time.
* We need some sort of concrete numerical measure of "bug likelyness" for lack of a better term. All software has bugs, but some are very hard to find or appear only during runtime under very specific conditions.
* We need to decide whether or not we take the language ecosystem into account. In the calendar example I provided above, Python would obviously be more productive because there are a ton of different packages available that make creating a GUI extremely trivial.
* Do we take into account time spent on learning the language/tool/package/framework/library? Do we measure the amount of time that it takes the team to feel comfortable working with a new technology?
All in all, it's an interesting thought experiment and I'm interested to hear what you think.
> Do you think programming productivity is possible to measure and if so how?
For the purpose of discussion, I would propose that a team of developers are given a simple task with highly specific and explicit functionality requirements. This team of developers should Ideally have no experience with any of the technologies used. Experience with the problem domain is acceptable. These developers would then be tasked with building out the solution with various different technologies (languages, frameworks, libraries). We then compare the time it took for the developers to complete the task relative to the amount of bugs present in the solution. For example, the team could be tasked to build a gui calendar with Haskell and then Python.
The issues with the above proposed experiment are as follows:
* We would need to find some way to adjust for problem domain familiarity. The developers are going to get better, and thus more productive, at the task after they have completed it the first time.
* We need some sort of concrete numerical measure of "bug likelyness" for lack of a better term. All software has bugs, but some are very hard to find or appear only during runtime under very specific conditions.
* We need to decide whether or not we take the language ecosystem into account. In the calendar example I provided above, Python would obviously be more productive because there are a ton of different packages available that make creating a GUI extremely trivial.
* Do we take into account time spent on learning the language/tool/package/framework/library? Do we measure the amount of time that it takes the team to feel comfortable working with a new technology?
All in all, it's an interesting thought experiment and I'm interested to hear what you think.