Agent-based model development

• Keep your models simple
• Document your models using ODD or equivalent documentation protocol
• Consider carefully how to evaluate and validate your model’s outputs. Make sure you do a proper sensitivity analysis!
• Structure your model into coherent modules where possible with well-defined inputs and outputs that use established community standard data formats.

Additional ABM Guides

• Considerations and Best Practices in Agent-Based Modeling to Inform Policy (Hammond, 2015)
• Guide for Newcomers to Agent-Based Modeling in the Social Sciences (Axelrod & Tesfatsion)
• When All Models Are Wrong
• Using Agent-Based Modelling to Inform Policy – What Could Possibly Go Wrong?
• Agent Based Modeling Oxford Bibliography
• Introduction to Agent Based Modeling

Code management

Some of the code and data management practices listed below are also described in greater detail in Good Enough Practices in Scientific Computing by Wilson et al.

• License your models with an appropriate Open Source license. Note that Creative Commons licenses are not recommended for software and will likely be deprecated and removed from comses.net in the near future.
• Use a version control system diligently, and strive for small, focused changes with meaningful and descriptive commit messages.
• Clearly document all software and data dependencies with explicitly pinned versions. Tools Docker, pip/poetry, packrat, Maven/Ivy, npm
• Strive for simple, well-commented, self-documenting code with meaningful variable names
• Adopt or develop community documentation standards to describe your computational models (e.g., ODD)
• Adopt a consistent, self-describing directory structure for your code, data, documentation, and results
• Archive your software in a DOI-issuing repository that also hews to the FAIR Principles for Research Software and the
• An excellent article from the UK’s Software Sustainability Institute on guidance for depositing software for a publication
• Provide clear example test cases, with well documented sample inputs and expected outputs
• Use relative paths instead of absolute paths when referring to input or output data files
• Structure your code with clarity, reuse and future comprehension in mind and adopt your modeling language’s idioms for writing clean, concise, and well-encapsulated code
• Common Software Quality Assurance Baseline Criteria for Research Projects group.

Data management

• Preserve raw and intermediate forms of data
• Adopt or develop community standards for interoperable data inputs and outputs, e.g., ESIP’s Interoperability efforts
• Document all data cleaning and processing steps - record your provenance
• Script your data analyses - don’t manually munge an Excel sheet
• Archive your data in a DOI-issuing repository that provides citable URLs for specific versions of your dataset
• Create tidy, analysis-friendly data
• Good practices for organizing your data using spreadsheets
• DataONE’s best practices
• Data Dryad’s best practices for creating reusable data publications