At the Center for Mind and Culture, our goal is to conduct interdisciplinary research by applying computational methods to complex social phenomena. Our work covers many fields, including neuroscience, scientific study of religion, demography, epidemiology, psychology, sociology, and computational modelling and simulation. We research a variety of topics including child sex trafficking, religious change, rural suicide, sleeping disorders, maternal mortality, and equity. I work on the technical side of these projects: simulation engineering, data analytics, custom software solutions, that sort of thing.
At the start of the COVID-19 pandemic, we knew we could apply our expertise in social modelling to epidemiology. Traditional epidemiological models like an SIR model do not account for human factors, like heterogeneity of compliance, contact networks, and human ideology; our experience is that these human factors play a large role in systems, and traditional epidemiological models could be more effective if they took these factors into account.
So, we wanted to extend traditional epidemiological models with an agent-based model, where each agent represented a person. We decided to narrow our scope to universities at first, since people’s schedules in a university are very regular with factors like class schedules, contact tracing strategies, isolation strategies, and other policies. We called the model The Artificial University, the predecessor to The Artificial Organization.
At the time, authorities had yet to recommend using masks. We were yearning for a system we could rely on. I was relatively new to modelling and simulation then, as my background was more in software engineering. I built the first version of our model in AnyLogic, but I was desiring a platform that could be better integrated with development workflows I was familiar with. The state of the research on COVID-19 was in constant flux, leading to an ever-changing, ever-growing model. A project like that can quickly become unmanageable without good work processes and conventions. That’s why Simudyne stood out as a solution.
Simudyne is organized like a standard Java project: you have package directories, classes, and a class which runs your model server. Any experienced Java coder could run Simudyne in the IDE of their choice and could start writing agent-based models in Simudyne in an hour. You can load in any library you want through Maven, and you can use any development workflow that works nicely with Java. Fundamentally, Simudyne is just a Java SDK, so you can do whatever you want with it.
After our first model version in AnyLogic was completed, technical debt was high. But with Simudyne, I could refactor efficiently in IntelliJ. I could easily use a Git development workflow. I could more easily use helpful libraries, like AutoValue and Immutable objects.
Perhaps most importantly, I could have effective parallel and collaborative development. I knew that I couldn’t sustain the project solo, but I was concerned about what collaborative development would look like on some platforms. With Simudyne, we were able to onboard another software engineer super easily, and utilize standard Git developer workflows in Github, complete with development branches, code reviews, and pull requests. These workflows not only reduce the accumulation of technical debt with a standard review and accountability process, they also allow for effective mentorship in a way that is difficult with other platforms. I could review a developer’s ODE changes in Github’s code review UI, and point out things like how some code could be cleaner, how a variable name was confusing, and how a unit test was unconventional.
That’s another thing that’s great about Simudyne; you can write unit and integration tests in a standard Java way with JUnit or other testing frameworks. With Simudyne, you could actually set a convention to test all code changes, and track code coverage, if you really wanted to. I’m not aware of other modeling platforms supporting anything close to that capability.
Another thing I’ve learned as a software engineer is to always treat your code like you will not be the only one working on it forever. Always assume that in three or ten years, a stranger will be reading your project and trying to figure it out. With a real development workflow and standard version control, I can make incremental changes and treat every chunk of code as if the next person to see it will be disconnected from myself. This is good practice in general but especially for organizations with churn. With Simudyne, I was able to do this well.
Simudyne’s SDK has been super helpful for our development, enabling us to bring on other developers to collaborate with effectively. I believe we’ve been able to create an environment of shared ownership, effective supervision, accountability, and mentorship that really wouldn’t be possible with other platforms I have used.