August 28, 2015 at 4:28 pm
Andy Warren (8/28/2015)
Mickey, I try to put stuff like that on a list, helps me feel a little more in control, and sometimes when I need a break I'll grab one and work on it even if it's not the most important thing.
I have a list like that, myself. There are a number of improvements I'd like to make, but they aren't really urgent. I usually tackle one of them when I need a break or on that rare occasion when I'm all caught up and a break introduces itself. I've had some good breakthroughs during those times.
August 30, 2015 at 1:42 pm
If you approach everything with the notion that nothing is perfect, that we all write bad code and we can always write better code. Then you will find a lot of problems that you can start addressing and fixing.
But, I agree, you cannot solve everything. Sometimes you have to accept when something is good enough and move on.
August 30, 2015 at 2:25 pm
Conversations like this strike me in an odd way. If there's a performance problem, the first thing people do is blame the database and if it takes more than a minute to fix, they blame the DBA.
What really needs to happen is all the "developers" and their "managers", front-end or otherwise, need to get over their damned selves and start working with the DBA in what people are now calling "DevOps" (which is actually as old as the hills). If you're not going to listen to the resident expert (the DBA) on all things SQL, then don't blame that person when the proverbial poo hits the fan.
The "developers" and the "managers" all need to learn that it's actually pretty easy to write good database code (embedded or otherwise) and it doesn't take very long to come up with a plan for what the database needs to look like but will save hundreds of hours fixing stuff after it somehow makes it to production. Even better, it won't be the customer that finds the problem if you do it right.
All you need is people that have a little more "problem solver" in their blood because problem solvers aren't the problem... it's the people that keep creating the same problems over and over again that are the problem. I especially love it when some knucklehead will take a huge amount of time to justify what he thinks is "good enough code" when it would take just a small fraction of that time to say "No problem" and then fix the code.
I also get a bit ticked when someone accuses a DBA of chasing windmills and unicorns when they do actually try to make something run in (as the given example) 100ms instead of 1 second (although I usually shoot for and achieve two orders of magnitude improvement). Just stop and think about that. If everyone knew how to write code like that the whole server would be 10 times faster which means the application would also be 10 times faster. Let's see you buy hardware that will do that. You'd have to buy MPP AND rewrite the code to use it correctly anyway. It just doesn't take that much time to write good fast code. "Mind the pennies and the dollars will take care of themselves".
I do agree that some things are more important than others and that the most important things should be fixed first but, if it's broke, fix it now. If it's not broke but is poor, fix it next in order of "poorness". In this day and age of ultra fast parallel processors, more memory than you can shake a stick at, and lightning fast hard disks, there's only one reason for performance problems. Crap code. Don't let it get to production and fix it when you find it... and you should always be looking for it.
And remember that preventing problems is always much more efficient and effective than finding and then solving problems, especially at month end at the customer site. 😉
Ok... here come the excuses... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 30, 2015 at 9:36 pm
Jeff Moden (8/30/2015)
I do agree that some things are more important than others and that the most important things should be fixed first but, if it's broke, fix it now. If it's not broke but is poor, fix it next in order of "poorness". In this day and age of ultra fast parallel processors, more memory than you can shake a stick at, and lightning fast hard disks, there's only one reason for performance problems. Crap code. Don't let it get to production and fix it when you find it... and you should always be looking for it.And remember that preventing problems is always much more efficient and effective than finding and then solving problems, especially at month end at the customer site. 😉
Ok... here come the excuses... 😉
Amen. Unfortunately, I get the feeling that more "crap code' gets into production than problem solvers like us are able to remove/replace with better code. It is sort of like an uphill battle. The on-going quest for more and more systems, with deadline pressures and what not just keep everyone behind the curve.
But then again, what would us problem solvers do if not for this. :w00t:
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
August 30, 2015 at 11:30 pm
I use the analogy of cost-based heuristics of the SQL Server query engine. It doesn't always choose the most efficient implementation of a query, rather just one that is fast enough within an acceptable given period of time. Otherwise the query engine would never get anything done while it went through all permutations comaring efficiency.
So when allocating resources, say to optimise a stored procedure, much as I would love 2 weeks' to get its execution-time down to 10ms, I will be satisfied if I can get it down to 25ms within a day or two.
In short, problem solvers have to learn to efficiently use the resources at hand and learn to define what «good enough» is. Experience and further learning greatly help in getting better results in teh same or faster times.
August 30, 2015 at 11:58 pm
PAH» Your comments "Better to listen and nod in most cases." remind me of a brief dip into the book Men are from Mars, Women are from Venus. one of the few things I understood was when a woman tells a man a problem she doesn't necessarily want it fixed she wants him to understand what she has to put up with.
I am sure this is a massive over generalisation but it does lead me to realise that just because there is a problem it does not necessarily need fixing.
Dilbert has this already covered: http://dilbert.com/strip/1996-07-16
August 31, 2015 at 1:25 am
I finally found my diagnosis... I have never related to an article as much as this, brilliant read.
Thanks Andy!
August 31, 2015 at 6:20 am
Sean Redmond (8/30/2015)
I use the analogy of cost-based heuristics of the SQL Server query engine. It doesn't always choose the most efficient implementation of a query, rather just one that is fast enough within an acceptable given period of time. Otherwise the query engine would never get anything done while it went through all permutations comaring efficiency.So when allocating resources, say to optimise a stored procedure, much as I would love 2 weeks' to get its execution-time down to 10ms, I will be satisfied if I can get it down to 25ms within a day or two.
In short, problem solvers have to learn to efficiently use the resources at hand and learn to define what «good enough» is. Experience and further learning greatly help in getting better results in teh same or faster times.
I guess what is "good enough" depends on the situation. If you have something that runs once a day, 25 ms is probably good enough. If, on the other handle, it runs 41 times a second, I don't think 25 ms is good enough if 10 ms can be attained.
August 31, 2015 at 6:37 am
I wanted to make the point that one has to remember time-constraints.
Many problem-solvers are perfectionists and they want nothing but the perfect query. It may take them 2 weeks when the extra performance gained is not matched by the time invested in achieving the perfect query, hence the comparison with the heuristics used by the Query Engine. The QE may not always choose the perfect execution plan but it is usually good enough given the time constraints. The advent of sprints and deadlines that are not too far away has made such time constraints even more important to developers.
Then again, your point is also valid. It may also be the case that «good enough» is not good enough. With a core query that is run many times each second and is responsible for locking core tables and making other queries wait, every millisecond counts. This is where an experienced DBA / developer / data-architect knows that the two weeks invested in getting the query optimised as much as possible will save more time down the line.
August 31, 2015 at 6:43 am
Marco, that's terrific, always nice to hear that something resonates.
August 31, 2015 at 6:51 am
Jeff,
I wonder if the life of a DBA isn't different than most because of the complexity compared to other systems. I'm not an Exchange/Sharepoint/whatever/whatever guy, but it sure seems more like those systems don't require (or get) the kind of low level tuning that we sometimes need to do. If (big IF) that's the case, then as the outlier we get stuck with the expectation that we're like those systems (set it and forget it) and once they realize it's not that easy, they want it to be that easy and start thinking about text files and NoSQL.
As far as problem solving though, I still see the challenge as being that of harnessing the potential of a problem solver. Somewhere between "do whatever you feel like doing" and "don't change anything" is a place where the PS is happy and useful and the business is getting the right ratio of gain to pain.
August 31, 2015 at 8:49 am
Jeff Moden (8/30/2015)
Conversations like this strike me in an odd way. If there's a performance problem, the first thing people do is blame the database and if it takes more than a minute to fix, they blame the DBA.What really needs to happen is all the "developers" and their "managers", front-end or otherwise, need to get over their damned selves and start working with the DBA in what people are now calling "DevOps" (which is actually as old as the hills). If you're not going to listen to the resident expert (the DBA) on all things SQL, then don't blame that person when the proverbial poo hits the fan.
... (removed for brevity sake)
And remember that preventing problems is always much more efficient and effective than finding and then solving problems, especially at month end at the customer site. 😉
Ok... here come the excuses... 😉
@jeff Moden, I am a "developer" (21 years experience, 20.5 years SQL experience). No excuses here. I say if you are currently in this kind of situation then find a new employer. Of course, that is only if you actually know your stuff, which it sounds like you do because otherwise you probably wouldn't realize that the situation you describe is unacceptable. 😉
I tend to listen to my DBAs. If what they say makes sense, I run with. If not, I do more research and test it myself in which case it usually ends up 50/50 on who is right. Even in the situations where the DBA's suggestion made sense, there are a few times where it turns out wrong. However, in the end I would say that the DBAs are right 85-90%.
@My-fellow-developers: Lesson here is that you should trust your DBAs, unless and until they prove otherwise. If you do find a case where the DBA was wrong, share it with them in a way that shows you are trying to make the whole team better, not that you are trying to prove that you are better. Amazing how willing people are to listen when approached this way. Actually a good approach to any situation.
Now, if you are stuck with someone who is continuously wrong and perpetually resistant to feedback (and you give the feedback the right way), then you need to document that to cover yourself and stop asking for help. If the "help" is forced on you anyway, document the before and after (results/performance/etc), what your objections were, and what the reply was to your objections. Be fair and document when you objected but YOU were wrong. If it turns out you are usually wrong, then be mature enough to accept it. If it turns out you are usually right, the next time "help" is forced on you, go to your manager and share your documentation in a professional way. If your manager doesn't back you up, at least you can (politely) tell him/her "I told you so" when it goes south. Your manager will either begin to listen to you and push back so that they don't look bad or you will find that it is time to look for a new employer.
The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end, there it is.
- Winston Churchill
Quick. Accurate. Inexpensive. Pick TWO
August 31, 2015 at 1:37 pm
Eric M Russell (8/28/2015)
... I spend my days in an office working with other IT professionals, not hanging out at a coffee shop with friends or watching episodes of Oprah and Dr. Phil. That said, people do often come to me for advice, not about IT junk, but stuff in general. However, at that point it's advice they're looking for.
Now, if it were Dr. Phil Factor....
😛
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
August 31, 2015 at 2:31 pm
This was fun to read. I saw myself through out the brief article. Keeping in mind that not all problems presented to us are done so to get a solution is important when the person telling us is our spouse.
August 31, 2015 at 2:38 pm
Iwas Bornready (8/31/2015)
This was fun to read. I saw myself through out the brief article. Keeping in mind that not all problems presented to us are done so to get a solution is important when the person telling us is our spouse.
When dealing with civilians (non IT people whom you don't work with), then a different set of social rules apply. Team rules don't work on spouses, and spouse rules don't work on team members.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 16 through 30 (of 46 total)
You must be logged in to reply to this topic. Login to reply