Back to articles

Development practices and patterns

I started today by reading “The Quiet Crisis unfolding in Software Development”. It is a great article about leadership, metrics, ownership, building better products and much more.

It made me think of the teams I have worked on and the values/structures we put in place around code.

My current team at DWP are probably the first to actually have a document to talk about approaches to code or testing.

We already have the Digital By Default service standards and the service manual which covers topics like progressive enhancement and accessibility.

This also doesn’t cover things such as code linting and styles, though both our Java and Node services have standards applied to them.

Development Practices and Patterns

The software we develop is being delivered using an incremental agile approach to identifying and delivering new system functionality. User stories are identified and prioritised by the Product Owner from a backlog along with along with supporting technical tasks. These stories are delivered across sprints as features that add new customer value to the existing version of working software.

Coding Practices

Version Control

Git our version control system of choice.

Development will be done on the ‘master’ branch (in what is sometimes called Trunk-based development). We will only create branches were absolutely necessary. This has the following benefits:

We will track release versions using the git commit version history. This still allow us to create a production ‘fix’ branch if required. Any ‘fix’ should be introduced into the ‘master’ branch as soon as is possible to allow normal development to continue.

Feature toggles will be considered if there is requirement to develop and release functionality at different points as opposed to the user of feature branches. However once a feature is introduced and stable the toggle should be removed to reduce the overhead of managing this capability.

Testing and Assurance

Testing and assurance of the working software is built into the development and delivery lifecycle via:

  1. Software Patterns - are used to establish good practice within the team and to provide a shared view on how the system is and can be further developed
  2. Code Reviews - of all code are used to maintain consistent coding practices, understand and share each others code and establish common working practices
  3. Documentation - decisions, library choices and common practice within the development process are briefly documented together with examples of working code
  4. Unit testing - used to check and assure the behaviour of the individual class and interface interactions
  5. Integration testing - used to check and assure the function of individual system components with the components/systems they interact with
  6. Functional Acceptance Tests - functionally test that the delivered software meets the functional acceptance requirements associated with it: validation; error handling; identified constraints
  7. User Acceptance Tests - user focused tests at the feature level that assure that the delivered software aligns with the identified user need

Supporting Practices

Were possible a test first approach using TDD/BDD is adopted when delivering software.

Continuous Integration is used to automate the execution of the building and testing of the various software components that are being incrementally delivered.

Automation were possible of software and infrastructure tasks are encouraged in order to aid repeatability and quality and also as a form of documenting critical processes and deliverables as code.