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 former 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, the team tries to keep a very tight feedback loop. This means deploying often and trying to stay away from a big-bang rewrite that takes months.
If there’s a database that no longer performs as needed, then the team would choose to rewrite components and incrementally ship them out rather than rewriting everything.
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 the team at IronNet practically implement the “ship often” method?
At IronNet, the team constantly receives feedback about what changes should be made. The stack has a high level of observability and collects a massive amount of information from their services. Observational points have to be kept on the front burner.
As feedback is collected, either from the product or from customers, they 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 the team to get rid of it.
The engineering team also starts the process of making small changes, by frequently asking “where do you want to be in 6 months?” From that question, long-term goals are broken into small pieces.
Most code changes come from either that constant data collection or from the check-ins about long-term goals.
Can you tell us about IronNet’s product?
Behavioral Analytics! The main idea behind the 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 the 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 the current tech stack and why was it chosen to build the 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 there’s a SAAS version of it. You can use the entire product virtually if you want.
Over time, the team went through a couple of technological changes. At the beginning, MongoDB was used. 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, a framework by Google (called GRPC) is used. It’s a high-speed RPC framework and enables the team to build stubs for servers and clients. It allows for an unleveled amount of tracing and health checking. It comes with a couple of pieces like the JSON Gateway which powers the front end, which is in JavaScript. Those two are able to merge together almost seamlessly.
GRPC also enabled the team to easily have services in Python communicate with services in Go, which has led the company to become a heavy Go shop. They’ve been able to build interfaces and bridge out. At this point in time, the best tool to accomplish the team’s goals is GoLang.
This tech stack has been the best option for the business since it’s absolutely critical to have high performance and high confidence in the data the team observes. 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!
