March 18, 2014 at 4:07 pm
My thought question: Have you ever been told that your query runs too fast?
YES. Our chief exec stood up before the entire company and said that a web site feature had had to have a delay introduced into it because the DB returned results so fast the customers didn't believe it was working:-P
March 18, 2014 at 5:36 pm
Your executive was probably somewhat correct. If the normal response to activities on your inter/intranet are at one general speed then both a slow response activity AND a fast response activity are perceived by users as abnormal. You really do need to 'normalize' all activities to maintain credibility. I know this goes against the grain, but you really do have a duty to look at things from your user's point of view. And unfortunately their view is what pays the freight.
March 18, 2014 at 6:12 pm
SQLRNNR (3/18/2014)
dwain.c (3/18/2014)
Oh God Steve, don't get me started!Good editorial!
Oh please - get started Dwain 😉
If you insist Jason. 😛 Bad code can be judged on many levels (some of which previous posters have alluded to):
- Doesn't meet the functional requirements
- Generally meets the functional requirements but is riddled with defects when it reaches UAT (and/or SIT).
- Isn't fast
- Isn't pretty (Make it Work, Make it Fast, Make it Pretty[/url])
- Is unmaintainable (for some of the reasons mentioned above)
- Is not extensible (but not too extensible so as to be developed out-of-budget)
- Doesn't have full functional coverage. For example, perhaps the development team didn't want to add a "delete transaction" button because that would have been too difficult, so instead the package comes with a support contract that allows for those cases where a delete is required but handled by "painstaking" analysis/scripting
IMHO, a lot of this comes out of two issues:
- Software engineering (a somewhat laughable term, again IMHO) has yet to achieve the level of maturity that other engineering disciplines have long ago achieved, despite 40+ years of practitioning.
- Instruction in software development, usually in a university or possibly a company specializing in training, is rarely conducted by expert software developers. "Those that can do, those that can't teach."
Now you see why I suggested you don't get me started.
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
March 19, 2014 at 6:08 am
thood1 (3/18/2014)
Your executive was probably somewhat correct. If the normal response to activities on your inter/intranet are at one general speed then both a slow response activity AND a fast response activity are perceived by users as abnormal. You really do need to 'normalize' all activities to maintain credibility. I know this goes against the grain, but you really do have a duty to look at things from your user's point of view. And unfortunately their view is what pays the freight.
I trust that the delay was put in the web page and NOT with the query!!!
Just in case it is uses elsewhere.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 19, 2014 at 7:37 am
David.Poole (3/18/2014)
My thought question: Have you ever been told that your query runs too fast?
YES. Our chief exec stood up before the entire company and said that a web site feature had had to have a delay introduced into it because the DB returned results so fast the customers didn't believe it was working:-P
If the response time of a data driven website is too fast, some users may abuse it by repeatedly clicking and posting-back. I'm thinking something like a live traffic, auction, or stock trading website. So, I can see the need to leverage something like javascript to delay the enabling of submit button, links, etc. to few seconds after page load.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 19, 2014 at 7:45 am
Eric M Russell (3/19/2014)
David.Poole (3/18/2014)
My thought question: Have you ever been told that your query runs too fast?
YES. Our chief exec stood up before the entire company and said that a web site feature had had to have a delay introduced into it because the DB returned results so fast the customers didn't believe it was working:-P
If the response time of a data driven website is too fast, some users may abuse it by repeatedly clicking and posting-back. I'm thinking something like a live traffic, auction, or stock trading website. So, I can see the need to leverage something like javascript to delay the enabling of submit button, links, etc. to few seconds after page load.
<CTRL><F5> Will often get around that. Caching the data in the application tier is sometimes a reasonable solution. Especially as you can configure firewalls to block too many repeated requests from the same IP address i.e. stopping Denial of Service attacks.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 19, 2014 at 5:03 pm
Gary Varga (3/19/2014)
I trust that the delay was put in the web page and NOT with the query!!!
Normal coding practises ensure any excess performance is bled off:rolleyes:
March 20, 2014 at 9:31 am
David.Poole (3/19/2014)
Normal coding practises ensure any excess performance is bled off:rolleyes:
That's a great quote. Now if there were only a way to make developers avoid doing this....
December 19, 2017 at 1:25 am
Some of the worst code I've seen is mine but I didn't know it was bad at the time I was writing it. The Daily WTF site[/url] is good at pointing out awful code but it isn't so good at taking people through why a particular set of code is bad.
There's definitely a place for a website that walks through bad code and explaining how it should be done.
December 19, 2017 at 4:26 am
David.Poole - Tuesday, December 19, 2017 1:25 AMSome of the worst code I've seen is mine but I didn't know it was bad at the time I was writing it. The Daily WTF site[/url] is good at pointing out awful code but it isn't so good at taking people through why a particular set of code is bad.There's definitely a place for a website that walks through bad code and explaining how it should be done.
I'm not so sure. While it may help prevent horrible practices, it's also inevitably going to prevent innovation and adoption of new better patterns than what have been considered best-practices in the decades before. The daily wtf finds a good middle-ground in my opinion, since it points out the issue without prescribing a solution.
December 19, 2017 at 8:23 am
I've written some less than optimal code, in fact I have some going into production soon because I was told it was good enough and I was needed elsewhere. (I've been forbidden to refactor and improve it...) :sick:
The absolute worst code I've seen was back in the Web 1.0 days. My boss bought a third-party report generator for Cold Fusion that include source code. It was very broken and slow. Two massive highlights were the variable names based on characters and themes from TV westerns. And nested loops instead using Select Distinct... :crazy:
December 20, 2017 at 3:54 pm
Any Craftsmen worth his weight, can look at something he has made and say to himself; I could have done better.
The longer the time between the time he finishes and the time he looks at it again the more he finds he could have done better.
For Craftsmen the reason for this is we strive to learn with everything we do, we strive to be better at our craft.
Once you no longer think you can do better, you have lost your passion and should think about retiring.
December 20, 2017 at 4:51 pm
Here, here! To rephrase my pancake argument from several years back, no matter the level of planning, the level of quality assurance or the number of peer reviews that precedes the formal submittal, almost instantaneously thereafter your mind will play the dastardly trick on you to remind you that you could have produced a much more elegant solution simply by just .... And as more time passes and you continue to grow you will realize there continues to be many more elegant solutions both due to increased technical competence and frequently due to increased technological advances. Most peers take advantage of both.
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply