jasoncwarner
commented
4 years ago The good way: Explicit decision making
The bad way: Implicit decision making
Sometimes tech "just happens" in an org because someone or a team wanted to use something or needed to use something for some reason, many of those reasons appropriate. However, the very real cost of putting non-mainstream tech in production often time outlasts the person, the team or even the tech's usefulness and becomes a cultural or business drag.
The way to avoid this is to actively discuss how it will be handled.
The best way I've seen this done is across multiple companies is to intentionally choose a set of tools and tech that are allowed to go into production. More, the even better way is to have mechanisms and tooling that keeps this so.
And, a few base things have to be answered that all tech and products have before going to production. This includes:
Who owns this? Who is on call for this? What are the production incident runbooks/playbooks? What is the rollout plan? Roll back plan? Is this is intended to be permanent or an experiment? etc
There are others though the biggest things to consider is 1. who owns it 2. experiment or non-experiment (they have different paths and decision making criteria) 3. criticality to business.
We didn't talk about #3 yet though releasing brand new, esoteric tech (think we are a Java company about to release a completely new Rails stack product) the reason to use NEWSTACK should be pretty clear and have some pretty clear business advantages to them. The most obvious cases are when the tech does a super specific thing very well (Semantic, which you cited, is a good example of that).
I've also seen a council of folks (cross functional engineering group) who minds after the various stacks and makes sure when something new is requested to production, they weigh in. Think something similar to hiring committee but for tech. This also can work pretty well. Certainly can for certain stage and size companies.
Hello Jason!
https://github.com/github/semantic stands out among the repos in GitHub organization. I wonder what was the process of adopting Haskell for a project?
Did you require that some number of developers commit to supporting it to have a reasonable Bus Factor?
Were there some technical requirements like "must be able to send metrics and logs to our preferred monitoring system"?
Was there some "probation period" where a team had to deliver an MVP and based on the project would go forward or not?
If semantic is a success story for a non-mainstream tech, are there failure stories you could share?
Any concerns about hiring for such projects?
Thank you for your time.