Everything around your web app decays from the moment you publish. But how often should you update? Here are some options for your software development process.
Let’s talk about the lifetime of web applications. Applications are born, live and mature. They learn new tricks along the way, and sometimes completely reinvent themselves. As software engineers, it’s our job to make sure that the software development process and all applications as a result of it stay on the right path—via updates and maintenance.
It’s the last day of your final sprint. 0 build errors, 0 warnings and all automated UI tests have passed. Your project is complete, so you can deploy it to production and forget about it, right? Wrong. Your web application has just begun its life—now it’s time to raise it.
Also, consider security for a moment. We live in a world where every new zero-day vulnerability can represent a real issue for your software development process and application. Often, those attack vectors are discovered by “white-hat” organizations, which provide the owner of the affected software time to patch the issue. This time is limited, and once that patch is made available, it must be applied quickly to your solution.
Finally, software is always being improved in big and small ways. Sometimes your UI vendor may offer new features that you might want to take advantage of. Often, latent performance improvements are baked into updates as engineers identify and improve bottlenecks. You could dramatically improve your users’ experience without making any obvious chances to your application, simply by upgrading your components and frameworks.
Let’s discuss the 1,000-pound elephant in the room. How often should you update? Updating too often means you have less time to work on new projects. Updating too infrequently can make for a painful and time-consuming refactoring. What’s the best cadence for updating your application? There are a few different options to consider, each with pros and cons. I’m going to go over some of the broad groups below.
Updating your web application frequently will require some discipline. You’ll need to set a strict schedule for yourself and stick to it. The good news is that, while you’ll have more scheduled application updates, each one should proceed smoothly. With frequent update, there tends to be less delta in the libraries that your project uses. Breaking changes will be minimized and noted in release notes. You may only need to run an update command and make no further changes. At Telerik, this is the process we recommend for normal application maintenance. (We’ll talk a bit more about the Telerik approach to library management later.)
This approach is like updating frequently in many ways. There might have been several library version updates that have accumulated, maybe even one or two breaking changes. You’ll have several iterations of release notes to skim through while doing your due diligence (you do read the release notes, don’t you?). It’s normal that you might have to update some code along the way. Overall, it’s more active work than updating frequently—but you’ll have to do it less often. This is a good middle ground.
You know the old adage “If it ain’t broke, don’t fix it”? Would this apply to software too? It might be the right strategy for non-critical systems, but consider this carefully. What would the cost be if the deployed application suffers a critical error and becomes unavailable? Would it be annoying but manageable? Would you be losing money every hour it is offline? Might someone be at risk of losing their job? Determine your risk, then decide if the risk is worth the benefit of not having to update for several years.
The challenge here is that if something is broken, it can be very hard to fix. By this point, it’s quite possible that there are numerous breaking issues that are compounding and interacting in unpredictable ways. You have many pages of release notes to read through, and your specific issue may require intuitive leaps to isolate. Fixing the issue may require a large-scale refactoring or other extreme measures. This strategy is only recommended for the danger-lovers among us.
By far the least-effort approach, this is only really an option if your application has a very limited lifetime with a planned and firm date to be discontinued. However, we’ve all written software that we intended to be thrown away in a few months, and we’ve all found that it’s still being used years later. Don’t let a “Never” strategy morph into an “As-Needed” strategy.
To that end, we release updates on a very regular cadence of three annual major releases, with one to two service pack releases in between. That’s more than six high-value updates per year, each bringing tons of improvements. Each release builds on the previous release—which provides a linear and easy-to-follow timeline for features, improvements and bug fixes.
We keep this pattern super reliable because we really hope that all our customers apply our new updates as soon as they’re available. Each release, R1 -> R2 -> R3 -> R1 …, is designed to be applied in order and offers nearly seamless updates. It’s our hope here that by making updating as easy as possible, we can encourage all our customers to adopt a frequent-update strategy.
DevCraft will arm your developers with everything needed to deliver outstanding applications in less time and with less effort. With award-winning technical support delivered by the developers who built the products and a ton of resources and trainings, you can rest assured that you have a stable provider to rely on for your everyday challenges along your software development journey.
Rick Hellwege is a software engineer, maker, and Principal Sales Engineer at Progress. Rick has a passion for experimenting with the latest technologies and frameworks, and constantly finding out how things work. When not writing code and driving demos, he can either be found on the most remote peaks of New England’s White Mountains, covered in sawdust in his workshop, or digging the earth in his garden.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required