How much handholding do you want in your simulation tool?

Imagine making your way up a mountain and you encounter a cliff face that you need to overcome. Regardless of whether the largest ‘cliff’ you’ve scaled is your home stairs or a literal cliff face, the tools you’re given will dramatically affect the difficulty – from pre-existing hand holds to only picks and camming devices.

If the goal is to make it up as quickly and painlessly as possible, clearly the option with the most support – the hand holds - is the preferred choice. However, what if the goal is actually somewhere around the bend? If the picks and camming devices weren’t provided, you’ll most likely be at a complete loss – a realization that hopefully wasn’t made too far from the ground!

Bringing us out of analogy-land, the parallel to the simulation space is how much “handholding” any given tool provides, a term I’m using rather loosely. The type of handholding I’m referring to here is the assumptions that the developers bake into their tool for the process of (ideally) streamlining the modeling workflows. This idea goes beyond features and functionalities, and even beyond the way you build the models (e.g., code versus visual editors); it focuses on how easy it is for the modeler to input the specific rules of their model into the virtual space that the tool provides.

More handholding makes it easier to build models, but at the expense of edge-case flexibility. This assumes that the assumptions being made by the developers are true of your system.

The handholding itself isn’t a bad thing, but it becomes detrimental if the tool you’re using doesn’t provide a way for you to ‘let go’ when it’s needed.

Additionally, the lack of handholding isn’t inherently bad – it’s arguably better than bad (or forced) handholding – it just puts more onus on the end-user for all implementations. SimPy is a great example of this, as it provides the barest of minimums for describing simulation logic; everything else is up to the end user to implement.

When the amount of handholding hits a sweet spot, it’s invisible. It aligns with the user to a point where they don’t perceive it.

On the other hand, bad handholding is at best obtrusive, and at worst, a complete roadblock for the project. Bad handholding is where you start to need workarounds to circumvent the roadblocks put into place by the developers. Unfortunately, many of these aren’t apparent until you are deep into trying to model something!

The best tool would provide ample amounts of handholding, while still providing mechanisms for you to deviate.

Let’s look at AnyLogic for an example of good and bad handholding which concerns routing, specifically comparing GIS and Pedestrians/AGVs.

When agents need to move on the GIS map, AnyLogic provides three out of the box ways to configure their routing: querying a server, a PBF (routing) file, or straight lines, with the first two having some options for configuration. This is “handholding” in that the modeler is provided a streamlined experience for a part of modeling that has many established solutions. But what if the modeler has a private routing server? Or they want to try out an algorithm besides A* or Dijkstra? Or want full control over the paths traveled?

In this case, AnyLogic provides an ‘out’: a “Use custom route provider” option which exposes a field for you to specify the exact path from one location to another. Here, the full possibility of pure Java is opened, enabling complete freedom.

Here’s a bit of a silly example, where, instead of just straight lines, all routes include a loop halfway through.

On the other hand, pedestrians (and free space AGVs) are provided with the intention of being helpful, but the specific implementation often gets in the way when it conflicts with real-world behaviors.

The “social force model” being used for pathfinding is seemingly acceptable and natural-looking at first. Though, in certain (arguably common) situations, like groups of colliding pedestrians, bottlenecks can quickly pile up in a way that wouldn’t happen with real people due to the short-sightedness of the algorithm; pedestrians/AGVs won’t (and can’t) perform any sort of optimal path detection when there’s bottlenecks. The accumulation of micro-delays (i.e., from bumping into one another) where there wouldn’t normally be one can be great enough to throw off the accuracy of the model.

I’ve seen the AnyLogic Support team suggest decreasing or increasing the pedestrians’ radius, but this is an artificial workaround for what is excessive hand holding that’s baked into the software. And, as you can see below, each direction introduces its own problems: too small and pedestrians will act like ghosts; too large and they clump even more.

Arguably, this is perhaps a worse problem for AnyLogic’s free-space moving AGVs. For one, AGV manufacturers may define movement patterns in unique, varying ways.  Further, there may be facility-specific restrictions that should be imposed on the routing logic (e.g., different sized buffer zones in the front versus sides or different distance tolerances for other machines versus people). With no easy way to customize these behaviors (without extensive, clunky workarounds), a modeler would hit a wall in terms of their ability to use the software.

The point here is that handholding can save immense time when it’s good but can be a nuisance or even a showstopper when it’s bad. If a company is building a platform for something as complex as simulation modeling, it’s vital that they’re aligned with the customers’ actual needs and they provide built-in features for users to customize any assumptions made by the software developers when they conflict with the end-user’s goals.

On the side of the user (or potential user), the tricky part is that to correctly and fully identify whether a certain software feature is good handholding versus bad for their specific use case requires detailed knowledge of both the software and the problem. And naturally, companies won’t want to talk about the historical issues people have had with their software 😉. For that, it takes extensive exploration or a trustworthy source to be able to correctly find the best solution based on time, resources and money constraints!