Ship Often or Big-Bang Rewrite?

In this thought leader Insight, the VP of Engineering at IronNet Cybersecurity, Michael Hans, explains his take on code deployments, tech stacks, and building a great product.

Managing the timing and frequency of a code deployment is often difficult, due to the scope of work involved. Engineering and product teams may wonder if it’s better to deliver small changes frequently or opt for a long-term massive change (i.e. a big-bang rewrite).

There’s no method that’s guaranteed to bring every team success for every product they ship, but it’s helpful to hear from the perspective of those who have succeeded in this area.

We interviewed Michael Hans, the VP of Engineering at IronNet Cybersecurity, to gain his perspective.

Michael’s professional background spans a wide range of companies, from a 10 person pre-series A funded startup to a global management consulting firm. Experience in these different company cultures has resulted in a unique technical and managerial view on product development. He is a firm believer in the idea that great products are driven by quantitative and qualitative feedback, as well as a culture that embraces shipping software and hardware.

The conversation below has been edited for length and content.


You mentioned that you prefer the “ship often” method over “big-bang” rewrites. Can you share more about this method?

Many startups begin in a similar position. They start building a product and it becomes a Minimum Viable Product (MVP). As they receive feedback, they add more and more features causing them to stray from where they architecturally thought they would be.

At that point, it’s appealing for the development team to completely rewrite these pieces. They may want to start with a clean slate since they’ve gained knowledge throughout the process and would write things differently now.

But it’s important to realize that anytime you write new code, you’ll encounter new bugs and will receive more feedback from that MVP.

At IronNet, we always try to keep a very tight feedback loop. This means that we deploy often and try to stay away from a big-bang rewrite that takes months.

If there’s a database that no longer performs as needed, then we would choose to rewrite components and incrementally ship them out rather than rewriting everything.


Stay Up-to-Date on DC Tech Trends

Why do you prefer this approach of “ship often”?

You can often judge the health of your engineering organization by the frequency that they deploy.

If a deployment takes a long time and involves too many people and manual levers, then perhaps there needs to be a shift in the way the team operates. On the other hand, if a deployment happens quickly it reveals a team that can collaborate and work efficiently.

Whether you wait to deploy in six days or six months, you rarely get it 100% right. If I wait for the longer deployment, I may end up discovering that all the little issues evolved into a big monster. I’ll still have bugs if I choose the short deployment, but they tend to be smaller and are easily traced back to the source.


How does your team practically implement the “ship often” method?

At IronNet, we are constantly receiving feedback about what changes should be made. Our stack has a high level of observability, we collect a massive amount of information from our services. We have to keep these observational points on the front burner.

As we collect feedback, either from the product or from customers, we discover where changes need to be made. Sometimes the feedback reveals the need to change an interface or a specific component. Other times, the feedback reveals that a component is no longer needed which allows us to get rid of it.

We also start the process of making small changes, by frequently asking “where do you want to be in 6 months?” From that question, we break down the long-term goal into small pieces.

For our team, most code changes come from either that constant data collection or from the check-ins about our long-term goals.


Can you tell us about your company’s product?

Behavioral Analytics! The main idea behind our product, IronDefense, is that a company can in real-time process their network traffic, send it up to the cloud, run behavioral analytics on that data and take any necessary action. There’s either a SAAS version or it can be installed completely on premise to avoid sharing data with the cloud. The value of the product is that it processes data and looks for anomalies, such as attackers trying to get inside or take data out of your network.

The power of our product is the collective piece, IronDome. This allows a company to be alerted when other companies using IronDome notice a compromise or attack in their network. You receive an alert based on another company’s feedback and can take action before your own network is impacted. Alternatively, you also see when something is marked as non-malicious. You don’t spend as much time looking into the issue because you’ve already received feedback from others in your sector.

I think of it as a neighborhood watch system. On top of the world-class analytics, you also receive insights based on everyone else’s data.


What is your current tech stack and why did you choose that tech stack to build your product? 

When we started building the product we only had an on-premise physical appliance and worked with clients who had a data center. Today we have a SAAS version of it. You can use the entire product virtually if you want.

Over time, we’ve gone through a couple of technology changes. At the beginning, we used MongoDB. But by the time we approached an MVP, we were doing a lot of relational queries. This prompted us to become a Postgres shop in order to get the properties of a relational database.

Today, we use a framework by Google that’s called GRPC. It’s a high-speed RPC framework and enables us to build stubs for servers and clients. It has allowed us to have an unleveled amount of tracing and health checking. It comes with a couple pieces like the JSON Gateway which powers our front end, which is in JavaScript. We’re able to merge those two together almost seamlessly.

GRPC also enabled us to easily have services in Python communicate with services in Go, which has led us to become a heavy Go shop. We’ve been able to build interfaces and bridge out. At this point in time, the best tool to accomplish our goals is GoLang.

This tech stack has been the best option for our business since it’s absolutely critical for us to have high performance and high confidence in the data we observe. If there are any missing packets, or missing data, then the analytics will be inaccurate. These tools ensure high quality data and key insights into that data.


Want to learn more about IronNet Cybersecurity? Check out their company page to learn about their company culture, product, and more!


Join the Hatchpad Community

Stay up to date on the DMV's high-growth startups, tech jobs, tech events, and salary insights.

* indicates required