Managing Your Web Application From Publish to Purge

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.

Why Updates Are Necessary Throughout Your App’s Lifecycle

Why do you have to bother with updates to your application when everything works perfectly? For starters, consider the current state of modern browsers. Chrome ships automatic updates to your customers biweekly. Those updates are based on constantly evolving web standards. New versions of frameworks such as Angular, React and Bootstrap are being introduced. JavaScript and .NET runtimes are being updated, and the version you built against is slowly becoming obsolete. In short—everything around your web application is slowly starting to decay from the moment you publish.

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.

How Often Should You Update?

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.

Frequently (Quarterly)

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.)

Occasionally (Semi-Annually)

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.

As Needed (Only When Broken)

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.

Never

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.

The DevCraft Approach to Software Maintenance

To wrap up, let’s discuss the Telerik DevCraft approach to software maintenance. We provide a cohesive selection of .NET and JavaScript UI libraries, embedded reporting, productivity tools and testing frameworks that are all engineered to work seamlessly together—all toward the goal of making our customers’ development projects easier.

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.

Try DevCraft!

Get started with a Telerik DevCraft trial today! Our DevCraft tooling is the most powerful collection of Telerik .NET and Kendo UI JavaScript developer tools. It includes modern, feature-rich and professionally designed UI components for web, desktop and mobile applications; embedded reporting and report management solutions; document processing libraries; automated testing and mocking tools.

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.

Try DevCraft