| title | description |
|---|---|
Technology choices |
How to make technology decisions at Artsy |
High-level architecture and technology choices are some of the most important and carefully considered decisions we make as engineers. This document describes how we make decisions, including:
- A radar for capturing current technology preferences and
- Technical plans and reviews for adjusting those preferences or making other significant technology decisions
We want to accomplish a lot with a lean team, which means we must choose stable technologies. However, we also want to adopt best-of-breed technologies or best-suited tools, which may need work or still be evolving. We've borrowed from ThoughtWorks' Radar to define the following stages for evaluating, adopting, and retiring technologies:
- Adopt: Reasonable defaults for most work. These choices have been exercised successfully in production at Artsy and there is a critical mass of engineers comfortable working with them.
- Trial: These technologies are being evaluated in limited production circumstances. We don't have enough production experience to recommend them for high-risk or business-critical use cases, but they may be worth consideration if your project seems like a fit.
- Assess: Technologies we are interested in and maybe even built proofs-of-concept for, but haven't yet trialed in production.
- Hold: Based on our experience, these technologies should be avoided. We've found them to be flawed, immature, or simply supplanted by better alternatives. In some cases these remain in legacy production uses, but we should take every opportunity to retire or migrate away.
Artsy's current choices can be edited in raw form here and viewed in radar format here.
See this document for more information on technical planning.
It sure is!
Sounds like it should be assessed. Go ahead and add it (via pull request) to the radar. This is also a great time for spikes or proofs-of-concept.
Propose a technical plan for how this choice could be trialed in production. Clarify the goals and potential benefits of the trial. If replacing an alternative, consider whether we would consolidate on the new choice (and how) or support multiple approaches. Specify a target timeline for deciding about the trial either way. Avoid trialing multiple unproven things in the same project or system.
Congrats! Is there a critical mass of engineers (>=3) comfortable working with this tech? If so, consider a Knowledge Share
or practice meeting discussion to review your experience and share any lessons. Make a pull request to the
radar and make sure to request comments from the relevant engineers or experts. Remember that it may not be
sufficient to just "adopt" a new choice. If this replaces an alternative that's in place at Artsy, that should
probably move to "hold" and a strategy be decided for migrating away from the old tech (e.g., opportunistically or
deliberately).
Use your judgment. Minor dependency selections may not warrant broad input. If a library or approach influences how future code will be written or how other developers will work, though, it's often worth a time-out to consider competing options, get feedback, choose deliberately, and document the choice.
As above, if the new project will affect developers' work or employ technology that's not "adopted," a technical plan is recommended. In all cases, lean on our other documentation and communication practices like:
- Ensure the README provides necessary context
- Share new repositories in open stand-up
- Add new projects to the project list 🔒 and specify which team will support them.
RFCs or Requests for Comments are ideal for discussing changes to how we work as engineers. Technical plans are better for considering technical approaches and technology or tool choices. You can't go wrong, though! Both ensure we discuss in the open and record our thinking.