6 ms·

> Creating a MVP should take not more than 1 month. Depending on your domain, 1 month is not enough to even understand the problem. > Reuse before Buy, Buy be

> Creating a MVP should take not more than 1 month. Depending on your domain, 1 month is not enough to even understand the problem. > Reuse before Buy, Buy before Build The accidental complexity to integrate w/ a 3rd party solution can sometimes surpass that of building your own solution. I call BS on dogmatic rules like that. Good architecture is analysing the requirements at hand and explicitly articulating and weighting the trade-offs.

gertlex 6y ago
> Depending on your domain, 1 month is not enough to even understand the problem. I ran across this too in brief skimming (There's a lot there) but I assumed it was talking about building the MVP after doing the learning needed (in as much as you ever fully understand most domains) and designing of the MVP system.
- hcarvalhoalves 6y ago
  If you follow Lean (where "Minimum Viable Product" originates from), there's no hard split between design/implementation phases, since the whole concept of MVP is avoiding waste in building something nobody wants. The keyword is "avoiding waste", not "build something in 1 month". You can still waste 1mo work pretending to be fast and shipping crap, that's not the point. The time a Minimum Viable Product will take is still completely determined by the requirements (definition of "viable", budget, experience, regulations, etc).
senux 6y ago
> I call BS on dogmatic rules like that. Good architecture is analysing the requirements at hand and explicitly articulating and weighting the trade-offs. I particularly like your point above. I apply that same perspective to several other domains. For example, purchasing a new phone, choosing a new tool for work or personal use, purchasing a car. It's easy to make decisions based on personal preference or, like you mentioned, dogmatic rules and call them "the right way of doing things".
- smoe 6y ago
  I agree, but it also fairly easily to be dogmatic overanalyzing things instead of executing. Especially early stage, you have limited knowledge what the requirements of a product that will stick might be. I think considering cost of future change and try to keep it low as a general rule is more important, than trying to make all the right choices from the get go for something you don't yet understand. You might have a good understanding of the problem, but that doesn't mean your solution will work and you have to adapt.
jonahx 6y ago
> The accidental complexity to integrate w/ a 3rd party solution can sometimes surpass that of building your own solution. This is one of the most common and damaging mistakes I see. Here are some other hidden costs that are often invisible to people: 1. The cost of understanding the 3rd party solution, which increases with the generality of the tool. That is, you are using a tool which solves A, B, C, and D to solve A. Using a well-documented tool helps here, but doesn't eliminate the problem. 2. The cost of upgrades, especially when forced by a security issue. 3. Framework vs library costs. It usually much less costly to import pure functions (think: an assertion library) versus importing a framework which forces a bespoke way of doing things (think: rspec).
- javajosh 6y ago
  I can't agree with you and the GP enough. 3rd party software is hell to integrate! We can at least hope that in a science fiction future there will be a standardized container abstraction for delivering working software, with well-defined conventions regarding an admin interface for setup, an operator interface to investigate issues, and a user interface, which we make as reliable, comprehensive, trustworthy, and buttery smooth as we can make it.
- fbr 6y ago
  I agree that integrating a 3rd party solution has multiple hidden cost. > This is one of the most common and damaging mistakes I see Interestingly, the most common mistake I see is people neglecting the cost of developing a solution themselves: 1. opportunity cost 2.long term maintenance 3. documentation & training new people ...
  - jonahx 6y ago
    Agreed rolling your own has hidden costs too and is often not the right choice. Ime, though, this lesson has almost achieved meme status. So while both types of mistakes are made, the "hidden costs of 3rd party tools" is often not a consideration at all. The node "left pad string" debacle is the archetypal example here.
Dopameaner 6y ago
I took the playbook with a grain of salt. It can be used as guidelines rather than a roadmap.
idolaspecus 6y ago
> I call BS on dogmatic rules like that. Good architecture is analysing the requirements at hand and explicitly articulating and weighting the trade-offs. This is quite the straw-man argument. For example, the section [1] whose title you quoted explicitly calls out the need to perform an evaluation first: > When functionality is required, existing IT assets in the organization must be evaluated and used first, unless they do not exist and/or are a significant mismatch to the required functionality. The "book" is clearly a draft-quality rough collection of notes, many of which are not fleshed out extensively, but it's quite unfair to consider it as a set of "dogmatic rules". [1] https://nocomplexity.com/documents/arplaybook/businessarchitecture.html#reuse-before-buy-buy-before-build https://nocomplexity.com/documents/arplaybook/businessarchit...
- hcarvalhoalves 6y ago
  > When functionality is required, existing IT assets in the organization must be evaluated and used first (...) Why must be evaluated and used first? Will I even have time to evaluate? What am I optimising for? Rules like "do this, do that", departed from the actual problems and the constraints, are by definition ignoring 100% of the data - that's why I call it dogmatic. I would appreciate more if it at least supported these claims w/ examples or links to studies, but it doesn't.
  - idolaspecus 6y ago
    I guess I agree the word "must" is maybe too far, but I'd hardly go so far as to say it satisfies the requirements for "dogmatic BS".
SNosTrAnDbLe 6y ago
Also, sometimes that third party solution will go out of business if its proprietary or it may simply stop getting code patches/updates if its an open source one. In the former case, contracts will help to some extent to mitigate the danger but you will still be stuck with using a legacy technology.
cratermoon 6y ago
The build vs buy question should definitely never go one way or another dogmatically, it's context-specific. Buy for parity, build for competitive advantage. Only within the context of the business can you decide.
foopod 6y ago
I would say one of the best ways to understand a domain is to rapidly prototype and test in it. One month to me would be the absolute longest. I don't see MVP as necessarily what you launch with, but what you need to test with to prove market viability and reduce risk when spending more money/time.
- hcarvalhoalves 6y ago
  MVP is a term that is tossed around a lot but few people actually use as the author intended. If you seek the literature where the term "MVP" comes from, you'll see 1) MVP is not the same as prototype (you can validate an idea on the market without even a prototype), and 2) there's no definition of "too long", it's situational. > As I talked about in a previous interview, IMVU’s original MVP took us six months to bring to market. That was a pretty big improvement over a previous company, where we spent almost five years before launching. Yet in another situation we spent two weeks building a particular feature that absolutely nobody wanted. In retrospect, two weeks was way too long. We could have found out that nobody wanted the product a lot sooner. At a minimum, a simple AdWords smoke test would have revealed how utterly bad the concept was. [1] [1] https://leanstartup.co/what-is-an-mvp/ https://leanstartup.co/what-is-an-mvp/
kthejoker2 6y ago
From one of the greatest articles I've ever read ( https://iism.org/article/why-are-ceos-failing-software-engineers-56 https://iism.org/article/why-are-ceos-failing-software-engin... ) > When discovering new value, drive to value; when scaling discovered value, drive to date. Meaning: don’t gate value discovery by setting arbitrary release dates. In effect, a release date is nothing more than saying to the team, “we are going to give up on discovery of the actual needed value by <insert arbitrary date here>.” Of course, that’s nonsense. Also, dates don’t increase the rate of learning from failure; they in fact have the opposite effect, the team will be much less likely to discover the value needed as they will actually increasingly fear failure as the date approaches, and they will therefore slow down the rate at which they are breaking things, which effectively puts an end to new learning – no more bugs found, no more value found. If the customers need hasn’t been met yet, it’s just a huge waste and confusing to all involved to release something that doesn’t actually meet the need. It’s even worse to release something by an arbitrary date that has the appearance of meeting the need but is riddled with business risking- or life risking- levels of chaos.

gertlex 6y ago

> Depending on your domain, 1 month is not enough to even understand the problem. I ran across this too in brief skimming (There's a lot there) but I assumed it was talking about building the MVP after doing the learning needed (in as much as you ever fully understand most domains) and designing of the MVP system.

hcarvalhoalves 6y ago
If you follow Lean (where "Minimum Viable Product" originates from), there's no hard split between design/implementation phases, since the whole concept of MVP is avoiding waste in building something nobody wants. The keyword is "avoiding waste", not "build something in 1 month". You can still waste 1mo work pretending to be fast and shipping crap, that's not the point. The time a Minimum Viable Product will take is still completely determined by the requirements (definition of "viable", budget, experience, regulations, etc).

senux 6y ago

> I call BS on dogmatic rules like that. Good architecture is analysing the requirements at hand and explicitly articulating and weighting the trade-offs. I particularly like your point above. I apply that same perspective to several other domains. For example, purchasing a new phone, choosing a new tool for work or personal use, purchasing a car. It's easy to make decisions based on personal preference or, like you mentioned, dogmatic rules and call them "the right way of doing things".

smoe 6y ago
I agree, but it also fairly easily to be dogmatic overanalyzing things instead of executing. Especially early stage, you have limited knowledge what the requirements of a product that will stick might be. I think considering cost of future change and try to keep it low as a general rule is more important, than trying to make all the right choices from the get go for something you don't yet understand. You might have a good understanding of the problem, but that doesn't mean your solution will work and you have to adapt.

jonahx 6y ago

> The accidental complexity to integrate w/ a 3rd party solution can sometimes surpass that of building your own solution. This is one of the most common and damaging mistakes I see. Here are some other hidden costs that are often invisible to people: 1. The cost of understanding the 3rd party solution, which increases with the generality of the tool. That is, you are using a tool which solves A, B, C, and D to solve A. Using a well-documented tool helps here, but doesn't eliminate the problem. 2. The cost of upgrades, especially when forced by a security issue. 3. Framework vs library costs. It usually much less costly to import pure functions (think: an assertion library) versus importing a framework which forces a bespoke way of doing things (think: rspec).

javajosh 6y ago
I can't agree with you and the GP enough. 3rd party software is hell to integrate! We can at least hope that in a science fiction future there will be a standardized container abstraction for delivering working software, with well-defined conventions regarding an admin interface for setup, an operator interface to investigate issues, and a user interface, which we make as reliable, comprehensive, trustworthy, and buttery smooth as we can make it.
fbr 6y ago
I agree that integrating a 3rd party solution has multiple hidden cost. > This is one of the most common and damaging mistakes I see Interestingly, the most common mistake I see is people neglecting the cost of developing a solution themselves: 1. opportunity cost 2.long term maintenance 3. documentation & training new people ...
- jonahx 6y ago
  Agreed rolling your own has hidden costs too and is often not the right choice. Ime, though, this lesson has almost achieved meme status. So while both types of mistakes are made, the "hidden costs of 3rd party tools" is often not a consideration at all. The node "left pad string" debacle is the archetypal example here.

Dopameaner 6y ago

I took the playbook with a grain of salt. It can be used as guidelines rather than a roadmap.

idolaspecus 6y ago

> I call BS on dogmatic rules like that. Good architecture is analysing the requirements at hand and explicitly articulating and weighting the trade-offs. This is quite the straw-man argument. For example, the section [1] whose title you quoted explicitly calls out the need to perform an evaluation first: > When functionality is required, existing IT assets in the organization must be evaluated and used first, unless they do not exist and/or are a significant mismatch to the required functionality. The "book" is clearly a draft-quality rough collection of notes, many of which are not fleshed out extensively, but it's quite unfair to consider it as a set of "dogmatic rules". [1] https://nocomplexity.com/documents/arplaybook/businessarchitecture.html#reuse-before-buy-buy-before-build https://nocomplexity.com/documents/arplaybook/businessarchit...

hcarvalhoalves 6y ago
> When functionality is required, existing IT assets in the organization must be evaluated and used first (...) Why must be evaluated and used first? Will I even have time to evaluate? What am I optimising for? Rules like "do this, do that", departed from the actual problems and the constraints, are by definition ignoring 100% of the data - that's why I call it dogmatic. I would appreciate more if it at least supported these claims w/ examples or links to studies, but it doesn't.
- idolaspecus 6y ago
  I guess I agree the word "must" is maybe too far, but I'd hardly go so far as to say it satisfies the requirements for "dogmatic BS".

SNosTrAnDbLe 6y ago

Also, sometimes that third party solution will go out of business if its proprietary or it may simply stop getting code patches/updates if its an open source one. In the former case, contracts will help to some extent to mitigate the danger but you will still be stuck with using a legacy technology.

cratermoon 6y ago

The build vs buy question should definitely never go one way or another dogmatically, it's context-specific. Buy for parity, build for competitive advantage. Only within the context of the business can you decide.

foopod 6y ago

I would say one of the best ways to understand a domain is to rapidly prototype and test in it. One month to me would be the absolute longest. I don't see MVP as necessarily what you launch with, but what you need to test with to prove market viability and reduce risk when spending more money/time.

hcarvalhoalves 6y ago
MVP is a term that is tossed around a lot but few people actually use as the author intended. If you seek the literature where the term "MVP" comes from, you'll see 1) MVP is not the same as prototype (you can validate an idea on the market without even a prototype), and 2) there's no definition of "too long", it's situational. > As I talked about in a previous interview, IMVU’s original MVP took us six months to bring to market. That was a pretty big improvement over a previous company, where we spent almost five years before launching. Yet in another situation we spent two weeks building a particular feature that absolutely nobody wanted. In retrospect, two weeks was way too long. We could have found out that nobody wanted the product a lot sooner. At a minimum, a simple AdWords smoke test would have revealed how utterly bad the concept was. [1] [1] https://leanstartup.co/what-is-an-mvp/ https://leanstartup.co/what-is-an-mvp/

kthejoker2 6y ago

From one of the greatest articles I've ever read ( https://iism.org/article/why-are-ceos-failing-software-engineers-56 https://iism.org/article/why-are-ceos-failing-software-engin... ) > When discovering new value, drive to value; when scaling discovered value, drive to date. Meaning: don’t gate value discovery by setting arbitrary release dates. In effect, a release date is nothing more than saying to the team, “we are going to give up on discovery of the actual needed value by <insert arbitrary date here>.” Of course, that’s nonsense. Also, dates don’t increase the rate of learning from failure; they in fact have the opposite effect, the team will be much less likely to discover the value needed as they will actually increasingly fear failure as the date approaches, and they will therefore slow down the rate at which they are breaking things, which effectively puts an end to new learning – no more bugs found, no more value found. If the customers need hasn’t been met yet, it’s just a huge waste and confusing to all involved to release something that doesn’t actually meet the need. It’s even worse to release something by an arbitrary date that has the appearance of meeting the need but is riddled with business risking- or life risking- levels of chaos.