3 Developer Guidelines - mdewhirst/sweat-equity GitHub Wiki

|

|

Developer Responsibilities

  • Discuss design issues on the dev mailing list

  • Write unit tests to mirror Stakeholder success tests before coding

  • Write unit tests to prove bugs before debugging

  • Observe coding objectives in this priority:

    1. Proven correctness via unit tests
    2. State-of-the-art security
    3. Adherence to dev team agreed coding style
    4. Maintainability for unknown future coders
    5. Flexibility for ongoing change via loose-coupling
    6. See also The Zen of Python by Tim Peters
    7. Optimisation only when proven necessary and then only after profiling

  • Always commit working code

  • Refactor without hesitation to eliminate duplicated code

  • Develop only the minimum functionality defined by Stakeholders

  • Obtain Stakeholder acceptance of deliverables

  • Support other Developers when asked for help

  • Regularly report progress to the entire dev team

  • Attend Stakeholder backlog prioritisation meetings

|

|

Rejected work and feature creep

If a Stakeholder rejects work instead of accepting it, the work needs new success tests.

Unfortunately, it was either not specified adequately in the first place or change in the business landscape has invalidated the original specification. This does happen. It provides a welcome opportunity to get things right.

In both cases, the rejected work should be dropped in favour of a replacement feature with refreshed success tests - and possibly a new name. It will need to be re-prioritised at the next Stakeholder meeting.

On the other hand, exercise discretion if the rejection can be turned into acceptance with a minor adjustment. Minor adjustment should not take the feature beyond the original description. Stakeholders have already prioritised the work according to that description.

Feature creep is a crime.