Written by J. Moellenkamp
on 
Reading time: 5 minutes
Administration   BestPractice   LessonsLearned   Onceuponatimeaserver

The joy of finding performance problems - A foreword

A journey

Many interesting journeys start with a first step. There are lessons in them and no matter how much you have seen in the past, you always learn new things. This blog entry is about such journeys. Journeys starting with “Jörg, i know it’s short notice, but do you have a few minutes to come into this telephone conference/meeting/video session” , journeys starting with interesting questions in the coffee kitchen about a problem someone is haunted by and journeys starting with a discussion with friends over dinner.

The road behind me, the road in front

Perhaps i should have called this series differently. Like “The joy and misery of finding performance problems”. Because there is both in it.

In my career I had a lot of discussions with customers,colleagues, friends about issues they had with their systems. Finding problems or moreso finding explanations is something I really love to do. Finding issues, solving them. It’s “fun” when you get into the problem, if there is just a vague issue with and you can do your best House MD impression while solving the problem in a large conglomerate of components. Seriously, there is a lot of job satisfaction in going into a problem situation, finding the problem, helping to solve it and grin when looking into the display thinking “Gotcha!”. This is the reason why chose the title “The joy of finding performance problems”

On the other hand, it’s not a fun job at all. Performance problems cost money. Performance problems cost sleep. Performance problems cost nerves. Performance problems cost job satisfaction until you have solved them. It’s about delivering results with a lot of pressure. Because people must have their problem solved as fast as possible when the system in question has performance problems. It’s about not being able to prove a theory. It’s about jumping into a situation where you have absolutely no knowledge at all because you never have seen the environment before, just your general knowledge about the involved components.

My professional aspiration is to plan systems in a way that I’m not getting into such situations. I love to do such work, but I don’t really want to do it. But well … sometimes it happens. Systems live inside their set of requirements and such requirements can change as life can change.

I write this blog article knowingly that searching for performance problems will be different in the future. There will be a part where I write about this future and its impact. It will be different. But I really think that some of the lessons I’ve learned will still be useful.

Experiences

This is not a blog article about a single technology. I wrote a lot about Solaris in the past. But it’s not about Solaris. It’s not about a single company I have worked for. The experiences I will describe are based on 27.5 years 1 of being in this business, experiences I made in different companies, discussions with friends, telephone calls in the evening when someone asked me if I had any idea with their personal pet project that just won’t work properly. It’s about lessons i’ve learned. Some of the lessons were learned the hard way. Some of them slowly over many years.

Keep in mind

As I wrote: This is not about technologies. It is not about products. However my experiences are partly a product of working for companies in my past. Thus I’m not independent in my opinion. Still, as this is my personal blog, it’s about my personal journey in this area. I try to keep products out of this blog entry as much as I possibly can, knowing that examples will be colored by the stations of my career, about products I worked with. But writing about them, presenting them as solutions would break the idea of this blog entry, which I will come to in the next paragraph. It would be breaking the idea of being as general as possible.

As with all the other article in this blog: It works for me, see if it is working for you.

Why am I writing this blog entry?

Recently I had a discussion with someone (whose opinion i hold very high) about working in IT in general. The essence of it was, that we are now the experienced people, that we went through several changes of the industry. That we all developed our own ways and means to work in this area that served us well. In short: We are now the old farts.

In parallel many new people enter the business. My little sister is just getting a foothold in this business and I don’t have the slightest doubt that she will be very successful in it. But then I remembered that I’ve learned a lot from experienced people over the years. And then I thought, instead of boring people with long stories from the trenches of the business (“Yeah, back then when I wrote some stuff in COBOL …” 2), I will just put it in a long blog entry for whoever is just getting into the business, for my sister and for everyone who is just interested in what I’m writing in this blog.

This blog entry is about putting my experiences in writing. How do I work? What’s my approach to problems? It’s written about performance problems, but many lessons may work for any kind of problem. It’s about my approach. This may work for you. It may not work for you. Would be nice to hear your thoughts about this topic. Feel free to comment on one of the usual social networks I’m using.

The next parts

I started to write this blog entry over several evenings. It was long in the beginning, escalated quickly from there and with each additional thought it got even longer . At the same time I integrated a “Reading time” plugin into my blog software and saw the number rising up to numbers far too high. The article just grew too long for one single article. Out of this reason I split it up into 8 parts (so far). I hope that I will have one part ready each week.

Today I just published the foreword of this article. The next part will be published on Monday next week. The other parts will be published on the following Mondays.

The joy of finding performance problems

So far the following parts have been published:

  1. If you count one and a half years doing IT in the German Army. I made the error to appear with a computer magazine at my physical examination. I assume that transformed a sure “unfit for serving because of my knees” to a “somewhat kind of just barely fit enough for serving” and so I did manage computers in uniform while doing military service. Long story. ↩

  2. I’m not that old, but i still know at it least in cursory way to express myself in the gift or curse of Grace Hopper. Long story, but not that long as the other story. Started with a school internship at a datacenter. I once joked that the loss of my hair relatively early was just an adaptation reaction to the COBOL knowledge beneath it. ↩