Posted on by Rowan Manning.
We recently sent out an internal survey titled “Origami Survey: Building Components”. The survey was designed to gather some quantititive data from our users, and the aim was to help us understand the barriers that teams have to developing their own Origami (or Origami-compatible) components. We sent the survey to engineers, and indicated that we were interested in responses from engineers of all seniorities and levels of experience with Origami.
After two weeks, we had 27 responses from different groups within Product and Technology. This post will explore some of the results, and what we can learn from them. (Bear in mind that while great that we’ve got this many responses, we should be wary of drawing too many conclusions from 27 out of all the engineers in Product and Technology).
To help segment the data, we asked each respondent which area of Product and Technology they worked in, as well as asking them to self-report their level of familiarity with using Origami components.
We’d like to say a big thanks to everyone who filled out the survey 🙂
We asked the question “How familiar are you with using Origami components?”, and asked respondents to mark themselves 1 (What are origami components?) to 5 (I’m an expert). Most people responded with 3 or 4:
|Enterprise Services and Security||1||1||2||0||0|
|FT Group Products||0||1||0||0||0|
|Operations and Reliability||0||1||0||1||1|
When you filter this by the area that the person works in, you can see that the groups who have been using Origami for the longest (Customer Products, Internal Products) generally self-report as having more experience.
We asked the question “Did you know that any engineer can create an Origami component?”, and asked respondents to answer yes or no. There ended up being a roughly 50/50 split:
When you filter this by the area that the person works in, you can see that Customer Products leans more towards “Yes” as an answer. This aligns with some of our assumptions, as Customer Products have some of their own shared components.
We also asked “Have you ever built or contributed to an Origami component?”, and gave respondents the ability to indicate whether they’ve either built a component, contributed to a component, or both. The vast majority of respondents have neither built nor contributed to the development of a component:
|Built a component||2|
|Contributed to a component||3|
To get an idea of how people are building their front ends, we asked “If there isn’t an Origami component that suits your needs, how do you build that part of your website?”, and gave respondents the ability to select multiple options from the following, or provide their own response:
Ignoring responses of “Other” for now, the results look like this. You can see that in the majority of cases, if an Origami component is not available then front-end code gets built directly into people’s application codebase:
|Area||We build and use our own Origami components||We build and use our own reusable non-Origami components, which are used across multiple applications||We build it directly into our application codebase||We never need anything other than Origami components||We use third-party libraries and components|
|Enterprise Services and Security||0||0||2||0||3|
|FT Group Products||0||0||0||0||0|
|Operations and Reliability||0||0||3||0||1|
The “Other” responses to this question are as follows:
We can see that very few people build Origami-compatible components outside of the Origami team. Engineers are also more likely to use third-party code than build their own reusable components.
We also got a lot of useful responses in free-text fields at the end of the survey. We’ll be reading and understanding these over the next few weeks. We’ll keep you posted on any work that we decide to do based on the results of this survey.
The Origami team