What Is a Software Simulator?
Our definition of a software simulator and its core characteristics.
In this blog post, we dig into what we mean by “software simulator” and how this technology works. For an example of how a software simulator can impact how you build software, especially as a team, read: Introducing CodeYam: The Software Simulator.
Simulations: The Secret Weapon of Inventors and Engineers
Simulators have been leveraged throughout history by inventors and engineers to gain critical learnings, faster. When you are exploring something new, especially in technology R&D, simulations allow you to test ideas more quickly. Simulations can provide insights into complex problems that can be the difference between failure and success.
For example, when Orville and Wilbur Wright were racing to be the first to build a functional airplane, they developed wind tunnel experiments that provided a secret advantage. This wind tunnel acted as a simulator that allowed them to more rapidly test their hypotheses. As a result, the Wright brothers gained an understanding of the dynamics of lift that allowed them to beat competing teams.
In our depictions of the future, AI often helps people work through problems using simulations. From JARVIS helping Tony Stark develop the Iron Man suit to the computers on The Starship Enterprise in Star Trek, the ability to easily run simulations against various scenarios is invaluable to the inventor, engineer, or problem solver.
With current technological advances, including AI, we should be pushing on the simulation frontier as much as possible to accelerate innovation and engineering across a variety of industries.
What Is a Software Simulator?
Simulators exist in many industries today, especially for hardware products. However, you don’t often hear about software simulators. To be clear, we are not referring to simulators built in software that allow you to design physical products, such as sneakers, faster. We’re also not talking about AI being used to write code or build software from scratch. Instead, we are focused on simulators designed to show how existing software performs in various scenarios (i.e. how different users would experience the software). A software simulator simulates software directly.
Here is an example how a software simulator might work:
Outside of companies like Tesla or Waymo, which have software to train and simulate how their self-driving AI will perform, the concept of a software simulator is rarely discussed. Yet, even for the simplest software project, the ability to quickly explore how the software responds to different scenarios can dramatically speed up the process of delivering a high quality product.
For most software companies, you might use staging environments and automated tests to simulate how software will perform in production. While useful, these tools only partially meet our criteria for a robust software simulator, which we define below. A robust software simulator could add significantly more value to the software development process and team.
We define a robust software simulator as a tool with these four qualities:
A “Simulated” Environment
Scenarios
Isolation
Automation
Simulated Environment
A simulated environment is exactly what it seems; without one, you would just have the real thing and not a simulation. For physical products, such as self-driving cars, creating a simulated environment with software makes a lot of sense. So what does a simulated environment mean for software?
For software, the real environment is production as that is where real customers (a.k.a. users) are using your software. Staging and test environments are generally the simulated environments we use in software development to test and validate the product before deploying changes to production. So while they are not fully robust simulators, with staging environments generally lacking scenarios, isolation, and automation, and test environments generally lacking automation, they are clearly valuable tools.
Here is an example of how you might use a software simulator to test code changes’ impact on the product and user experience for a software application’s sign in flow:
Scenarios
Scenarios in a simulator represent different contexts. For the Wright brothers, their wind tunnel allowed them to evaluate how the plane would respond to various wind conditions. Different wind conditions represented different scenarios for their planes.
In software, a scenario will usually be the data for a given user. A scenario could also be data from an external source. For example, if you had a weather widget that changed the display based on the current weather, then some scenarios to simulate might include rain, hot temperatures, or an emergency weather alert.
The ability to quickly generate scenarios saves time and allows you to test how a product responds under a wide range of conditions. Today’s software staging environments usually provide no support for scenarios, which is one of the reasons they do not satisfy our criteria for a robust software simulator. On the other hand, test environments do simulate different scenarios. However you generally have to set these scenarios up as test cases, and that effort can be significant.
Isolation
Isolation in a simulation allows you to easily dig into an experience. Consider Tony Stark asking JARVIS to zoom in on a specific aspect of the engineering design he is working on, simulating how a component of the Iron Man suit behaves in various scenarios. This allows him to understand and isolate issues, addressing them more specifically. The ability to zoom in on specific aspects of a complex system is crucial to creating a high quality product.
The ability to zoom in and out within a simulation is incredibly valuable. This allows you to explore and iterate on both the design of an individual component and how all of the components work together. Putting an isolated component or the whole project through various scenarios lets you learn and iterate toward the final design faster.
In this example, you can see an activity feed in the context of the larger dashboard product, then isolate just the activity feed feature to demo and check different scenarios and user states.
Automation
Without automation, simulation becomes very effort-intensive. This is where developer-written tests for software products become challenging. Many startups, and even larger companies, do not have robust developer-written tests because they do not have the time and resources to build them.
A software simulator is not intended to replace developer-written tests, but can provide a way to increase test coverage and reduce surprises. This increase in quality assurance and test coverage comes at little to no cost to the engineering team, because of the high level of automation involved.
If code can be automatically simulated as soon as it gets written, then software simulations can be used in a variety of ways (e.g. manual testing, sharing for feedback, communicating progress, etc.) as you move from development through to production. As mentioned before, we dig into this more here: Introducing CodeYam: The Software Simulator.
The CodeYam Software Simulator
We are working to bring a robust software simulator to life. We want to make it fast and easy to simulate any software program under any scenario, with the ability to dig into specific aspects of that software easily.
If you are interested in learning more you can subscribe to this blog.
Or visit our website to follow us on social media and join the CodeYam waitlist.