10 Best Practices for Software Engineering

Heroux and Willenbring's 10 Best Practices

In a draft paper called Barely Sufficient Software Engineering that I find myself returning to again and again as a computational chemical engineer, Michael Heroux and James Willenbring, both of Sandia National Laboratories, wrote up 10 (actually, 11) guidelines for writing scientific code that is high quality and encourages collaboration.

They are:

0. Manage your source (the basics)

1. Use issue-tracking software for requirements, features, and bugs

2. Manage your source (beyond the basics)

3. Use mailing lists to communicate

4. Use checklists for repeated processes

5. Create barely sufficient, source-centric documentation

6. Use configuration management tools

7. Write tests first, run them often

8. Program tough stuff together

9. Use a formal release process

10. Perform continual process improvement

An Abbreviated Version

Issue tracking

Version control

Mailing list

Checklists! Checklists!

Self documenting

Configuration management

Test driven

Pair programming

Formal release

Continuous improvement

Full

See Also: The Cathedral and the Bazaar (19 best practices for creating open-source software)

Following Heroux and Willenbring's paper (http://www.sandia.gov/~maherou/docs/BarelySufficientSoftwareEngineering.pdf), here are 10 "best practices" for software engineering:

1 Issue-tracking software for requirements, features, and bugs

2 Manage source: beyond the basics

3 Use mailing lists to communicate

4 Use checklists for repeated processes

5 Barely-sufficient, source-centric documentation

6 Configuration management tools

7 Write tests first, run them often

8 Program tough stuff together

9 Use formal release process

10 Continuous process improvement