More often than not, we evaluate people based on their skills. How competent they are, how relevant their experience is, what technologies they use.
Especially in the tech industry, we believe that growing our skills will prepare us to deliver better results. I also believe that having the right skills is the best way to do an excellent job.
But it shouldn’t stop here.
Skills and gear
If you’ve ever played an RPG, you would know that besides skills, you should have very good gear. I think this applies to our day-to-day life as well. The gear plays an important part in success, as we can see now in the fast digitalization of some industries.
When I think about the gear of a fighter I remember the APU from Matrix and I wonder what type of questions did the builders of that machine have. What did they prioritize when creating it? Was it flexibility or durability, speed or endurance?
Building Ivory is our attempt to have the best gear possible. Our goal is to not be limited by what’s considered to be the best in the market right now. We want to ask our own questions and come up with the best solutions for us, while still using what’s best in the market.
Read this first: Meet Ivory - our highly opinionated acceleration framework
Asking the right questions when building something
If you want to make a great tool, you have to make sure that the tool will be used. A lot.
At the moment, we’re trying to find a balance between “just make it work so developers will use it and it gets traction” and “it will be nice and shiny and our developers will love it”. If it takes too much time to make it work or if it contains too many new things, it may be too complicated for it to be used in a new project. Especially for a new project that should have started much earlier and should be ready by tomorrow (if you’ve worked with many startups, this might ring a bell).
The questions we’re trying to answer right now are:
- How many days (or hours) would it take for a developer to create the setup of a new project?
- How many weeks until the team deliver unique features?
- What if they used Ivory?
- Will it be too complicated for a new developer to understand the folder structure and the conventions to just use it properly (and avoid making a mess)?
How is Ivory a developer-centric framework?
I can explain it best with some examples.
1. To yarn or not to yarn
When we looked up yarn2, we initially thought it would be an awesome addition to the innovation that Ivory is looking to bring about. Later on, we realized it would have been too big of a change to go with yarn2 and it would have required developers to dedicate more time learning to use that tool as well. In the end, we decided to go with yarn instead of npm (which may still be a change for some developers, but not as big as yarn2).
Why yarn and not npm? That’s a question we asked ourselves as well. Would this be a difficult switch for developers using Ivory? Our answer was “No”. However, we made a note to come back to this question and include an —use-npm option later on.
2. Integrations
Every time we’re looking at adding or integrating something new, we ask ourselves: “What would be the developer experience of someone using this?” With the answer to that question, we included i18n for translations and adapted them in a way that’s easy to use, intuitive, and that also covers most use-cases.
Next, we asked ourselves: “Is this new tool that we want to integrate into Ivory powerful enough to cover most products’ needs? Is it simple enough that developers can just use it? Are we already using this in our own projects?"
While answering those questions, we built Ivory to include not only AWS Amplify (at its core) but also MaterialUi, react-hook-form, i18n, and Cypress. We also included examples of how to use them.
For our first release, we planned to include the auth module from AWS Amplify, with predefined options. Because Amplify doesn’t have a headless version of running the add auth command, we thought that it would be enough to include instructions in the README file.
Feeling like we couldn’t just leave it at that, we went the extra mile and researched a way for doing this automatically so that a developer would not have to worry about which options to pick (they’re already chosen by Ivory’s CLI).
3. Testing
In the last days before releasing version 1, we performed tests of the entire flow of creating a new app, to make sure it works, with all the options the developer can choose. It was a tedious process mainly because we had to wait several minutes just to find out that we needed to make one small tweak. Then we would test it all over again. But it was worth it.
4. Feedback
After we had our first version of the tool we asked more developers to try it out while taking notes of their experience using it.
If you're interested in finding out more, we recently launched the first version of Ivory.io.
npm install ivory and in less then 30 minutes you can create a fully-functional single-page web application built with React, with an AWS Amplify serverless (Dynamo and Lambda) backend, a fully-configured build pipeline and user acceptance tests; all provisioned with infrastructure as code.