Think about it. When was the last time you heard about your application being slow? Every day? week? month? When was the last time you heard from some business manager “we could do X more/better if the system could be more responsive”? Lots of times. How many processes in your business have their schedule and deadlines dictated by machine execution times? I'm sure that you'll find a few, some of them probably rated as business critical.
So you approach your dev team (either in-house or outsourced) and request from them some time to fine tune the application response or batch times. You always get some variation (or a mix) of the following two answers.
Answer 1: your application does not have any kind of problem with performance, even if somebody is saying that it is “slow”. None at all. It is already working 100% optimized. All the execution paths have been checked and tested, and each one of them is using the best possible algorithm. There are no places worth looking at in the code any more for performance improvements, none. If you want, or more likely need, to improve performance, just buy us some new fancy hardware.
Answer 2: we just cannot stop to look at performance. There is no time to do that here. If we stop and look at performance, we'll delay the next release, the next patch, the next whatever is in the works. We can always take care of performance later. Do you really prefer delay the next project milestone/business roll-out/bug fix in exchange of some nebulous performance improvement target? If you want better performance, just buy some fancy new hardware.
Frankly, both answers make perfect sense, and it would be very difficult to challenge them in a business context. First, you would need to have extensive knowledge of the inner workings of your application to challenge the first. Second, you would need to have a lot of muscle within your business organization to stand up and say “next release/next change process/next bug fix is not as important as investing some time in application performance”
This is business, not F1 racing. Just being the fastest does not give you any prizes. But performance is always on the back of your mind. You don't know quite why. Well, you do. But like the two answers outlined above, you are really lying to yourself. Because you know that, at some point in time, you'll be under the spotlight for your application performance. But is just better to postpone it because.... (insert some mix of Answer 1 and 2 here)
And therein the day comes where your application performance is no longer tolerable, even by the most generous and forgiving users on the face of earth. Even by the management board that have never, ever, seen even the application after its splash screen (well, they probably did in that demo, but they did not understood anything beyond that) And you'll be on the spotlight. And you'll go to your dev team, ask them to improve performance and you'll be told that... (insert some mix of Answer 1 and 2 here)
So you prepare an extra budget outside of plan, assemble a team of techies and buy some fancy new hardware. A migration project after that, your application is running on fancy new hardware. Surprisingly, performance improves. But only a bit. Not even remotely proportional to the money you've spent. What happened?
Simply put, answer 1 and 2, or some mix therein, are not true. Well, they are true, until they have to be proved. And that moment comes when you actually need better performance. This is the time when you realize that your application has a performance problem.
Granted, some applications are not like that. I'm sure that anywhere with human lives at a stake, from medical equipment to air plane controls, performance is taken very, very seriously. Outside of those fields, however, performance is just another factor in the balance of costs and benefits.
No comments:
Post a Comment