The 4 Good Things

The BBC’s Future Media department promotes the use of four key principles across its engineering teams, known as “The 4 Good Things”.

The interpretation of these principles tends to vary a little across each team, but generally speaking they provide a consistent approach to software development across a number of different projects, platforms and languages.

Here are those four principles along with my personal interpretations.

1. Meaningful Code Reviews

  • Code should be written in pairs whenever possible, or reviewed by someone else at the earliest opportunity when it’s not
  • Only code successfully reviewed should be merged to trunk
  • Traceability is recorded (who did the code review and who wrote the code)

2. Developer Accountability for Non-Functional Requirements

  • Operational considerations (i.e. NFRs) are part of the definition of ‘done’
  • NFRs should be discussed with stakeholders in depth
  • A feature/story isn’t complete until the team is confident that it can be managed in production and perform well under foreseeable load and circumstances
  • Developers are accountable for monitoring the health of the product

3. Real Continuous Integration

  • Smoke tests that are automatically run on each commit (and at least daily) in order to confirm that the latest commit has not fundamentally broken the build and/or the world
  • Tests must be in a shared environment so that they cover changes made by all developers, and because “it works on my machine” is not the point
  • Tests are run against trunk

4. Automated Acceptance Tests

  • NFRs are explicitly stated in the stories wherever possible to help ensure the definition of ‘done’ is met
  • Acceptance tests should include all of the functional tests
  • Acceptance tests should run on the TEST environment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »