Reverse Jevons Paradox (mht.wtf)

[dead]

> you might effectively kill a whole class of changes, like "small refactor" PRs.

Or the changes might be "smuggled through" in an unrelated changeset that has to go through the red tape anyway.

Now that I think about it, it's very easy to point to reverse jevon's paradoxes. Regulations around building housing, large org bloat + processes, when the stupid form fill that i need to fill out gets too long on some website...

> If you make it hard to change code by requiring multiple levels of reviews, a web of Jira tickets, a horde of people needing to sign off, and other red tape, you might effectively kill a whole class of changes

I remember this theater on things which were suspected to be too expensive with insiffiufficient ROI to implement, except that all the time wasted by multiple people arguing in Jira tickets, sitting in meetings, and writing specifications was likely far more expensive than just building and testing the thing.

For some reason, there seems to be a strong and automatic tendency for older and larger organizations to drift toward petrification through bureaucratization.

Or also called bureaucracy

> Jevons paradox happens when the cost of a resource goes down, but the total spend on that resource goes up.

I would argue that is not Jevons paradox but standard supply and demand (and this "reverse Jevons paradox" too). Jevons paradox occurs when a more efficient use of a resource leads to an increase in its use (instead of a decrease as a first order analysis would suggest).

The author has discovered the red tape.

> if the cost of a resource goes up, the total spend on that resource can go down.

Not unlike hiking taxes on the rich, seeing them vote with their feet, and revenue subsequently catering.

But as long as we reward politicians for delivering blame more than results, this political folly will continue.

Until Strein's Law[1] kicks the teeth in.

[1] https://en.wikipedia.org/wiki/Herbert_Stein#Stein's_Law

Jevons Paradox is called a paradox because it is non-intuitive. It is very intuitive to conclude that when costs go up, people will use less of that thing.

> The cost of making small changes to the codebase is so high that it becomes net-negative for a single developer to make the change

That's called Software Engineering at Google

In micro economics theory they call this price elasticity where you try lowering the price to see how much more customers buy and you plot that to a graph calculator to get a curve and the bend on the curve is the price elasticity. Then you can calculate the optimal price to maximize sales.

Will it happen to memory? I am looking at you guys, electron apps.

I can’t tell if this is a troll post or not, but either way, the concept the author seems to be looking for is called the “Law of Demand” [0].

0: https://en.wikipedia.org/wiki/Law_of_demand

> if the cost of a resource goes up, the total spend on that resource can go down

... must be a satire post, right? This is just the most plain and intuition result.

> “if the cost of a resource goes up, the total spend on that resource can go down”

This is tautologically true in the limiting case of infinite cost.

One of my favorite examples of this kind of thing is requiring a ticket for every change.

There is a class of changes that take very little time but have a positive impact. If the cost of making a ticket for that change exceeds the cost of the ticket, it's human nature that some people just won't make the change.

This is a bit of a contrived example (e.g. you could bundle multiple small changes into one ticket) but it's still a good example of a policy meant to make things better actually leading to fewer improvements.

I think that this person does not know what the Jevons Paradox is. The Jevons Paradox is that increasing the efficiency with which a resource is used may increase the total amount of that resource that is used. Consuming more because costs went down isn't the Jevons paradox - it's spending more because costs went down.

So if you give all your coders a great test harness and they run more tests because it takes up less of their time, that's not the Jevons paradox. If you give your coders a great test harness and then they go from spending 10% of work hours on testing to spending 20% of work hours on testing because testing has such a good ROI now, that's the Jevons paradox.

“If delta-x is negative, then delta-y can be positive.”

It seems like there’s a straightforward/obvious corollary that reverses the sign on both clauses. (Walk the curve in the opposing direction.)

I liked this footnote. A simple, intuitive explanation.

> If you pay $1.00 to press a button, and pressing the button pays you $0.99, you > will press the button zero times. If you get $1.01 instead, you will press the > button all the time.

One thought: If it only gives you $0.01 profit you'll (have to) push it more than if it gave you $1000 profit. There's a saturation point.

I thought this would be about the actual reverse effect, namely that if something gets too cheap, people don't want it anymore. Which would have been also an interesting article, regarding status symbols and luxury items.