4 ms·

Such is the hellscape we’ve brought on ourselves from the widespread adoption of “minimum viable product” as the right way to build things. We judge viability b

Such is the hellscape we’ve brought on ourselves from the widespread adoption of “minimum viable product” as the right way to build things. We judge viability by some feature set, not whether the stupid thing is resilient or can be maintained. It also doesn’t help that “minimum viable” is only one step away from “non-viable”. Every project then becomes like Icarus, testing how close to the sun we can fly before our wings melt.

sweezyjeezy 2y ago
But what's the alternative here? "We spent longer than was minimally viable but we still don't have a good idea if it has market fit"-product? In my experience the code usually gets binned whether the idea gets traction or not. Some companies misjudge when to rewrite, but that doesn't make the MVP part of the process wrong. The absolute greatest wastes of talent and humanity I've ever seen in tech didn't come from tech debt, those efforts were almost always at least working on a product that people were paying money for. The biggest wastes were from over-delivering products that hadn't and were never going to succeed.
- trentnix 2y ago
  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.
  - cyanwave 2y ago
    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
  - generic92034 2y ago
    > 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).
  - sethammons 2y ago
    We changed it to Most Lovable Products to reinforce that we don't just do the minimum, we need our customers to enjoy it
    - trentnix 2y ago
      I like it!
- deleted 2y ago
  [deleted]
- usefulcat 2y ago
  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.
  - kiba 2y ago
    "Temporary" frequently become permanent.
- meiraleal 2y ago
  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
- k_bx 2y 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.
  - FearNotDaniel 2y ago
    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.
    - wry_discontent 2y ago
      This totally isn't true. Some languages make refactoring easier and some make it harder. FP languages make it easier
    - tome 2y ago
- theFco 2y ago
  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...
jahewson 2y ago
I don’t think MVPs are the problem here. Most projects were like this before MVPs were conceived of. Usually the failure is that the project isn’t minimal at all. It’s usually the maximum complexity that a given team can handle.
rorytbyrne 2y ago
MVP is a good approach when interpreted correctly: “minimum” is in reference to the feature set, not the implementation quality.
- sulandor 2y ago
  almost makes it sound like implementation quality does not play into viability
  - rorytbyrne 2y ago
    Implementation quality should always be high, that is standard practice for engineering disciplines.
mihaaly 2y ago
What I'd like to see managing expectations towards the new product well before anything started, considering resource (time, money, workforce, etc.) limitations. And not going for the shiny things do not fit! Because limitations are everywhere. Ok, software engineers like to pride themselves in the ability to do anything and everything (not as much as salesguys of course) but this stems from the ninja attitude towards technology and forgetting other dimensions of reality. Should only attempt managable goals on all necessary levels. I am still waiting for place where this is achieved...
sethammons 2y ago
I don't blame mvp at all. At $prev_gig, we did agile and mvps and all that. BUT we also focused on ownership. You build it, you support it. Forever, or until officially handed off and accepted by another team. Everything has an owner. You can still get teams who are scared of what they own and refused to update it, but that is a whole lot of "and so? Do it" when you have a healthy product backlog that is single stack priority and the higher priority thing requires output from them (while a pain, it didn't happen _that_ often). To be fair, $prev_gig was a very well ran company in a lot of ways and better than any other shop I have been in.

sweezyjeezy 2y ago

But what's the alternative here? "We spent longer than was minimally viable but we still don't have a good idea if it has market fit"-product? In my experience the code usually gets binned whether the idea gets traction or not. Some companies misjudge when to rewrite, but that doesn't make the MVP part of the process wrong. The absolute greatest wastes of talent and humanity I've ever seen in tech didn't come from tech debt, those efforts were almost always at least working on a product that people were paying money for. The biggest wastes were from over-delivering products that hadn't and were never going to succeed.

trentnix 2y ago
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.
- cyanwave 2y ago
  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
- generic92034 2y ago
  > 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).
- sethammons 2y ago
  We changed it to Most Lovable Products to reinforce that we don't just do the minimum, we need our customers to enjoy it
  - trentnix 2y ago
    I like it!
deleted 2y ago
[deleted]
usefulcat 2y ago
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.
- kiba 2y ago
  "Temporary" frequently become permanent.
meiraleal 2y ago
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
k_bx 2y 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.
- FearNotDaniel 2y ago
  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.
  - wry_discontent 2y ago
    This totally isn't true. Some languages make refactoring easier and some make it harder. FP languages make it easier
  - tome 2y ago
theFco 2y ago
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...

jahewson 2y ago

I don’t think MVPs are the problem here. Most projects were like this before MVPs were conceived of. Usually the failure is that the project isn’t minimal at all. It’s usually the maximum complexity that a given team can handle.

rorytbyrne 2y ago

MVP is a good approach when interpreted correctly: “minimum” is in reference to the feature set, not the implementation quality.

sulandor 2y ago
almost makes it sound like implementation quality does not play into viability
- rorytbyrne 2y ago
  Implementation quality should always be high, that is standard practice for engineering disciplines.

mihaaly 2y ago

What I'd like to see managing expectations towards the new product well before anything started, considering resource (time, money, workforce, etc.) limitations. And not going for the shiny things do not fit! Because limitations are everywhere. Ok, software engineers like to pride themselves in the ability to do anything and everything (not as much as salesguys of course) but this stems from the ninja attitude towards technology and forgetting other dimensions of reality. Should only attempt managable goals on all necessary levels. I am still waiting for place where this is achieved...

sethammons 2y ago

I don't blame mvp at all. At $prev_gig, we did agile and mvps and all that. BUT we also focused on ownership. You build it, you support it. Forever, or until officially handed off and accepted by another team. Everything has an owner. You can still get teams who are scared of what they own and refused to update it, but that is a whole lot of "and so? Do it" when you have a healthy product backlog that is single stack priority and the higher priority thing requires output from them (while a pain, it didn't happen _that_ often). To be fair, $prev_gig was a very well ran company in a lot of ways and better than any other shop I have been in.