Measuring developer productivity has been an unsolved problem for decades already, vibe engineering just makes that unsolved problem feel even harder.

▲

ozim 7 hours ago | parent | next [-]

Measuring “single developer productivity” is unsolved problem. It also is not a problem unless you are pointy haired boss and want to plan bonuses based on that or fire people based on that.

You definitely can measure team output over time and have some idea. Compare team to what they did in last 6 months and you have your measure for having idea how much can be achieved next month. But you cannot not plan like what can be achieved in longer period just next sprint or two.

This said you cannot compare teams like that.

▲

chii 8 hours ago | parent | prev [-]

proxies like customer/revenue growth, complaints/satisfaction and such works imho.

	▲	ozim 7 hours ago \| parent \| next [-]
		Missing part of discussion is “what for?”. To make personnel decisions who to fire or give bonuses it doesn’t work. Just as lines of code don’t. If any of those indicators is lacking you have to dig deeper. What lazy managers want is a single number they don’t have to dig into to make decisions. Lines of code, story points, bug counts. To plan work for next sprint having last 6 months of stats gives quite good idea what can be achieved. But story points or stats are not useful for telling if specific features will be developed in specific timeframe.
	▲	tonyedgecombe 7 hours ago \| parent \| prev [-]
		How can you assign revenue growth to a particular feature? Even if the customer tells you they bought your product because you added widget x you can't really be sure. So much of this stuff is emotional rather than rational.