Blogs

Adopting a Performance Focus With Software Development

27 Jan

Over the past few years I have given a number of talks and written multiple blog posts on the topic of performance optimization as it relates to software development.  These postings have been very technical in nature and focus greatly on the problem solving aspects of application performance.  However as I review my presentations one of the most critical aspects of application performance is actually business organization and dedication to application performance.  In this post I would like to review the common approaches that I see within development teams and easy ways for management to encourage positive change to focus more on development.

Application Performance Approaches

As I walk into a new client situations one of the first questions that I ask the development team or management is: "What is your approach for monitoring and validating application performance?"  It is the answer to this that helps me categorize companies into the two most basic categories of companies based on how they approach performance.  We find the following common options.

Reactionary

I would say that 75-80% of the organizations that I work work end up falling into this category.  These are organizations that admit that they "deal with performance when it becomes a problem," or those that "don't do any regular testing."  Basically the developers work as they would like to work and accomplish the tasks at hand. Should a situation arise that something is running slow it becomes a fire-drill and often other items are pushed out of the way to handle the last minute scramble that is a major performance need.

As you can imagine this school of thought doesn't necessarily setup a development team for the greatest success.  Often times we will see some of the following issues within these environments:

  • When issues arise within an application developers are pulled from other responsibilities and they need to re-focus on application performance.
  • Time between performance reviews/audits can be expansive, if ever completed in the past.  This makes diagnostics very hard and prone to risky re-architecture if major issues are found
  • Organizations in this category often cannot answer critical business questions such as "How many users can you handle?" and related capacity questions.
  • Development teams in these environments do not typically have the tools necessary to diagnose and resolve issues when they arise.
  • The development and management teams believe that the current application architecture is adequate for their customers. 
  • The team is time-constrained and limited on resources for anything non-essential

Proactive

Organizations in this group understand that the long term success of their organization is greatly dependent on the ability for it to handle the customer base that is there today and what will come in tomorrow.  Often times when discussing with these teams we will uncover some if not all of the following traits within the teams.

  • The development team has set standards for coding practices and standards.
  • The development team often will have tools and processes in place for regular reviews of their application as it relates to performance
  • Organizations have been asked critical questions such as "how many users can you handle" and have an idea, if not an exact answer to this question.
  • The development and management teams understand and embrace the fact that the applications performance AND features comprise the entire product.  New features that reduce performance are strongly discouraged.

Moving Towards Change

Regardless of where your organization falls in the above spectrum it is important to consider the methods of moving forward.  Regardless of the style of organization there are a few common "checklists" that I like to recommend that organizations work towards adopting.  The more items they can check off of this list the more they are setup to handle what comes at them day to day.

  • Establish and maintain performance minimums and standards for the application.  For example if a web application a standard response time of <= 1.5 seconds for all pages when under ___ user load.  
  • Establish a set of tools and systems to monitor and track application performance and ensure that your developers are trained on the usage of these tools.  The individual tools that are included in this item will depend on the type of application being developed, however, the key is to ensure that you have diagnostics available to your team at all tiers of the application.  Everything from data storage, to .NET code, to front-end application code and everything in between.
  • Integrate ongoing application performance testing with EVERY release of your application.  If a performance metric is no longer met, it should be treated as a "Show stopper" and resolved PRIOR to pushing the release into the wild if possible.
  • Establish a culture that if existing performance optimization issues exist in your organization that they will become priorities as soon as possible to improve your organization.
  • Encourage and provide training to your team if they are unsure of how to approach performance related items.  Application performance is a learned skill and often times simple mentoring and training can improve even the most junior developers day-to-day coding practices.
  • Establish good test routines for standard and peak loads and test them regularly, at least once per major release.  Make sure that no new high-stress points are introduce to your application.

This is by no means a comprehensive listing but is intended as a means to introduce developers and managers alike to the difference concepts and actions necessary to ensure that an organization has a proper performance focus.

In Conclusion

If you simply focus on checking more items off of the list you can move your organization from reactive to preventative with minimal effort.  It is important to push internally to realize that your developers DO need additional tools to help them accomplish these goals.  They also need communication from management to understand the limits and expectations of the systems they develop.

I hope this information has proven to be helpful.  If there is interest in expanding on any of these areas or comments please share them below.

tags: General Tech, Business, DNN Administration, Performance, Presentations
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Connect with Mitchel

I hope the information here has been helpful. To stay connected you can also subscribe to blog updates via email, contact Mitchel about consulting services, or reach out for assistance via CodeMendor

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.