Then the output isn't the same if not all students had the same outcome. Furthermore you used day as the time period when talking about programming. I assumed as a matter of consistency you meant to use roughly the same time period for teaching. Every semester I teach calculus is different. Two different people don't teach the same way even if the curriclumn is the same.
Your statements here strengthen the parody. Merge sort is the same for everyone, right? So let's just go by lines of code. The outcome is the same.
A mistake in wording on my part - I should have said "the desired outcome is the same". Sorry for the confusion.
Two different people don't teach the same way even if the curriclumn is the same.
So what? The goal is the same. It is meaningful to measure whether my students know more or less calculus than yours.
If the goal of programming were to re-implement merge sort over and over then it would be an effective metric to count the number of correct merge sort implementations.
The inability to compare a realtime monitoring system to a web scraper is what makes programming harder to measure.
But in many cases one can measure programmers by output. For example, at Styloot, one task we have is building web scrapers. They all have a pretty straightforward (and identical) goal. An effective metric for programmer performance on this task would be to measure the # of scrapers written or (better) the # of items correctly scraped.
See also quant traders - the goal is homogeneous (increase profit, adjusted for risk), and your code is measured by how well it achieves that goal.
Your statements here strengthen the parody. Merge sort is the same for everyone, right? So let's just go by lines of code. The outcome is the same.