Created
February 9, 2018 03:00
-
-
Save mcfunley/094a7bf94d4d7b500c0f854d74fdc706 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Regarding HBase/Redis I've been extracting what I think of as our | |
process for adding new technology to the stack. I don't want to | |
create the perception of checklist that if folks jump through the | |
hoops somehow there is magically a new tech in the stack, but it also | |
shouldn't be totally undocumented. | |
This is a draft. Y'all are the first folks to see this, so feel free | |
to poke holes. | |
1. What problem are we trying to solve? (Technology should never be | |
introduced as an end to itself) | |
2. How could we solve the problem with our current tech stack? (If | |
the answer is we can't, then we probably haven't thought about the | |
problem deeply enough) | |
3. Are we clear on what new costs we're taking on with the new | |
technology? (monitoring, training, cognitive load, etc) | |
4. What about our current stack makings solving this problem in a | |
cost-effective manner (in terms of $$ and people) difficult? | |
5. If this new tech is a replacement for something we currently do, | |
are we committed to moving everything to this new technology in the | |
future? Or are we proliferating new technologies for specific tasks? | |
6. Who do we know and trust who uses this tech? Have we talked to | |
them about it? What did they say about it? | |
7. What's a low risk way to get started? | |
8. At each step get together a mixed discipline group of senior | |
enginners (but not just snr-engs) and thrash out the point. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment