Maybe we need a separate campaign, "Kill Games": any games whose existence requires players being "shaken down" should not be allowed to exist.

Or “You Don’t Need to Play Video Games”.

I enjoy playing video games but I recognize them for what they are: a luxury past-time that is not necessary for life and one that would probably leave most of us better off if they all disappeared tomorrow.

> one that would probably leave most of us better off if they all disappeared tomorrow

I get what you are trying to say, but in general video games offer unique experience that no other media can provide - interactivity, e.g. exploring different worlds with different mechanics. I think this experience can invoke something in people that no other media can replicate. So I think we will lose something important if it suddenly vanishes.

We had a way of measuring velocity, but who cares about estimating stories when we could be spinning up more agents? Burn a bunch of tokens and those stories will be DONE before you could even find your planning poker cards!

I've lived through a bunch of initiatives about improving planning and estimation. None of them turned into a stable process that worked for anyone. I don't know if I can extrapolate from that, but it gives me an inclination that no one really trusts anything that comes out of task estimation. Which would be why we're looking for more objective metrics like token burn rate. No room for argument - tokens are tokens!

A token is approximately word generated by a LLM; a few dozen tokens gets you a line of code... so measuring token burn rate is the same as counting lines of code. All it took was a change of name, and we're back to the most primitive metric we ever got for measuring programmer productivity.

I don't think I can take anything from management in tech seriously again after tokenmaxxing.

"When a measure becomes a target, it ceases to be a good measure"

https://en.wikipedia.org/wiki/Goodhart%27s_law

This but unironically.

The speed of generating code is now faster than the time it takes to plan and estimate how long it will take to generate the code.

Generating more code faster might be useful, but there have to be some other constraints on it.

Using this paradigm, we can achieve unlimited bugs sooner than ever before.

1. To fix a bug, always add code, never remove. 2. Whenever you fix one bug, always introduce at least two new ones.

This sounds like government software, in my experience.

I was brought on to one particular team to do cleanup and all I was given was band-aids to layer on top.

Odds are good your local or state government is running this software right now for managing its courtrooms.

They obfuscate it more than just pressing "Yes". You get a big warning saying Microsoft Defender has protected you, and the only clear option is "Don't run"

https://cdn.advancedinstaller.com/img/prevent-smartscreen-fr...

In order to run, you have to click on "More info", and then a second "Run anyway" button appears.

There's way more than 5% of the Windows userbase that gets confused and can't get past this warning.

There was an audit of the VPN servers earlier this year:

https://mullvad.net/en/blog/fourth-infrastructure-audit-comp...

The Business Source License is not an open source license. Open source does mean "free to use without encumbrance" - see points 5 and 6 of the Open Source Definition at https://opensource.org/osd

Yea - software released under the BSL is “source available”, not open source.