Well, productivity measures how fast you deliver new value. Fixing a bug is about repairing value that you thought you had delivered but actually did not. Counting bugs as "value" would be double counting.
> Fixing a bug is about repairing value that you thought you had delivered but actually did not.
In that case it's important to classify issues correctly. Email sending worked yesterday but not today because Office365 changed some SMTP requirements (say ciphers)?
Customer will call it a bug, but according to your definition it should be classified as a feature.
Interesting to note that two of your decision points are on "shipping product improvements at a regular cadence" or "shipping so slow that it's negatively impacting customers". Both relate to a productivity discussion, ie "how to define what it means to 'ship' as an engineering team". In that sense, we're aligned on why it's important to measure productivity.
It would however be a mistake to try to optimize for maximum productivity in a vacuum, but note that this is not what this thread is about. This thread is about the unit of measurement that people use in their teams. In that sense it's purely a research / curiosity question
The material output of programmers is code. In that sense, programmer productivity is (|additions| + |deletions|) / time. Economically, it’s (|additions| + |deletions|) / wages paid.
This is how I would quantitatively measure the productivity of members on the teams I work with. If you look at this measure across your team, I think you’ll find it roughly matches your intuitive notion of who the most productive programmers are. I also think you’ll find story size positively correlated with the magnitude of code change or time.
The thing is, measuring how fast programmers output software isn’t all that useful.
This feels like you're measuring lines of code as productivity, but most experienced engineers would disagree that lines of code is a good metric. Am I misunderstanding your assertion?
Code is the output of a programmer. Time (or wages) is the primary economic input to software development.
Productivity is not a measure of whether something is worth doing. It says nothing about whether the code is valuable or worth writing. A factory has increased productivity if it has produced more widgets with the same inputs, even if nobody wants those widgets or those widgets pollute the environment.
Similarly, programmers do not choose what software to write. They are employed to write software someone else decides is valuable to the business. Their productivity is independent of whether the software has business value.
Consider a one line program. A programmer that produces that program in 5 minutes is more productive than one who produces it in 1 hour.
Stories with sizes are proxies for magnitude of code change or time. A larger project is larger because it takes more time or more code change, or both. Story size/points is an attempt to estimate this. So it is more accurate to measure the actual code change and time taken.
It’s true that the same program can be written with different amounts of code. But this is largely irrelevant at the organization level, where programmers are not writing multiple versions of same program in different languages and toolsets. A team is typically writing software within the context of a particular toolchain and runtime environment.
It was supposed to represent "how big" the feature was.
As it's subjective and vague, the score was suggested by the engineer in charge of the feature and then (rapidly) approved by the team during daily meetings.
But I guess this principle could be applied with a score representing whatever you want to track, and however you want to track it.
I agree 100%, you need to have a strong product foundation to turn good output into good business outcome. A productive team that delivers features no one wants is pointless. Both go hand in hand, but as far as engineering management goes, it is still a challenge to find a good productivity metric. What’s used in your organization @przeor and what do you think of it?
1. Yes, that's the point. 10x doesn't say "compared to what", but hints at "compared to now"
2. For sure. My 3 former companies let people spike while working, and I've seen mediocre engineers (lots of bugs, rework) become ok (barely any rework, a few bugs from time to time)
You're right in a way, but you're missing the "10x compared to what?". Consider the 1x baseline as being the median productivity of your development team (which is definitely hard to approximate, but for the sake of the exercise let's take 'value-added tickets per developer' [which excludes bugs/rework]). Then the goal is to do 10x on this median in a reasonable amount of time. Rince and repeat.
