There is one certainty in writing software and that is “there are 100 ways to solve the same problem”. Usually, in this context, we are talking about architecture and when we talk about architecture we inevitably talk about tech stack. First, let’s define “tech stack”:
Tech Stack - /tek/ /stak/
The chosen programming languages, frameworks, and third-party services that are used to build and run a software application.
At Airship, we build custom software applications tailored to your specific needs. There is a responsibility that comes along with the trust our clients give to us. It is to ensure that the tools we are using to solve their problems are the right ones at the time of solving. We have a checklist in place to determine if a new technology should make its way into our tech stack so that we are stewarding that trust well.
Here are the 9 categories in which we assess whether a technology and/or process is used in the solutions that we build:
The Airship Tech Rubric
Community Size
Software is a living, breathing thing. As with all living things, it hiccups, and when it hiccups, it’s really great to lean on others to help get rid of them. A large community behind a technology breeds trust and allows teams to move faster because there’s likely someone that’s seen that hiccup before and gives you helpful information. Not only that, community size is a great measurement of a technology's maturity as well.
Maturity
When choosing a technology, do you want it to be able to run or still be learning to walk? The longer a technology is in the world the more it’s learned to step over the cracks without tripping and been battle-tested in large applications. We do not use our client’s time and money to learn fresh new things, they trust us to use technologies that can stand the test of time. We typically let 6 months go by at least before we assess the trajectory of new technology.
Bugs/Issues Count
Open Source Software (OSS) is an amazing gift to the community. Many people spend their personal time creating tools and technologies to help build products easier. While not a metric that takes a technology out of the running, it’s important to have a pulse on the number of issues that are occurring. The types of issues that people are seeing, and identifying how quickly fixes for issues are resolved.
Last Commit Date
Along with an OSS’ bug/issue count size and process, it’s important to see how active development is in regards to new enhancements and features of a technology. There are thousands of libraries that provide similar paths to solving specific challenges but it’s important that those libraries are also keeping up with the times. The last commit date of an OSS repository can shine a light on a supernova or a dying star.
Licensing Restrictions
Important and can be detrimental is overlooked is the licenses attached to OSS. Understanding how you are allowed to use a library and what requirements, if any, the creators ask you to abide by. We look for MIT licenses as those are the least restrictive and allow you to do whatever you wish with the code.
Cost of Use
Not all software is open source. There are hundreds of products that are available that add superpowers to software applications. Understandably, these products charge for their use. Understanding the long-term costs, what can affect those costs, and ensuring that we set proper expectations with our clients around these costs is of ample importance.
Compatibility
If you’ve tried to run React Native (among other technologies) on an M1 Mac then you’ve likely run into compatibility issues that took some time to understand and fix. This is normal but also distracting and could lead to missed expectations if they sneak up on you. This is a guidance metric that makes us intentionally look for potential issues and have an understanding of them ahead of development so we can set proper expectations with our teams and clients.
Documentation
(aka the recipe for success)
Have you ever tried to bake a cake with a recipe that looks like this?
- Get eggs
- Get flour
- Mix together
- Put in oven
- Eat
Of course not! I am not sure what inedible mess would come out of the oven in this scenario but I assure you it wouldn’t be pretty and likely would not look like what you expected. Documentation within a library is much like a recipe for success. It brings clarity around installing a technology, how to use the technology, and what’s happening under the cover to ensure when you’re baking an authentication system, that that’s what you pull out of the proverbial oven. Great documentation can be the difference in hours vs weeks of work and/or rework.
Side note, OSS is typically maintained by individuals with full-time jobs just like you. If you find a chance to add to the documentation to make the next person’s life easier, I suggest you do so. It follows the Cub Scout rule and you can say “I’ve contributed to that library” 😁
Developer Experience
Airship is very very good at the technologies we bring into our tech radar center ring. These technologies are battle-tested and can be used to build ANY software application experience. In almost all cases, we use Ruby on Rails, React, NextJS, and React Native together to deliver amazing customer software applications to our clients and their stakeholders. These technologies allow us to move fast while also ensuring we deliver a quality solution that meets your needs. As we continue to bring more technologies into our center ring, we hold the developer experience expectations as high as these 3 stacks. A solid developer experience can be the difference between days and months of work.
You may be asking yourself, with all of these metrics how does Airship ensure it’s staying on the cutting edge of new technologies that have a trajectory of changing the industry? Much like the process we use to move technologies closer to our core competencies, we also have a process to test new technologies that don’t impact the excellence we deliver to our clients. But, that’s another blog post 😉!
We’d love to hear how you determine when it’s right to use a technology. If you don’t have a process for this, feel free to bring the Airship Tech Rubric into your organization. It’s aimed to help us serve you better but also to ensure we are in alignment with your goals as an organization. If you want to dig deeper, feel free to reach out!
