Answers: <blockquote>
    <p>start using it if you fail, you can select another technology</p>
  </blockquote>
  
  <p>This approach has two major drawbacks:</p>
  
  <ol>
  <li><p><a href="https://en.wikipedia.org/wiki/Technical_debt" rel="nofollow noreferrer">Technical debt</a></p>
  
  <p>While it may be tempting to apply "fail fast" mentality to architecture and design, skipping or abbreviating the design phase would be a mistake. <a href="https://en.wikipedia.org/wiki/Fail-fast" rel="nofollow noreferrer">fast-fail</a> should be used in conjunction with good design practices, not in lieu of them. Making hasty decisions can often result in poorly scaled solutions. While <a href="https://devops.stackexchange.com/a/1220/2845">using MySQL seems like a good idea when you are working with a 100mb database to generate reports, it scales poorly into the terabyt range for doing your archival reports</a>.
  Using DNSMasq to run an overlapping DNS Zone might seem like a good political decision at the time, migrating off of that and resolving the disparity to between your DNS Zone and the overlapping upstream zone a few years later turns into a nightmare.
  <br>
  <br></p></li>
  <li><p>Expense</p>
  
  <p>Technology can be expensive. Buying a solution only to discard it later cares with it hugely wastful expenses. But even more expensive is the time expended by personnel. Salaries are every companies' largest expense. Wasting time developing a solution only to discard it and develop a replacement is wildly inefficient.</p></li>
  </ol>
  
  <p>This however should not be construed to mean that <a href="https://xkcd.com/1801/" rel="nofollow noreferrer">decision paralysis</a> or analysis paralysis isn't a problem. It is! Fail-fast just isn't the best way to <a href="https://en.wikipedia.org/wiki/Analysis_paralysis#Preventing_and_overcoming" rel="nofollow noreferrer">combat it. There are other, much more tried and true ways to combat this without comprimising good design principles.</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-01T22:09:59.297Z
Answers: Limited time POCs doesn't cover future issues & due to the process of open-bid, the cheapest solution is the chosen one. An open bid process could lead to technical debt anyway. to satisfy open bid, the low denominator of the requirements are specified not the ideal optimum ones the ones that solve today's problem in the future. the optimal is to solve future problems today. as for buying a solution, we can start working with the upstream opensource version first to get accustomed and learn more about it. the initial steps of decision making. no need to rush into enterprise paid solution.
Answers: Walid
Answers: CC BY-SA 4.0
Answers: 2018-06-01T15:31:31.437Z
Answers: 2018-06-01T15:31:31.437Z
Answers: James Shewey
Answers: <p>I believe in 'fail fast' but it's also important to tackle understanding an opportunity in the right way.</p>
  
  <p>If you come up with an idea, code in a vacuum for a bit, then release it to people, you will undoubtedly fail fast, but not in a way you would like.
  A better approach is if you come up with an idea, clearly articulate your hypotheses on why you think it's a great idea, then validate that idea with potential clients to see what <strong>they</strong> think. This will give you a great opportunity to clarify the idea, refine it, and possibly reject it outright. </p>
  
  <p>I never cease to be amazed at how much my initial idea improves from just a little collaboration with people that I would want to 'sell' it to. And - to be honest, I've discovered why many of my ideas really weren't all that great - and shelved them fast (before any code was written often).</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-05T21:32:57.580Z
Answers: 2018-06-05T21:32:57.580Z
Answers: mike
Body: <p>I am trying to convince my fellow workers and management as part of DevOps transformation to adopt "fail fast" in almost everything. Amazon has two principles "bias for action" &amp; "are right a lot" which I belive are quite similar. my dilemma is espically when adopting a new solution. as an Enterprise, they tend to evaluate several products first, then run many proofs of concepts, then an open bid. which is a waste of time and resources. my take is that decide on one solution quickly based on technical and financial merits, start using it if you fail, you can select another technology, reversing a decision on technology is not a big deal, isn't DevOps about being Agile and having quick feedback loops? I would like to hear your input.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-06-01T04:02:49.103Z
Comments: "run many proofs of concepts" this seems to go into the right direction but not the way you would prefer? I am not sure what to answer yet, but in general I think this is question of culture; I am thinking of the Three Ways and maybe you could shape your answer towards a specific situation?
Comments: Ta Mu
Comments: CC BY-SA 4.0
Comments: 2018-06-01T08:10:43.063Z
Comments: Yeah, sign a 3 year contract for dozen of bucks each year and decide after 3 month it is not a good solution... Does it ring a bell of why it could be a bad approach ?
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-01T18:47:46.807Z
Comments: @Tensibai you do not have to start with the enterprise solution,  most solutions now days have an upstream open source solution
Comments: Walid
Comments: CC BY-SA 4.0
Comments: 2018-06-01T18:52:43.833Z
Comments: @PeterMuryshkin take an example of PaaS, one can evaluate Openshift, Rancher, Docker EE, Xebialabs, or raw kubernetes with several add-ons. or just set mind to start using one and in his on-going learning journy can find the limitations and check if other solutions suffer from the same limitation, or they can be resolved in chosen platform, why spend time in several POCs while time can be invested in getting things done.
Comments: Walid
Comments: CC BY-SA 4.0
Comments: 2018-06-02T06:28:13.493Z
Comments: @walid you're asking a different question then. When describing an open bid as end of process, free OSS was out of context for the question for me.
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-02T12:16:41.850Z
Comments: @Tensibai I value your input, I know I might be wrong in generalizing "Fail fast" on all processes, however, the evaluation of new technology with the intent of adopting it via POC, open bid is one use case. another use case is adopting an OSS e.g. configuration management/deployment framework. there is a tendency in the enterprise to not settle fast on one technology/tools unless several have been evaluated.
Comments: Walid
Comments: CC BY-SA 4.0
Comments: 2018-06-02T16:54:19.020Z
Comments: And there's reason for that, just the salary of people taking the learning curve of a technology is a large cost, you'd better know if the tech will last more than a few month, fail fast is for trying ideas/implementation , not technologies as far as I know
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-02T19:48:28.490Z
Comments: @Tensibai agree, one use case is Pivotal vs. Openshift. as far I can see both are mature technologies and can provide the same requirements. it's actually a waste of resources and high salaries to not make a fast decision, I am saying to think long term, I am also saying, we have so many technologies that are mature with minor differences or strategies that are well known. I can see that I should not generalize. thank you for your input.
Comments: Walid
Tags: <project-management><agile><practices>
Title: what do you think of making fast decisions?
UserDisplayName: Walid
ThreadText: # what do you think of making fast decisions?
  
  (Asked by: username_0 on 2018-05-31)
  
  I am trying to convince my fellow workers and management as part of DevOps transformation to adopt "fail fast" in almost everything. Amazon has two principles "bias for action" & "are right a lot" which I belive are quite similar. my dilemma is espically when adopting a new solution. as an Enterprise, they tend to evaluate several products first, then run many proofs of concepts, then an open bid. which is a waste of time and resources. my take is that decide on one solution quickly based on technical and financial merits, start using it if you fail, you can select another technology, reversing a decision on technology is not a big deal, isn't DevOps about being Agile and having quick feedback loops? I would like to hear your input.
  
  **Tags:** project-management, agile, practices
  
  > **Comments:**
  > **username_1**: "run many proofs of concepts" this seems to go into the right direction but not the way you would prefer? I am not sure what to answer yet, but in general I think this is question of culture; I am thinking of the Three Ways and maybe you could shape your answer towards a specific situation?  
  > **username_2**: Yeah, sign a 3 year contract for dozen of bucks each year and decide after 3 month it is not a good solution... Does it ring a bell of why it could be a bad approach ?  
  > **username_0**: @username_2 you do not have to start with the enterprise solution,  most solutions now days have an upstream open source solution  
  > **username_0**: @PeterMuryshkin take an example of PaaS, one can evaluate Openshift, Rancher, Docker EE, Xebialabs, or raw kubernetes with several add-ons. or just set mind to start using one and in his on-going learning journy can find the limitations and check if other solutions suffer from the same limitation, or they can be resolved in chosen platform, why spend time in several POCs while time can be invested in getting things done.  
  > **username_2**: @username_0 you're asking a different question then. When describing an open bid as end of process, free OSS was out of context for the question for me.  
  > **username_0**: @username_2 I value your input, I know I might be wrong in generalizing "Fail fast" on all processes, however, the evaluation of new technology with the intent of adopting it via POC, open bid is one use case. another use case is adopting an OSS e.g. configuration management/deployment framework. there is a tendency in the enterprise to not settle fast on one technology/tools unless several have been evaluated.  
  > **username_2**: And there's reason for that, just the salary of people taking the learning curve of a technology is a large cost, you'd better know if the tech will last more than a few month, fail fast is for trying ideas/implementation , not technologies as far as I know  
  > **username_0**: @username_2 agree, one use case is Pivotal vs. Openshift. as far I can see both are mature technologies and can provide the same requirements. it's actually a waste of resources and high salaries to not make a fast decision, I am saying to think long term, I am also saying, we have so many technologies that are mature with minor differences or strategies that are well known. I can see that I should not generalize. thank you for your input.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2018-06-01. Score: 4
  
  > start using it if you fail, you can select another technology
  
  This approach has two major drawbacks:
  
  1. [Technical debt](https://en.wikipedia.org/wiki/Technical_debt)
  
     While it may be tempting to apply "fail fast" mentality to architecture and design, skipping or abbreviating the design phase would be a mistake. [fast-fail](https://en.wikipedia.org/wiki/Fail-fast) should be used in conjunction with good design practices, not in lieu of them. Making hasty decisions can often result in poorly scaled solutions. While [using MySQL seems like a good idea when you are working with a 100mb database to generate reports, it scales poorly into the terabyt range for doing your archival reports](https://devops.stackexchange.com/a/1220/2845).
     Using DNSMasq to run an overlapping DNS Zone might seem like a good political decision at the time, migrating off of that and resolving the disparity to between your DNS Zone and the overlapping upstream zone a few years later turns into a nightmare.
  2. Expense
  
     Technology can be expensive. Buying a solution only to discard it later cares with it hugely wastful expenses. But even more expensive is the time expended by personnel. Salaries are every companies' largest expense. Wasting time developing a solution only to discard it and develop a replacement is wildly inefficient.
  
  This however should not be construed to mean that [decision paralysis](https://xkcd.com/1801/) or analysis paralysis isn't a problem. It is! Fail-fast just isn't the best way to [combat it. There are other, much more tried and true ways to combat this without comprimising good design principles.](https://en.wikipedia.org/wiki/Analysis_paralysis#Preventing_and_overcoming)
  
  > **Comments:**
  > **username_0**: Limited time POCs doesn't cover future issues & due to the process of open-bid, the cheapest solution is the chosen one. An open bid process could lead to technical debt anyway. to satisfy open bid, the low denominator of the requirements are specified not the ideal optimum ones the ones that solve today's problem in the future. the optimal is to solve future problems today. as for buying a solution, we can start working with the upstream opensource version first to get accustomed and learn more about it. the initial steps of decision making. no need to rush into enterprise paid solution.  
  
  ---
  
  ### Answer by username_4 on 2018-06-05. Score: 2
  
  I believe in 'fail fast' but it's also important to tackle understanding an opportunity in the right way.
  
  If you come up with an idea, code in a vacuum for a bit, then release it to people, you will undoubtedly fail fast, but not in a way you would like.
  A better approach is if you come up with an idea, clearly articulate your hypotheses on why you think it's a great idea, then validate that idea with potential clients to see what **they** think. This will give you a great opportunity to clarify the idea, refine it, and possibly reject it outright.
  
  I never cease to be amazed at how much my initial idea improves from just a little collaboration with people that I would want to 'sell' it to. And - to be honest, I've discovered why many of my ideas really weren't all that great - and shelved them fast (before any code was written often).
  
  
  ---
  
  