More likely, you have a content management system (CMS), which is specifically configured and customized to manage your content. In some cases, this same software will deliver your content to your audience. In more complex cases, the CMS exposes your content over an API to a front-end application and other channels, which present this content to your audience.
echo("It's software all the way down.");
When it comes to the software supporting your website or application, there will always be a tension between building something new and innovative and getting the most out of what you have already built. Twenty years ago, Joel Spolsky wrote about Netscape making the "worst strategic mistake... they decided to rewrite the code from scratch."
While I love this quote (I probably reference this thinking at least a few times a month) perhaps the more important point is made at the end of Joel's article:
"It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time."
Now, this isn't to say that I am anti-innovation or that I am a technology conservative. In fact, I believe that iterations are the best way to make pieces of software more effective, elegant, or efficient. But, far more than this, I hate to see the waste created by under-investment in existing production software.
Talking about something new is way easier than executing maintenance plans on what you already have. And, as it turns out, executing a new development project is often far more difficult and way riskier than you can possibly imagine while you're dreaming up the new idea.
I believe that adopting a maintenance mindset is one of the best ways to delay the risky undertaking of a full web site or web application rebuild. I come across a lot of engineers, communications professionals, and digital marketers who think that web maintenance is something that starts after a development cycle and ends just before a rebuild.
When talking to customers and teams, I try to encourage us to give the software being created the upper hand by employing what I refer to as "Engineering for Maintenance". You can think of this as "building it right". Once the software has been built and launched in a way that it can be maintained, you can execute a systematic maintenance plan, which I refer to as "Maintenance Engineering".
Engineering for maintenance
In the best case, "building it right" should be the first step taken towards adopting a maintenance mindset. Building and launching web software in a way that it can be maintained covers multiple interrelated disciplines. Starting from the user experience (UX) and design process, where we uncover the best way to communicate with your audience, through to the content modelling, where we plan a logical structure for your content, to picking the technology stack and developing the custom features required to present the specifics of your brand, organization, or mission.
By building something in a maintainable way, we lay the groundwork for getting the return on our investment for the longest possible time.
We frequently come across maintenance cases where "Engineering for Maintenance" was not considered. There are multiple reasons why this could be the case, running the range from inexperience to unexpected success, to pivot pressure, through to simply negligent practices. In these cases, the "Engineering for Maintenance" often takes the shape of an audit and change implementation plan to lay the foundation of what we need to take the project into an appropriate maintenance plan.
In the web development context, "Maintenance Engineering" covers all the disciplines of keeping the website delivering the specific value it was created to deliver. This could be from simply communicating a concise brand message, through to an enterprise brand presentation, collecting donations, or selling products.
Maintenance Engineering is not just keeping the software secure and up to date - it is also about keeping features working well, iterating on features that can be changed, and building out new features which can launch on the same software. So Maintenance Engineering also covers the creation of new features to deliver new value as you iterate and grow to further understand your audience.
Consequently, this phase doesn't only involve engineers. It equally involves UX specialists, designers, content specialists, analytics consultants, and project managers.
As you may notice, there is a significant overlap in the activities that are undertaken during a new development stage and those undertaken in a maintenance stage. However, I've found that "Maintenance Engineering" has a somewhat different flavour to that of the engineering undertaken when building new software. This is due to the fact that maintenance engineering looks after a production site - it necessarily takes a more conservative approach, and moves at a different pace.
I don't mean to suggest that things move more slowly in a maintenance phase - in fact, this is often quite the opposite. I rather mean to underline the point that there are often more things to consider with a site that is in production. This is the reason that, at Amazee Labs, we split our team into a new build team and a maintenance & extension team.
Get more from what you have already built
Adopting a maintenance mindset can be a challenge. It sometimes requires a shift in thinking and taking a longer view than what you may have intended. But I believe it can be valuable, and that you can often get more out of what you have already built.
Find a partner that gets it
If you have an internal team looking after your web software, find a product owner, manager, or member of the engineering team that also believes there is merit in maintenance as a mindset, rather than a milestone.
If you outsource your web development, have a chat with your project manager or customer liaison and check that they share your view on maintenance as a mindset. At Amazee Labs, this happens by default in the regular alignment calls between the Project Manager and client Product Owner.
Spend some time with your chosen partner taking an inventory of where you are at with your current site or application. How aligned is your website look and feel with your brand? How well is it telling your story? Is it still effectively selling your products, or collecting your donations? Essentially ask yourself, from a functionality and communication perspective, how far off are you?
Next, take inventory of the software and infrastructure. Is the software out of date, and can it be brought up to date easily? How performant is the site? Does it feel snappy or sluggish?
Remember, the goal is to get more out of what you already have. There is no getting without doing, so the most important part of trying it out is to take action! The sooner you try to adopt the maintenance mindset, the sooner you'll really know how much more you can get out of what you have already built. In some cases, you may find that the relative cost of maintenance is so high that new software should be considered. In this case, you have learned something, so you're already better off than you were.
But in my experience at Amazee Labs, 9 times out of 10, with some planning and some creativity, we have been able to extend the lifetime of our customers' sites significantly.
The team and I at Amazee Labs are passionate about helping you get more out of what you have already built. If you are interested to find out what we do, and how we do it, get in touch. Looking forward to hearing from you.