Risks when changing software

Some questions to answer to:

  1. What changes do i have to make?
  2. How will i know that i’ve done them correctly?
  3. How will i know that i haven’t broken anything?

You can’t minimize software problems by avoiding them. Avoiding changes will make people get rusty at it. Another consequence is fear.

The alternative of avoiding changes is to try harder.

Changing software

Requirements change. Designs that cannot tolerate changing requirements are bad designs.

There are four primary reasons to change software:

  • Adding a feature
  • Fixing a bug
  • Improving the design
  • Optimizing resource usage

There is a very big difference between adding a new feature and changing old behaviour. When adding behaviour we must NOT change or remove behaviour the users already depend on.

Improving the design without changing its behaviour is called refactoring.

Optimization is like refactoring but it has a different goal. Some resource used by the program, time or memory, is changed.

When working on a system we can change three different things:

  • structure
  • functionality
  • resource usage

The Legacy Code Change Algorithm

  1. Identify change points – the places where you need to make the changes
  2. Find test points
  3. Break dependencies – Depenencies are the bigges impediment to testing. Break them to get tests in place.
  4. Write tests
  5. Make changes and refactor