A portion of “product-market fit” failures are actually software quality failures. I think it’s easy to blame the ensh*ttification of software on corporate incompetence, but I think “minimally viable” is part of the story as well.

The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it.

Hard agree with the last sentence. We’re capable of greatness, im optimistic for new generation products. Not all humans are bad. Cycles and such

> The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it.

Not every area in the software market is like this. For example, in ERP software often applications from the 90ies are still in use (maybe revamped, maybe not) by many customers. And the maintenance periods are measured in decades (typically not initially, but there always seems to be a maintenance extension).

We changed it to Most Lovable Products to reinforce that we don't just do the minimum, we need our customers to enjoy it

I like it!

In the context of the topmost comment, the alternative is “don’t stop at MVP”.

If you make an MVP and end up discarding it shortly after, that’s fine, and completely appropriate for an MVP.

OTOH, MVP may not be sufficient for something that the business still relies on day in, day out months or years down the road.

"Temporary" frequently become permanent.

If it didn't get traction someone defined badly what was the MVP. As it wasn't viable. The M gives the idea of a minimal feature set or low effort but it shouldn't, a MVP now that competition is high needs much more quality and features than a decade ago

In my opinion, instead of searching for alternative we should use good programming languages that are extremely refactor-friendly and legacy-resistant.

That's why I love ELM as a front-end langauge (and hope to see a successor ROC succeed).

For back-end, that's why I love Rust, Haskell etc. All languages that are closer to Pure, FP. Because I can leave codebase to other devs and still know that it's not gonna turn into something which I've seen happening to Python, PHP and other OOP language codebases.

Nope, it's not really about the language - any mainstream language/platform can be used well or badly depending on who's guiding the design of the app (assuming somebody is, instead of falling into the "agile means no design up front" cult). You can create an elegantly structured, maintainable app in python, node, rails, .net or you can create a big ball of mud. Perhaps apps in Elm, Rust, Haskell et al have a bias towards better design because they themselves attract an elitist crowd who think more consciously about these things. If Haskell ever caught on enough to have an "eternal September" moment then the world would be littered with shitty codebases of pseudo-pure-functional code that somehow broke all the idioms that are supposed to make the language great.

I once had a client who'd had a shiny but disorganized MVP developed on .NET, and of course as the org tried to scale and ramp up new features, the devs had to fight more and more against the design (or lack of it in some parts, or overly complex over-design in other parts). At some point he met some dude at a networking event who had built a successful business on a Node codebase, and became convinced that we should rewrite from the ground up in Node because our performance problems were all the platform's fault. Wrong wrong wrong. But it's much easier to believe a sales pitch than to do the hard work of learning what good, performant design in your chosen language/framework looks like.

This totally isn't true.

Some languages make refactoring easier and some make it harder. FP languages make it easier

Who knows whether Haskellers are better, on average, at designing software. As a Haskeller I'd like to think they are! But I really have no idea. What I do know is that _I_ can design better software in Haskell than in Python, and I put that down to qualities of the language.

Help, I've seen bad elixir. Ecto queries spanning dozens of tables with the performance grinding to a halt as load increased, with models and logic so intertwined that you had little hope of untangling the ball of string so you could refactor and scale the database.

You can make bad things in any language. I like Go for the same reasons you like FP. And there too, people can do strange and unmaintainable things

The MVP shows if the idea would get traction. But what good is an idea that gets traction if it is unfeasible to scale, or the organisation is not willing to support it. I think this is what google does with many of its products that end up cancelled. They tested the MVP, people bought in, but the organisation already moved on, so there is no will to support and further develop it. We should be responsible and do an MVP only after deciding if the organisation would be able and interested to scale a product and support it. Otherwise, the downsides are a toxic crunch to support the product, customers are unhappy with yet another product dies, etc...