How Armory Builds Products

Jan 16, 2020 by Andrew Backes

There are two primary approaches to developing and delivering software products. The first is to spend a long time building a product for end users before releasing it and seeking feedback, and optimizing for traditional engineering standards like reliability, scalability, and quality along the way.The second approach is the one Armory embraces: getting a product into our customer’s hands as quickly as possible so we can rapidly get feedback and iterate based on that feedback. As a startup, we have to optimize for speed. We are nimble, responsive and conscious of our resources. Our philosophy is to optimize for speed: ‘build the right thing fast, instead of the wrong thing, right.’ Our rapid feedback and iteration loops enable us to quickly assess and determine whether we are developing the right product with the right features, for the right customers. Once we have confirmed that a product or feature satisfies a market need, we improve on it by optimizing for those traditional engineering standards.The Iterative Process and Spinnaker

Armory is commercializing Spinnaker, a cloud-native continuous delivery orchestration platform created and open-sourced by Netflix and Google to codify and standardize software delivery pipelines to multicloud targets. With much of the world’s software still deployed to data centers, customers adopting Spinnaker are market leaders. They are critical in defining the features that will be broadly applicable as the rest of the market moves towards cloud (and Spinnaker!) migration.

These customers need a set of lightweight minimum viable product (MVP) features they can deploy and test, in turn giving Armory feedback and guidance on how best to commercialize Spinnaker. Our approach of rapidly releasing, iterating on, and then improving on features helps us validate (or invalidate) these features. We are learning alongside our customers and improving Armory Spinnaker on a near-daily basis.

As we build Armory Spinnaker, we are discovering the acceleration and unblocking features that make continuous delivery even more powerful for our current customers. Customers that adopt Spinnaker later in the market process will benefit from our early innovations. And, we’ll continue to discover features with our early innovators that will benefit later adopters. We’ll stay ahead of the Spinnaker flywheel with this iterative approach to building and releasing products and features.

As we learn what the market leaders need – and as our early users and adopters implement it – our engineers return to the proven product and feature set and refactor them for optimal commercial engineering practices. We refactor the code for scalability, readability for internal maintenance, diagnostic capture, documentation, quality and readability.

First, we build the right thing quickly, and then we go back and build the right thing robustly.

The ‘Perfectionist’ Bug

Building the ‘right thing’ iteratively is ultimately more fulfilling than building a perfect thing without feedback. You know you’re building something that users will ultimately use extensively, and that solves true customer needs.

While this may make sense logically, there’s a natural tendency for engineers to trend towards an inherent perfectionism. As engineers, we want to build a perfect product with perfect code. At Armory, we like to remind our engineers of a reality: you will (and can) never build the ‘perfect thing.’ It will always get better based on feedback from users and based on improvements in the tools and techniques in the market.

If you spend an extra ‘x’ period of time trying to build a perfect product for your users, you could have spent that same ‘x’ period of time getting valuable user feedback to iterate on that product. Using that feedback and making the product more useful to your end user enables you to leapfrog what you would have otherwise labored over in a black box of development. Making the product more useful also means it’s more likely to be used widely by those customers.

Armory believes it’s important to start talking about this inherent tendency towards perfection and moving towards coding and building products based on a constant feedback loop from actual users. This doesn’t mean we encourage sloppy coding or development practices. It means we focus on taking the first step and getting something into our customer’s hands. We encourage our engineers to get comfortable building (and releasing) MVP’s, and coming back later to improve on it if it turns out to be headed in the right direction. We consider everything in this process as a stepping stone to something that fulfills a customer need, one that is ‘right enough’ until we get the next round of feedback and make the next set of tweaks.

Armory’s Process: A Feature Example

One of Armory Spinnaker’s most powerful features is pipelines as code. As we built out the features and released the MVP, we were surprised to find that some of our assumptions about why and how customers would use pipelines as code were wrong. Customer feedback drove iteration and also a deeper understanding of the use cases and context for this feature.

Our intention in building pipelines as code was from the perspective of supporting a golden path for infrastructure. We knew that customers wanted (and needed) example pipelines that could be copied and used as building blocks across the organization.

We were surprised and delighted to find that customers immediately began leveraging the pipelines as code feature as a conduit to other use cases. They began using pipelines as code in very modular ways. For example, customers began using the feature to determine who controlled or owned code modules and as building blocks within Spinnaker.

We were also excited when customers began using pipeline as code modules for managed, declarative delivery. This led us to add managed delivery to our product roadmap and work with customers on use cases in this area. We thought we were solving a specific infrastructure challenge. Customer feedback led us to a wide variety of additional use cases that has broadened the value of this feature set. Imagine if we had narrowly built the pipelines as code feature with no customer input – we would have missed valuable customer guidance and context for many additional uses and areas of applicability!

Build the Right Thing Fast

Our approach to building products mirrors our approach to many things – our company culture, how we respond to market trends, and our contributions to the Spinnaker community. We believe that listening closely to customers, our Armory tribe, and the broader Spinnaker community enables us to contribute the highest value and supports the growth of Spinnaker.

Intrigued by our approach to building products? We’re hiring!

Recently Published Posts

3 Common Spinnaker Challenges (and Easy Ways to Solve Them)

Sep 27, 2022

Spinnaker is the most powerful continuous delivery tool on the market.  DevOps engineers and developers recognize this power and are looking to use Spinnaker as a foundational tool in their Continuous Integration and Continuous Delivery (CI/CD) process for hybrid and multi-cloud deployments. Such a powerful, expansive open source tool needs expertise within your organization to […]

Read more

Streamline Advanced Kubernetes Deployments from GitHub Actions with New Armory Service

Sep 23, 2022

Today, Armory is excited to announce the availability of the GitHub Action for Armory Continuous Deployment-as-a-Service. GitHub is where developers shape the future of software. After a developer writes and tests their code in GitHub, it must be deployed. Armory’s GitHub Action for Continuous Deployment-as-a-Service extends the best-in-class deployment capabilities to Kubernetes. CD-as-a-Service enables declarative […]

Read more

When everyone is facing the same headwind, go on the offensive

Sep 12, 2022

Call me Pollyanna, but what a great time to be a Platform or DevOps engineer. If you’re working in a public company, the S&P is off ~20% year over year, so the value of your RSUs has wilted. If you’re working in a private company, venture funding and M&A velocity are anemic, making expansion capital […]

Read more