situation is heating up because they have urgent performance problems in their
production environment” … That’s something I heard quite often in my
consulting career. And in many cases it was an outcry for help, because this
problem did not turn out during tests, but most times in production
I read once
a nice quote: “Everyone has a performance
test environment. But only a few have a production environment!” So
really inevitable that performance issues occur? Given the number of cases I’ve
seen, I am inclined to believe it. But it is not.
that if all of a sudden a performance problem is put on priority 1, it has a
history. If you are in a project team and one morning your project lead/PO
tells you that the priorities have shifted, and that you need to push that
little unknown item “Performance tuning” from the bottom of the
backlog to the top of the list, you were aware of performance as topic. But
other features were considered more important.
Or if your
customer is starting to escalate with your account team that a really bad
application (the one you developed for them) performance is affecting their
business, then you often know, that this is not a new issue.
cases the priority of this problem just hit a certain level, that executives
are getting concerned and start to escalate this topic, because it is hurting
their and/or the company’s goals. Here you go, yesterday everything was fine,
today it’s all screwed.
All of these
problems have a history; performance problems rarely just rise out of nowhere,
but they evolve under the radar of ignorance. As long as noone complains, who
cares about performance? Features are more important. Until the complaints get
loud enough they cannot be overheard anymore.
But when you get at the point where you need to care about performance, you are often in a very bad position. Because now you need information, tools and processes to improve that situation very fast. Because are in the focus everyone is looking to your problem (it’s yours!). “Deliver a fast improvement! Within this week!“
But if you
have never prepared for that situation, you lack all the necessary things for
such an operation:
- You don’t have KPIs to know
what is “acceptable” performance. You just have everyone’s
feeling “it’s slow!”
- You don’t have the tools to
measure the current performance. You just have logfiles (hopefully you
have them …)
- Is your system actually able
to deliver that performance?
- “Has anyone got the
reports from the latest performance tests?”
hard situation and there is barely any other way than just to take a bunch of
good people and start a surgery in production: Analyzing lot of data, making
guesses, increasing logging, deploying hotfixes, and do all the things you
already accumulated list on your list of “things which might improve
performance” which you maintained over the last months.
But let’s be honest: This is chaos, unplanned, affecting a lot of other teams and people, and hurting careers. But does it really have to be that way?
No. Application performance is no magic, but must be managed. Performance should always be an important aspect in your project, and resources should be spent on it as you spend resources on testing. Otherwise performance is ignored 90% of the time, and in the remaining 10% you are escalating because of the lack of it.