Plan for Change

PlanForChange

Plan for Change

MOTIVATION

- Change is inevitable:
  - Requirements change
  - Teams change
  - Technology changes
This talk aims to answer the question, "how do I deal with these changes?"

CHANGING REQUIREMENTS

- Design is an important way of dealing with changing requirements
  - Design is a plan of how a system is organised, based on constraints (requirements)
  - Multiple designs fit the constraints, so we have some options in how to organise the system. 
    - Some are better than others!

- How do I design?
  - Dark Art! No hard-and-fast rules. The following are all recommendations.
  - Look at others' designs. Look at Design Patterns.
  - Use UML (Unified Modelling Language) loosely: Use Case Diagram, Component + Object, Sequence, State / Activity
  - Use programming features to separate concerns, allowing for repeatability, clarity and isolation
    - Functions, classes and packages are all useful separations
    - Use interfaces to protect one area of the code from another (and be aware of implicit interfaces on functions and classes)

- When do I design?
  - Start with a high-level design before developing (to ensure sanity and allow quick changes).
  - From there, design as you go along.
  - Follow the Boy Scout Rule - tidy up as you go along, even in legacy code.

- Other ways of dealing with changing requirements
  - Use automated tests; they allow you to replace the system without affecting its useful functionality, allowing for change.
  - Use version control for the moment when your client wants that feature from v1 back!
  - From a project management perspective, use Agile techniques to allow changes during the project.
  - Get your client involved: use tools like JIRA and Trello to give them restricted control of the project and engage with the project further.
  - Pre-empt requirements changes in the design phase and put your flexibility there. This requires good business analysis!

- Warning signs of poor adaptability
  - Long code listings are difficult to understand and should be unravelled.
  - Code fear - reluctance to change an area of the code because you don't know what it does or its implications on the rest of the system. Use tests!
  - Everyone can access everything leads to a large complexity. Consider layering or using more interfaces.
  - Side effects: get rid of them. Never depend on them!

TEAM CHANGES

- Most likely, a developer will leave the team and another will join. There may not be any handover, so don't depend on talking to someone to make them aware of the quirks in your project.
- Documentation is important:
  - The SMG should at a bare minimum get you a development environment and show you how to deploy to a live environment.
  - Comments in the code should be explanatory, in full English and provide context for unusual gotchas.
- To do less documentation, automate your development environment setup or deployment process.
- If you're left in the team, make sure you know where the leaving member has put all of their knowledge!
- Are there any style rules or processes to follow? Automate their enforcement!
- Be wary of:
  - SMGs that have not been updated in a while, or after a development cycle. (Document!)
  - Long SMGs with many build or deployment steps. (Automate!)

TECHNOLOGY CHANGES

- In order to react to technology change, you first need to know it's happening! Read around, read blogs, follow people on Twitter, try new things!
- There are some general pros and cons for new technologies:
  - Most offer performance or readability improvements.
  - Documentation is typically lacking.
Read around the technology to try and get some hands-on experience. If there isn't any, go and try it!

SUMMARY

- Things change, so get used to it!
- A good design will make requirements changes easier.
- Keep your SMG up-to-date and automate as much as possible to ensure team changes are easy.
- Read around and experiment with new technology. Take the plunge on projects when you can!