In most scenarios, an application’s readiness to be launched is generally measured using the following 3 parameters
Of the three parameters, functionality is the easiest to deal with. Majority of the time spent in the project goes in getting it right; so much that the entire focus of the development team generally is getting the functionality correct.
Usability has gained a lot of importance over the past few years; clients no longer are keen on great applications with a bad UI. With a lot of new technologies emerging in the past few years, this is an area that is more or less stabilizing and we can see lots of applications around that give the wow feeling.
What I am going to touch upon today is – Performance. I am not going to provide a silver bullet to put an end to all the performance issues; I am trying to provide a small change in the mindset that will go a long way in addressing the performance issues.
Over the past few years, I have observed a similar trend in the projects I have been associated with or heard of. Apart from incorrect or incomplete functionality, the number one reason for delays in launching an application has always been performance.
According to businessdictionary.com, Performance is defined as
The accomplishment of a given task measured against preset known standards of accuracy, completeness, cost, and speed.
A very concise and precise definition which generally becomes a nightmare in a software application given that some of the “tasks” to be measured in performance include:
Time taken by the application to respond to a user’s requests (response time)
Time taken by the application to respond to multiple concurrent user requests over an extended period of time (load test)
The length of time that the application continues to respond to user requests before completely breaking down (Reliability)
Unfortunately, performance issues are not encountered till the fag end of any project, until after the functionality is tested and just before the preparations are on for the launch. This trend is mainly due to the following reasons:
Developers, by nature, are more interested in solving things logically – they are keen on getting things working. Moreover, given the tight timelines that most projects typically have, their main focus tends to be towards getting to implement the functionality rather than thinking about their performance implications.
Clients too spend a majority of the time with the development team explaining the functionality to be implemented. Hardly any time is spent on “performance” expectations
To add to these, the environment where an application is tested throughout the development phase is not good enough to check the application’s performance. Hence the focus during testing too is to check completeness of the functionality rather than bother about the performance.
Thus during the entire development phase, focus is on completing the functionality rather than working towards an acceptable performance.
Planning for (Lack of) Performance team
The team that specializes in testing the application performance is generally involved in the project only after the entire functionality is tested. Thus the performance issues start showing up when the application is functionally complete.
Also there is hardly any time that is set aside for improving the performance of the application.
The typical fallbacks of the above approach include
Due to short development timelines, a lot of performance issues start surfacing due to improper coding practices which lead to a lot of code refactoring after the project is completed
Once the code is refactored for performance enhancements, the entire application needs to go through a complete retesting cycle
Escalations and Time & Cost overruns
All the above leading to delays in the project launch
From my experience, there are some very simple rules or tricks that, if incorporated from the early phases of a project, will avoid “performance” bottlenecks:
1. “Take care of the code and the code will take care of performance” – Use good coding practices; look at ways the same code can be written to perform better
2. Evaluate using client side coding against server side manipulations – try using ajax calls rather than reloading the entire page for every single change on client side.
3. Agree to performance requirements at the beginning of the project and continuously monitor performance
4. Performance, or lack of it, is not just based on application code; plan for infrastructure that can meet performance requirements
5. Be realistic – understand what can be done and what can be not. All modules can not behave identically; decide on performance parameters based on functionality required and UI to be provided. Discuss and inform what can be done, what cannot.
6. While using third party components, make sure you are aware of their performance bottle necks
7. When integrating with multiple applications, ensure all are tuned to performance. Ensure the data transfer between applications is minimal and optimized
8. Many performance issues crop up because of improper DB design; ensure DB is tuned to handle data.
We mainly need to teach our developers to provide a “better solution” to a given problem rather than “getting things done”. It is a small change in the mindset, right from the work Go.