Myths About the Performance Testing Results into Bad Development Process

In this post, I am going to talk about the Myths about the performance testing results into bad development process

I originally posted this article on Linkedin with heading “Slow Running Software Applications? Let’s Do Performance Testing”

Performance testing of the software application can help you find the bottlenecks. But wait, when do you think it should be done?

People often think that the Performance Testing comes into picture only once the Application is completely developed.

Well No, this is partially correct, because the Performance Testing done once the application is developed is the final piece of the puzzle. We might have already missed on many things which if done at the time of development would not only deliver a more accurate product but also, would reduce the bug fixing effort towards the end. We can be sure of not missing such important things if we follow a Better Software Development Process.

Now, what is a Better Software Development Process?

  • This brings me to the Retro Approach of Developing the Software Products (unfortunately still followed by masses), where the developers never wanted to step out of their comfort zones hence, used the only technologies and frameworks they were aware of. That could have been fine if followed 8-10 years ago. But, in this era of the rapid increase of user base if we want to develop a robust product we should first do an extensive Proof of Concept (PoC) to understand which is the best technology or framework for the product development.
  • Also, we should not wait to test the product until the development ends instead we should start testing (unit testing, performance testing etc) the product when it is in the development phase to avoid difficulties later.

 

Consider some real world examples of Performance Testing. The reason behind my sticking to Performance Testing is if we do not identify the performance bottlenecks early in the development phase, we might end up paying millions by adding more servers (hardware) to suppress the performance bottleneck but, this too will not prevent the application from crashing.

After observing many different applications, I have found one common reason for performance issues that is true for 90% of the applications.

Let me take two different examples to explain this better.

Example -1 Immature business requirement implementation:

Yes, there are applications which lag even in basic functional/business implementation. I had tested an application which was querying the complete data set of “Sales Order” from the DB2 database by joining all the required tables at the time of page load. This was happening even with no lazy load and with no pagination etc!. This is not it, it will again fetch all Sales order once you create the new sales order.

Why a business user would be interested in viewing like, 3 million records (3-5 years data) every time when they create a new sales order? This was not even restricted to only to the Sales order instead, same was happening with the Invoices, and PO etc.

What will performance testing do in this case? After doing the analysis, we found that a query was taking time and the DB contention was high, but as per the query execution plan, the query was optimized. The problem is with the improper implementation of the business requirement.

Example -2 Lack of understanding on how to use technology:

There are applications built with the technology and framework that are not the best choice for that particular application.

Yes, There are development companies using the technology in which they are comfortable, instead of using the right technology. For instance, very small example, Use of .NET for small static websites with just a contact us form. Simple use of HTML, CSS and Javascript is good. If you think you will be updating the content frequently then, use any CMS like WordPress or Drupal according to the need. Any free CMS will be far better then the small static website written in .Net for that matter.

 

Implications of Retro Approach for Developing the Software Products:

  • You will end up paying millions for hardware resources that will still not solve the performance issues completely.
  • Use of middleware application that will save the data in cache which will again add the cost to the hardware infrastructure plus the cost of the middleware itself
  • Rework on optimizing the code
  • Maintenance cost will be high
  • Threat of application failure because of heavy load

 

Now, How a Good Product Development Cycle Should Look Like

Small tweaks/enhancements in the existing development process will work.

  • Development plan: To create a great product with efficiency, you should create the development plan intelligently to include the required pieces of testing as the part of the development process to eliminate the production and maintenance cost. It should contain the effort for the unit, performance, and security review while developing the application. It should engage the right person at right time.
  • POC of technology and framework before use: Choice of right technology is very important you should understand requirement before choosing the technology stack. This should be done right in the designing phase and review before actual implementation. The best way is to involve the Performance and Security Experts for suggestions and review.
  • Implementation – Review and Profiling of the code: Profiling of code means testing how much RAM and CPU a piece of code is consuming. If there a scope for optimization, then at this stage(while writing the code) will be more efficient. There are many profiling plugins available for free that can be integrated with the IDE like  jvmmonitor, and VisualVM etc. Even a developer can do this job with all those plugins or Performance Tester can help and give suggestions if required.

 

If the development process is tweaked in this way, following will be the benefits:

The above graph depicts two same kinds of projects with different approaches.

Here if you observe the Retro Product Development Cycle (indicated by RED line) took more time to complete the project compare to Improved Product Development Cycle (indicated by GREEN line) though the Retro Approach took less time in initial phases as compared to the Improved approach.

The major reason behind this difference is that in the Improved approach we focus on the POC for selecting the technology, tuning of the Code and DB Queries from the beginning of the project itself. Therefore, unlike Retro approach we were not burdened with an unoptimized product which is difficult to fix.

So, start checking the performance sooner, than later.

Thoughts and comments are very welcomed…