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 between modules.

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 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 external software and data dependencies with pinned versions (e.g., 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 provides citable URLs for specific versions of your codebase (for more details, see the Force11 software citation principles)
• An excellent collection of software deposit guidance from the UK’s Software Sustainability Institute: https://softwaresaved.github.io/software-deposit-guidance/
• Provide clear example test cases, sample inputs and expected outputs
• Use relative paths, not 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