Linux and PHP web application support and development (Bromsgrove, UK)

Software Maintenance

It is a well known fact that over 90% of the cost associated with a software system occurs after the initial release/development – specifically maintaining it – for instance :

  • Updating the software to cope with new legal changes (tax laws, security requirements and so on)
  • Updating the software to ensure correct operation with new devices or interfaces – so, perhaps you wish to optimise the interface for a new mobile device?
  • Updating the software to cope with changes to the underlying hosting platform or environment.
  • Adding new features (perhaps you’d like a Facebook “like” button on each page? Or have new functionality which is needed such as generating a PDF of a page?
We often take on existing PHP based projects from third parties developers, and often find the customer will have
  1. A bespoke application/code base,
  2. A backlog of urgent work,
  3. Minimal documentation and
  4. The site itself is live (and perhaps business critical).

To work around these problems we will normally aim to:

  1. Clone the live site within our internal network – allowing us to make changes and discover how the application works without affecting the public. This also allows us to get ‘sign off’ from the client before making a change live.
  2. Analyse the code base and get a feeling for which areas are likely to be problematic moving forward; we’ll often provide a report from this exercise to the client to help them understand what we feel the state of their software is.
  3. Start to build a suite of automated tests on the site – to help ensure that as we make changes to the software that we’re not introducing new bugs/defects.
  4. Store the underlying source code within a revision control system – allowing us to track changes and giving us an audit trail of the changes we’ve made.
  5. Refactor the code as necessary to enhance quality, remove security defects and make it more maintainable in the future.
  6. Create documentation about the system – normally within a “wiki” which is linked through to the source code.
  7. Introduce a deployment process to ensure changes have been confirmed to work before “going live”
The end result is :
  1. We are able to deliver changes while minimising the chance of introducing new defects
  2. The source code becomes more readable, robust and reliable
  3. Over time a history of changes and documentation build up – providing us (and future developers) with documentation on the code base.