patternMinor
what do you think of making fast decisions?
Viewed 0 times
fastyouwhatdecisionsmakingthink
Problem
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.
Solution
start using it if you fail, you can select another technology
This approach has two major drawbacks:
-
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 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.
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.
-
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 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.
This approach has two major drawbacks:
-
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 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.
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.
-
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 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.
Context
StackExchange DevOps Q#4213, answer score: 4
Revisions (0)
No revisions yet.