It also points out the fallacy and lie of electric car companies caring about the environment. They don't. It's just the new thing to sell. Just like every company known to man is parroting sustainability now.

Sure, but it doesn't matter whether they actually "care" about the environment, or just about selling cars, an electric car is still better for the environment.

Now, if you keep buying new cars to keep up with the latest features, that's a problem.

> Now, if you keep buying new cars to keep up with the latest features, that's a problem.

It depends on what happens to your old cars (and they're mileage ratings). Many people are driving more inefficient cars and would upgrade if affordable used cars were available. The market can absorb more than a few yearly upgraders, though of course after a point it is a waste.

ugh. their instead of they're.

Everyone can make a good car now, they are a commodity now. So to differentiate in the market you turn to nonsense (pointless features you can talk about) and obfuscation (confusing pricing and options and fees, ala airlines)

I'd say warranty is the feature I'm most interested in.

I'd much rather have a reliably car than a solid warranty. If fewer creature comforts get me there then count me in.

That's right... commodity fetishism manufacturing consent:

https://www.alexanderrea.com/project/mcdonalds-happy-world/

Because what could be more fun than praying for autonomy at speed in a self-driving car while ordering a happy meal?

I'm happy they stopped at the concept.

Given the lack of regulation, I'm surprised we don't have drones dropping happy meals through moon-roofs in traffic like turkeys-via-chopper on WKRP in Cincinnati.

Does the word 'good' have a different meaning in the US? Your car manufacturers barely manage to compete in the segment protected by the chicken tax tariff... Some do a decent job in luxury EVs.

This is becoming so widespread, it’s no longer just a byproduct of how a project or a product is managed. It’s an explicit guidance that is explicitly stated in the form of “No feature should take more than 1-2 months. 3 months feature work is the longest term we should plan and consider. Everything we work on from planning to design to implementation to deployment needs to be in the hand of a customer at most in 2-3 months max” I even had this hilarious conversation with my manager once.

I asked: “You know how broken this feature is, right? Like if you even deviate from the simple announcement example in any way, you’ll probably be broken in a completely unknown way. We’re providing an ‘alternative’ that only implements a 1/10 of the scenarios but nonetheless exposes the same interface to users”

He said: “yeah, that’s fine. The most important thing is to deliver something for users to use. To even know if anyone wants this at all or if no one will use it”

I perplexedly asked: “but how would you know if people are not using it because they don’t want it, or if they are using it because they try and it’s hopelessly broken?”

He said: “We’ll fix it. If they are not using it because it rough or broken, then we’ll fix it. We will wait for feedback about what’s broken and fix the problem they run into. If people want to use something and they find issues, they’ll just report it.”

I said: “… do you do that? You try a feature in a new product or a tool or a feature, and when it doesn’t work at all, do you start file feedback items and work with that company to make sure their feature work? I know i don’t. I just move on until they fix it or find a competitor who has a better alternative”

He said: “no, most people will report problems and we can fix them as they come. Also we should tell from telemetry what people are trying and what’s not working and what we should fix vs not”

I said: “yeah, that makes sense.“, knowing that our telemetry is also generally broken because it’s implemented in the same way and generally we do the work when business folks come back asking for some data or complaining how the data we provide doesn’t add up.

Oh fun times.

this sounds like a conversation wherein someone learns about lean startup / agile methodologies for the first time (build an MVP and get it in front of people ASAP to get feedback, don't perfect it first)

Shipping obviously broken stuff is a good way to discourage users from giving any feedback at all.

believe me, they'll let you know when you ask.

“Not perfect” is a straw man because obviously nothing ever is perfect or 100% complete. When shipping something becomes the priority, then “obviously broken” stuff just gets re-dubbed “not perfect” which is exactly the problem.

If your users are forced to use your platform because you mainly sell to CTOs who only need a list of checkboxes checked, and they strike a deal with you, then yeah. It’s a great business model to check as many boxes as possible, get that contract, then figure out what those boxes actually mean later.

"obviously broken" is a straw man because we're just discussing anything that doesn't satisfy everything you want (which you listed).

indeed, the concept of an "obviously broken" MVP is an oxymoron, since V stands for "viable"

when giving everybody everything they want becomes the priority, then "not perfect" stuff just gets re-dubbed "obviously broken" by 1 random person, which is actually the problem: it's better to ship something and get feedback and iterate on it than to ship nothing or to ship the wrong thing after a long development time or to ship at the end of however long it takes to satisfy everybody's desires