Creating a website that is both functional and aesthetic is not an easy task. In this article, we will guide you through the process of preparing a site outline step by step.
This should be the last part of this series and we will touch on something that takes place after the project is done, deployed and serving your clientele – web application maintenance.
In previous parts, we looked at:
- essential parts of website project: content, design/UX, and backend (Part 1),
- building apps from scratch and frontend development (Part 2),
- testing and hosting (Part 3),
- performance optimization (Part 4),
- website caching (Part 5),
- ssl certificates (Part 6),
- and code deployment (Part 7).
End is not really an end
The fact that the build of the project is completed doesn’t mean the work stops completely. Web application maintenance is as important as the maintenance you perform on your car – you do it to ensure safety and smooth operation. Neglect it and post-incident fixes may actually cost more than a well-executed service plan. What’s important is to plan for this work up front so that you’re not surprised later on.
Before we go any further, let’s define what web application maintenance should and should not cover. Let’s start with what should be included:
Application-related maintenance
This splits into two main groups of tasks:
- Bug fixes. Despite developers’ best intentions there will always be bugs – unexpected and unwanted behaviour of the app in certain circumstances. They may be caused by use cases that no one thought would take place (real users are super-creative) or by external causes such as a new version of web browser being released.
- Keeping software up to date. In most cases, your website is created with a framework or at least is using some third-party libraries (plugins). These change over time as their creators release new versions that fix security issues, improve performance or introduce new features. It may feel like an unnecessary bother, but at the very least security updates are critical to introduce as soon as they are available. Otherwise, if someone can figure out what your app is using (not that hard to do actually), it’s extremely easy to use a known vulnerability with evil intent. It is important to note that the exact description of the issue to be fixed is available with most security updates. A similar situation is that of performance updates – why wouldn’t you want to improve how your website performs? It’s better for your users and improves your changes for conversion.
Hosting-related maintenance
The servers running your web application also require occasional review and updates. These fixes may be related to updating the web server software (Apache, Nginx), database server application (MySQL, Postgres), caching apps, the operating system itself, or its packages (parts responsible for certain operations, for example secure connections).
Web Application Maintenance is also an investment
In most cases it’s easier to do smaller updates more often, as opposed to one big one every year or two. There are two reasons: psychological and technical.
The first is due to how we view and think about expenses. Web application maintenance plan is an expense that does not bring anything new to our business or our clients. Because of that it’s easy to see it as a necessary evil. It’s easier to accept a small bill every month than a big one at once.
The second is related to the speed of changes in web development technology. It’s happening at a breakneck pace and not all changes are fully backwards compatible. Sometimes we want to update one library and instead of just adding a new version we hit a problem as it’s not plug-and-play anymore. If we do updates often it’s usually a smaller and easier job to update in the application itself. Often it’s easy to find relevant articles about the update procedure, etc. After longer period of time these small changes pile up, and it’s not only a lot of work to make sure all updated versions actually work well together, but it’s hard to find instructions as these are less popular as time goes on and Google buries them under newer content.
Finally, leaving the updates to happen rarely makes them a significant change to the web application as a whole. This means a lot more thorough regression testing is required in order to confirm that the whole system still works well.
Conclusion
You need web application maintenance in order to secure the future success for your project and happiness of your customers. Plan for it when you’re planning the project and make sure that the team you’re working with is willing to be involved with the maintenance after the project is done.
It may not be mandatory that the same team builds and maintains the project, but it’s easier that way – people already know how things work and why things are built in certain ways. Finally, it’s often true that people willing to maintain the project will deliver higher quality software, but that’s not a rule.
As usual, if you have any questions or suggestions leave a comment below or ping us on tweet us at @nopio_studio.
