Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

The Worst Code Expand / Collapse
Author
Message
Posted Tuesday, March 18, 2014 10:35 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 9:37 AM
Points: 5,819, Visits: 3,737
John Hanrahan (3/18/2014)
Well maybe close to the worst code I have ever seen was written by me. We had 16k of room to print out a large document in an old version of BASIC. I kept running out of memory space trying to print it so the code ended up with more GOTO's than sand grains in a small beach. I SWEAR there was no other way to write it but when one of the other programmers had to upgrade it to a newer version of that BASIC he was not 'happy'. I actually felt fortunate that I was his boss at the time as otherwise I would have had to upgrade the code.


Love the honesty. I have written bad code. Its just that I have seen worse. That says more about them than me.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1552309
Posted Tuesday, March 18, 2014 10:49 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 11:21 AM
Points: 1,793, Visits: 5,044
Whether the worst code we've ever seen was somebody's elses or ours is not what's important. We have to own our code, just like we own the responsibility of our kids. We can examine our own stored procedure that been running "just fine" in production for years and make it run 2x faster by day's end, or we can spend forever pointing out flaws in someone elses code and accomplish nothing.
Post #1552316
Posted Tuesday, March 18, 2014 10:51 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, August 15, 2014 9:32 AM
Points: 7, Visits: 41
The article is so true. I've been a developer since before the COBAL and Fortran days and long before the interactive programming days came along. But there is one thing I'll always remember from my first Programming 101 course: my instructor told us up front that coding is like making pancakes, the first program is always for throw-away! The batter's not correct, the griddle is not hot enough, etc. The dog gets the first pancake!

Unfortunately, most of our employers don't want to pay us to make the second pancake even when we learned from our first attempt exactly how to make the perfect second one.

Also unfortunately, most of us figured out that we always learned from each additional pancake flipped that there was an additional pancake that we could make that would be so much better than the last. And it is this knowledge that can frustrate the hell out of you the longer you program.
Post #1552317
Posted Tuesday, March 18, 2014 11:10 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 9:37 AM
Points: 5,819, Visits: 3,737
thood1 (3/18/2014)
The article is so true. I've been a developer since before the COBAL and Fortran days and long before the interactive programming days came along. But there is one thing I'll always remember from my first Programming 101 course: my instructor told us up front that coding is like making pancakes, the first program is always for throw-away! The batter's not correct, the griddle is not hot enough, etc. The dog gets the first pancake!

Unfortunately, most of our employers don't want to pay us to make the second pancake even when we learned from our first attempt exactly how to make the perfect second one.

Also unfortunately, most of us figured out that we always learned from each additional pancake flipped that there was an additional pancake that we could make that would be so much better than the last. And it is this knowledge that can frustrate the hell out of you the longer you program.


I never let the dog eat the first pancake...I like it!!!

What does that say about my code?


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1552327
Posted Tuesday, March 18, 2014 11:19 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: 2 days ago @ 12:25 PM
Points: 29, Visits: 232
I love the pancake analogy. It perfectly describes my first attempts. The problem I see is too many developers never throw away that first pancake but add tons of syrup and toppings to cover for the crappy pancake and in the end, you get really sick eating the thing.

Translation: to support a bad application we, as DBAs are forced to try and tune the database instance and hardware to make up for the bad code and we end up with a monster server for a solution that could have run faster on a tenth the resources.
Post #1552332
Posted Tuesday, March 18, 2014 4:07 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 6:20 AM
Points: 2,923, Visits: 1,874
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


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1552425
Posted Tuesday, March 18, 2014 5:36 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, August 15, 2014 9:32 AM
Points: 7, Visits: 41
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.
Post #1552431
Posted Tuesday, March 18, 2014 6:12 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: 2 days ago @ 9:53 PM
Points: 3,438, Visits: 5,390
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)
- 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 mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

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?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1552437
Posted Wednesday, March 19, 2014 6:08 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 9:37 AM
Points: 5,819, Visits: 3,737
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!!!
Post #1552584
Posted Wednesday, March 19, 2014 7:37 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 11:21 AM
Points: 1,793, Visits: 5,044
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

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.
Post #1552609
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse