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
- A bespoke application/code base,
- A backlog of urgent work,
- Minimal documentation and
- The site itself is live (and perhaps business critical).
To work around these problems we will normally aim to:
- 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.
- 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.
- 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.
- 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.
- Refactor the code as necessary to enhance quality, remove security defects and make it more maintainable in the future.
- Create documentation about the system – normally within a “wiki” which is linked through to the source code.
- Introduce a deployment process to ensure changes have been confirmed to work before “going live”
The end result is :
- We are able to deliver changes while minimising the chance of introducing new defects
- The source code becomes more readable, robust and reliable
- Over time a history of changes and documentation build up – providing us (and future developers) with documentation on the code base.
