I’ve been thinking about the needs of decisions (technical or design) to translate across the self, the team, and the organization. On any project I belong to each of those “bodies” simultaneously. Choices I make needs to cascade across each context. One such decision I’ve been mulling is the option to employ a JS framework for a client’s site.
From a wider front-end team sensibility, urgent demands and quick fixes mean the quality of the original Vanilla JS degrades quickly over a short period of time. With multiple teams (in-house, remote, and offshore) adding code to support more scenarios and workarounds, it’s unsustainable to nitpick each line of code. I don’t see the urgent demands subsiding soon. We need a system. As much as it pains my puritan heart, a framework seems like it could be the best possible solution.
A framework gives structure and conventions. Abide in the pre-agreed upon conventions and things should go well. Frameworks come with prefab open source solutions too which are basically free solutions. Need a modal? Install
react-modal, it might be 81kb but it gzips away don’t worry, let’s move fast. Reducing the code we write reduces our surface area for potential bugs.
Small teams have a bit more freedom to switch tooling up as needed. The level of effort is fairly small as well; a few quick conversations, tell everyone to re-pull and
npm install, update a readme, start a Slack channel for support. Easy. It’s great if decision can stop at this level.
For some decisions, it’s important to consider how this change effects the entire organization. Do your changes scale? Do technical changes or design changes create unnecessary workloads and process burdens? Is DevOps aware? Is marketing? QA? Legal? Does this break A/B Testing? Who is responsible for communicating the framework switch to offshore? Does offshore even know React? Are the Java devs who end up writing front-end code going to adopt the new framework? What is the actual cost in meetings of on-boarding other teams to this new thing?
I’m seeing technology and design choices as a mixture of compromises between these three questions; what can I do, what’s possible as a team, and what’s possible as an organization. It’s a lot to consider and I probably spend too much time thinking about it, but I’ve spent a lot of my life debugging various “solutions” that actually create more problems and were poorly designed, thought about, or implemented.