software development

Stellar Science uses lightweight, flexible software development processes inspired by the original Agile Manifesto, valuing:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
  • “The best measure of progress is working code.”
• Customer collaboration over contract negotiation or detailed requirements specification
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. Individual projects adapt and tailor aspects of modern agile approaches including scrums, sprints, and retrospectives, always ensuring the processes exist to support productive software development rather than inhibit or complicate it.

Stellar Science emphasizes these general software development approaches:

• Use revision control always: push early and often so others can see the work in progress (and to back it up)
• No code ownership: anyone is free to improve or extend any code any time, along with the responsibility to exercise caution and seek help in unfamiliar areas, and to get anything broken working again
• Code for reuse: separate data from algorithms, create reusable libraries and tools where possible
• Be concise yet readable and maintainable: generally prefer less code to more code; don’t copy and paste but rather generalize code into reusable components used in multiple places
• Leverage existing code: don’t reinvent the wheel, but use existing Stellar or external code, tools, and libraries
• Continuous integration: integrate components early and often, versus writing code in isolation for months and expecting it all to nicely integrate with other components at the end
• DRY: we won’t say this again
• Documentation: should live and be maintained with the code; avoid boilerplate; avoid repeating the code; focus on what the next developer (who may be future you!) needs to understand
• Unit testing: develop tests before or concurrent with code; write both low-level and integration tests
• Relentlessly refactor: with sufficient unit tests as a safety net, continuous integration helps alert you to breakage
  • Almost never throw the current code away and start from scratch
• You Ain’t Gonna Need It (YAGNI): since anyone can refactor and extend code later, write the simplest thing that can possibly work now, rather than creating grand architectures that try to meet as-yet-unknown future requirements
  • This requires judgment: don’t paint yourself into a corner, but also don’t write lots of code that’s not yet used
  • When making stable APIs for external (non-Stellar) use, some anticipation of future use cases may be necessary
• Prefer less state: prefer immutable variables; avoid duplicating state, especially that requires synchronization
• Consistency and uniformity: the code should appear, as much as can be reasonably expected, as though one person composed it