The Mystery
Disclaimer: This story is a work of fiction. However, all product information and claims are completely true.
The day began like any other day with coffee and emails at home, a short trip to the office, and a Scrum standup at 9AM. I hadn’t planned for it, but while my coffee was brewing that morning, so was a mystery!
After the standup I planned on spending some quality time with the latest internal build of Plan Explorer. There’s nothing interesting about that activity, it’s just part of my job. Upon entering my office though, I was greeted by the shadowed silhouette of a man.
I’ve seen just about every horror movie you can imagine, and I’ve probably read the book. Something I’ve learned from just about all of them is… turn on the light! That is what I did next. Realizing it was just Brad from Marketing, my heart rate returned to normal.
Have you ever met someone with whom you instantly felt at ease? A guy who is both “every man” and exceptional at the same time? Brad is that guy. He is a silver knight delivering the SQL Sentry message. He wields the sword of Google Analytics, and the shield of SEO. I’m always happy to see him.
“Brad!” I said, “It’s good to see you. To what do I owe the pleasure?”
I’ll spare you the details of the rest of the conversation. There was some back and forth over whether a Furby is genetically related to a Mogwai or a Wookiee, but that isn’t relevant. (Feel free to weigh in on it with a comment though.)
Brad was there to bring me some feedback from people who have been evaluating SQL Sentry. In particular, a few people were interested in the “Advisor” part of Performance Advisor. It seemed that a handful of them were having trouble understanding how to tap into advisory capabilities.
Elementary my dear Brad. They are looking for Custom Conditions!
Now, Brad is a smart fellow. He was already expecting that answer, and what came next was, I believe, the true point of his visit. He proceeded to explain that the name of the feature, Custom Conditions, may not send the message that this is what should be used to provide advisory capabilities. He also mentioned that some people were expecting us to just tell them what to do, rather than providing them with a way to define what that means for their environment.
We’re now faced with a mystery. Why are Custom Conditions named that way? Why not just build a bunch of generic advisory rules and turn them all on by default?
I will pause here to say that I already knew the answers to these questions, but I needed evidence to substantiate them. It was time for an investigation. Like any good investigator I would start with interviewing the witnesses.
The Witnesses
I’ve been working in Product at SQL Sentry for about a year now, but Custom Conditions predates that. I would need to talk to the people who designed and built the feature. While I’ve only been in this role for a year, I’ve been at the company for a lot longer, so I already knew exactly to whom I would need to speak. I also knew that more drastic interrogation tactics such as caffeine denial or serving them light beer would not be necessary.
Greg Gonzalez
Greg is our CEO. Everyone knows how important that is, but until very recently, he was also the sole Product Manager for our entire platform, including Plan Explorer. When Performance Advisor was first released, he also personally did much of the development. He would be the best place for me to start.
Greg’s favorite thing in the world is having someone stop by his office for an unplanned visit, so I thought I would surprise him by popping in to ask why Custom Conditions are named as they are, and not something catchier.
As I suspected, the answer was that Custom Conditions describes exactly what they are. Why wouldn’t we call them what they are? The “alerting” engine in SQL Sentry has always used the concept of conditions and actions. I use quotes around the word alerting, because it is about so much more than sending an alert. Sure, that is a very common use case, but sending an alert is only one of many possible actions. When circumstances meet a condition, the engine is able to take action. Custom Conditions are the next evolution of that pattern.
Next, I wanted to know why Custom Conditions need to be defined, rather than having some sort of built-in, enabled, and pre-configured set. There is also a great answer to this. Performance best practices are constantly changing. What is “good” or “bad” depends on who you are, where you are, the circumstances of your workload, and sometimes even what day it is. The number of hard rules is extremely limited. Instead of trying to tell everyone what we think is best, we decided to leave that to the people who know best. These would be both the experts in our industry, and the experts on your environment (that would be you).
We designed Custom Conditions to be extremely flexible, and powerful at the same time. We then engaged with super smart people both inside and outside of our organization. These include brilliant SQL Server MVPs, Microsoft Certified Masters, and Microsoft Certified Architects from places like SQLskills and Coeo (among others; those are just the coolest. Yeah, I said it!). The results of these engagements are included in the Custom Conditions pack provided for Performance Advisor.
That’s right, the first time you access the Custom Conditions feature in the SQL Sentry Client, you are asked if you want to download the Custom Conditions pack, which provides you with a full set of pre-built conditions to use in your environment. The pack is regularly reviewed for accuracy, and we are constantly evaluating new additions.
Even better, there are always those areas of your environment about which only you know. Maybe there are performance counters that you need to see, but that others would ignore. Maybe you need to evaluate specific values from data for your application. Custom Conditions let you make the rules. We provide an extensive pack to get you started, but you don’t have to follow our rules. We’re not the boss of you! You decide what is good or bad for your environment. It’s good to be king isn’t it?
All of this is wonderful, but I wanted to go deeper. I had one more question. I wanted to know why the Custom Conditions builder sometimes felt more like I was building an application than using a designer. For this, I needed to talk to someone who eats, breathes, and sleeps code. Again, I knew exactly who to go to.
Brooke Philpott
Brooke is our Director of Software Development. He’s been here since the beginning, having written the first lines of SQL Sentry code. He’s also one of the best engineers I’ve ever known. I say this despite the fact that he didn’t like my idea of giving out branded Pop-Tarts at conferences during breakfast hours. If you would like to get Pop-Tarts from SQL Sentry, please make sure to tell Brooke what a great idea it is.
In talking to Brooke about the interface for building Custom Conditions, I learned a lot about how they work in the first place. They combine values derived from performance counters, expressions, queries, or explicit values to create logic that ultimately evaluates to ‘True’ or ‘False’. They can be fairly simple, or extremely complex. The idea was to provide an interface that allows for that wide range of options, but still lets you to put them together quickly. I believe that we have accomplished that objective well with the Custom Conditions interface.
Having this guy looking out for the needs of those who need to throw together a quick Custom Condition along with those who need to define complex logic for advisory purposes is sort of like having Elon Musk go to the store with you to pick up batteries during his break from designing electric jets.
My Epiphany
I think I’ve solved Brad’s mystery, but before I went back to fill him in, I was stopped in my tracks by an incredible realization. If I think back through my career, especially the early days, I wondered why I didn’t take more shortcuts. By shortcuts, I don’t mean “cutting corners” or skipping important details. What I mean is, early on, I tended to sometimes do things the hard way, for the sake of learning more, and preparing myself for the next challenge. I didn’t often look for things that gave me all the answers, or told me what to do. I was more interested in learning what to do myself, and why to do it.
Are any of you like that? Would you rather spend your time scripting a solution in T-SQL or PowerShell than clicking a few buttons on something that does it all for you? I’m betting there are more than a few of you who would. It just makes sense. We all want to be able to guarantee that we’ll continue to add value for our employers.
This is yet another reason that Custom Conditions are so great. You can apply what you’ve learned through experience, research, and training through the SQL Sentry monitoring engine to automate advisory needs for you and your team. Creating logic with Custom Conditions lets you apply what you know about SQL Server, SSAS, Windows, Hyper-V, and VMware to build out intelligent, event-driven advisory capabilities with SQL Sentry. Abstracted away for you is the data collection, and evaluation of the logic. Knowledge that you gain and use building Custom Conditions can be used to do things the hard way wherever you go. I hope you don’t have to do it the hard way, ever, but my point is that you’re not investing your time learning something that will never be useful again.
Back to the Mission
I finally made my way back to Brad. By now he was back in his office digging through about 14 spreadsheets. I told him all the things that I had discovered about Custom Conditions, and I could see that he really started to understand why things were designed and built the way they were.
Brad looked up from his spreadsheets, which I’m certain were filled with valuable insight about, well… all of you, and said “you should blog about that.”
So, there you have it. The case of “The Condition Mission” is solved. Let this blog post serve as the record for the case.
Until next time,
JRH
