How often we anticipate the release of a new program or application for a long time and then get horribly disappointed by the way it back-pedals our work. Why do such situations occur and how can we, as software developers, influence it? And one of the most important questions is who should be blamed for broken software. Evaluation of an application performance depends on three parties involved into the application lifecycle: the user, the customer and the developer. Regardless of the type of the application and the data it processes, the user always tends to demand high level of application performance. No one wants to work with a program that is slow and stupid. And the notorious first impression that can not be underestimated depends not only on the design and usability but on the application operating speed as well.
The customer often pays great attention to the program functionality leaving aside the question of performance. And sometimes the problem becomes obvious only when the user gets disappointed by the product.
The developer has major influence on the application performance rate, especially if he/she lacks skills and experience. Knowledge gaps often result in choice of slow and least effective delivery methods. Another factor is absence of clear performance requirements. It often provokes the developer to use methods that are easy to realize but affect the application operating speed. Poor performance can also result from absence of well-elaborated architecture that usually contains a set of general rules to ensure proper performance of the software. When there are no such rules the choice of development methods depends only of the experience and responsibility of the developer. So the chances to get a highly productive application can be rather low.
We at Gersis Software had faced such problems and we elaborated a set of measures that can help avoid the risk of low application performance. These measures concern mainly the customer and the developer, as there is little that can be done to influence the subjective expectations of the user.
First of all constant practice and learning is a must for every professional, especially for developers. Improving the knowledge base a developer reduces the risk of mistakes he/she can make. Secondly, regular code reviewing reveals critical points. If the feedback is mostly negative, the project manager should consider the idea of shifting the work to another developer. Deliberate architecture that implies not only the general coding rules for the application but also detailed architecture of separate functionality parts makes sense. Such fundamental approach allows detecting possible problems before the development process starts. Take a critical look at the performance requirements provided by the customer – sometimes they are not the optimal ones. If the customer didn’t provide any criteria it would be reasonable to work out your own requirements to evaluate the operating speed of the application. Load tests and performance tests help to monitor the influence that changing of the code produces on the system performance. Never stop looking for alternative ways to boost the performance. But do not abuse unconventional algorithms, resort to them only in case of extreme necessity. Constant performance monitoring and discussing the current conditions with the customer help to predict possible shifts of delivery time.
The rock on which Gersis Software stands is every team member’s dedication to quality. That is why high performance rate is part and parcel of quality coding for us.
The customer often pays great attention to the program functionality leaving aside the question of performance. And sometimes the problem becomes obvious only when the user gets disappointed by the product.
The developer has major influence on the application performance rate, especially if he/she lacks skills and experience. Knowledge gaps often result in choice of slow and least effective delivery methods. Another factor is absence of clear performance requirements. It often provokes the developer to use methods that are easy to realize but affect the application operating speed. Poor performance can also result from absence of well-elaborated architecture that usually contains a set of general rules to ensure proper performance of the software. When there are no such rules the choice of development methods depends only of the experience and responsibility of the developer. So the chances to get a highly productive application can be rather low.
We at Gersis Software had faced such problems and we elaborated a set of measures that can help avoid the risk of low application performance. These measures concern mainly the customer and the developer, as there is little that can be done to influence the subjective expectations of the user.
First of all constant practice and learning is a must for every professional, especially for developers. Improving the knowledge base a developer reduces the risk of mistakes he/she can make. Secondly, regular code reviewing reveals critical points. If the feedback is mostly negative, the project manager should consider the idea of shifting the work to another developer. Deliberate architecture that implies not only the general coding rules for the application but also detailed architecture of separate functionality parts makes sense. Such fundamental approach allows detecting possible problems before the development process starts. Take a critical look at the performance requirements provided by the customer – sometimes they are not the optimal ones. If the customer didn’t provide any criteria it would be reasonable to work out your own requirements to evaluate the operating speed of the application. Load tests and performance tests help to monitor the influence that changing of the code produces on the system performance. Never stop looking for alternative ways to boost the performance. But do not abuse unconventional algorithms, resort to them only in case of extreme necessity. Constant performance monitoring and discussing the current conditions with the customer help to predict possible shifts of delivery time.
The rock on which Gersis Software stands is every team member’s dedication to quality. That is why high performance rate is part and parcel of quality coding for us.
 | Team Leader |
| Bookmark or share: |          |
