Reading time 3 min

The worst time to learn that a business-critical performance metric depreciated is once a release is in production. Poor site performance can lead to losses in conversion rates and sends frustrated users running right to your competitors. The earlier you can detect a problem, the easier it is to resolve.

Defining “Continuous”

In today’s world, the ability to build fast apps or experiences is no longer a competitive advantage – it’s an expectation. Now the advantage is to build fast experiences faster than everyone else. In this increasingly fast-paced industry, the need to push new features and experiences has outgrown traditional methods of software development, in which conception, design, testing, and implementation are discrete entities, which can be potentially spread out over a long timeline spanning weeks or months.

In response to the race to the new release, these cycles of delivery and deployment have condensed into near continuous mini-cycles complete with more frequent releases, some even as short as every twenty-four hours. Continuous delivery and deployment require a paradigm shift with regard to development, integration, and feedback cycles. As these cycles shorten, development and deployment can respond rapidly as business requirements and industry trends change from day to day.

Shifting from the more linear concept of the waterfall model, the phases of build > test > fail or succeed have condensed from days (or even weeks) into more immediate feedback for developers, thereby helping to minimize the possibility of lost man-hours (read: money) and roadblocks (read: more money) when implementing new code changes. With continuous development and deployment, developers have greater control and visibility into defects, enabling them to remediate any potential issues before go-live.

image for continuous integration and devops_01262015

Source: Carnegie Mellon University’s Software Engineering Institute

Why Do We Advocate Continuous Performance Management?

Going Beyond the Functionality Binary

As these phases continue to condense, one key component is the importance of evaluating the performance impact of a new feature at every stage of the software development lifecycle. To be able to move fast in today’s world, you must have confidence in your abilities to test, review, and deploy your applications without negatively impacting your end-user experience. Remember, it doesn’t matter how fast your development cycle is if you’re putting out flawed code that negatively affects your application’s performance. Your development cycle has to be both fast and dependable.

For example, can you imagine a release without extensive functional testing? Finding out that something failed after go-live is a worst-case scenario. In a more ideal scenario, you would test the entire app and fail the build for any critical use cases that don’t function properly. At a minimum, your developers should have transparency into what functional errors exist, consequently providing the tools for a cost/benefit analysis to decide which errors are acceptable for go-live.

In this burgeoning realm of continuous development and deployment, moving quickly with confidence requires that organizations learn to automate as many of their development activities as possible. This might include using a continuous integration server to automate and test the build process.

This also means going beyond the concept of the simple functionality binary (i.e., Does the feature work? Yes or No) to a more refined concept of functionality and performance. We agree with Andy Still that:

Performance…is a consequence of legitimate activity and once resolved should stay resolved. To that end, once the methodologies for addressing performance issues are understood they can be applied in multiple situations. These elements are not beyond the capabilities of a good developer, given time and space to do so.

Moreover, we know that performance metrics can directly affect business goals (e.g., conversion rate) with an impact equal to functionality defects. Given this knowledge, implementing a build without transparency with regard to its effect on performance metrics no longer makes sense. Integrating and automating testing as part of a build or continuous integration system is critical to ensuring consistent and repeatable insights. Performance best practices have become standard practices, yielding better products that perform better. To remain competitive, organizations must consider phasing in the features of continuous performance management, especially with regard to automation.

Learn more about continuous performance by checking out our eBook, Building Faster Experiences with Continuous Performance.

Suggested Blog Posts

The Perception Gap for Poor Web Performance

E-commerce revenue continues to grow,as consumers turn away from shopping in brick-and-mortar stores to shopping online.  However, many businesses are not prepared for this growth because they do not fully understand the market and how to invest in...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design...

Read More

Finding Causes of Intermittent Errors from Google Webmaster Tools

Google Webmaster Tools is a web service that allows webmasters to view the status of their sites as seen by Google and the Googlebot crawlers. In addition to indexing your site structure and content, the Googlebot crawlers also record data on perform...

Read More

Optimization Options not Always Optimal

Web designers and developers are always looking for ways to speed up their page load times. Yahoo has an excellent article written on the best practices for speeding up your page. How do you know if implementing one of their suggested practices will...

Read More