• (nodebb)

    So Will was right after all. It WAS an SQL problem.

    (Otherwise, business as usual. Nobody wants to look at other people's code, nobody wants anyone to look at his/her code.)

    Addendum 2016-08-01 06:37: I think I forgot the obligatory

    SELECT * FROM Comments WHERE ordinalNumber = "FRIST"

    my bad.

    Addendum 2016-08-01 06:37: I think I forgot the obligatory

    SELECT * FROM Comments WHERE ordinalNumber = "FRIST"

    my bad.

    Addendum 2016-08-01 06:39: Neither does a preview exist nor does the page refresh automatically.

    (Unless the script for that is hosted at google-analytics.com)

  • Quite (unregistered)

    "A couple weeks after his departure, a coworker named Brad decided to take a look into the code himself."

    There's the blindingly obvious WTF -- that nobody had seen fit to look at Will's code before. That means: no peer review, no buddy system / pair programming, not even when it is tantamountly obvious that Will's code has "scaling issues".

  • Jonathan (submitter) (unregistered) in reply to PWolff

    We had a simple "monitoring" aspect to our system which once fully rolled out, logged about a million entries a day. At about 25% of rollout, the frontend became really slow to load. And while I was watching the the Task Manager on the SQL server box, I noticed it peaked transmitting at 1.2Gb/s. Turns out, a filter criteria which used a combobox on the front end was being populated by pulling all the rows out the database, then distincting those results in memory.

    While I still advocate for Entity Framework and LINQ-to-EF, it is unfortunately a downside of them that making a mistake like this is very easy. On the upside, with EF, it was also very easy to fix the problem too.

  • JustSomeDudette (unregistered)

    So the RWTF was the company and Will's co-workers, who instead of trying to help some clearly struggling they let him and the business suffer. GG WP.

  • Nate (unregistered)

    And this is why you never trust 90% of developers with database code.

  • RandomDude (unregistered)

    "Will wasn't getting any shiny certificates now. Ne was getting phone calls from department heads" --------------------------------------------------------------------^ He

  • Rohit (unregistered)

    In rewarding Will exclusively and disproportionately at the beginning, the group may have strengthened a false sense of pride and ownership, leading to isolation from peers. It may be that Will was unwilling to reach out for help for fear of losing exclusivity, and his colleagues, on their part, may have suffered from envy. This is a common pattern. The responsibility can be collective.

  • William Furr (google)

    You would think after years of reading The Daily WTF I would no longer be surprised at things like this that would never happen if these teams did code reviews. In my career in the same time period, I have never worked anywhere that didn't do code reviews.

  • Joseph Osako (google)

    Considering that most programmers I have worked with won't re-read their own code unless you put a gun to their heads, never mind review someone else's or let someone else review their own... yeah, TRWTF can be found in in any of our mirrors.

  • Appalled (unregistered)

    For the last 6 years I have never done a Code review . Fortunately my errors are few and far between and usually typos rather than design flaws.

    Why is this? It's a one-man shop, actually one Manager, two hardware people, and me as the Applications Programmer/DBA/Web Admin and a lot of the Server Admin.

    It's heaven. Just a teeny bit of bureaucracy with the End User Departments. Otherwise I do whatever the hell I want with zero interference.

  • Bert (unregistered) in reply to Appalled

    Is this relevant to the article, or just your way of saying "I am great"?

  • Ron Fox (google)

    Apalled - is your name Wile E. Coyote? Now we know where you went after this WTF.

    Seriously. He has a point. There are environments where peer review of code just isn't possible without adding staff the organization can't afford. ...that's when there's only one programming in the entire organization.

  • Guest (unregistered)

    Well. at least he was safe from SQL injection attacks.

  • Appalled (unregistered)

    Whether I'm great or not isn't the point. (I am). The point is the job is great and I can laugh at all you suckers and the crap you gotta put up with on a daily basis. That's the TRWTF, "How'd HE get so lucky?"

  • Foo AKA Fooo (unregistered)

    Gotta love the h-scrollbar for this very long and complex piece of code!

  • TheCPUWizard (unregistered) in reply to Appalled

    @Appalled - Not having some to review is horrible. There are time where I am a "one man shop" from at least the software perspective. It is at these times I bring in an intern [paid] for the primary purpose of Always having 4 eyes on all code.

  • Appalled (unregistered) in reply to TheCPUWizard

    OK, I gotta admit. I DO do the same every once in awhile (twice a quarter?) depending on criticality. I bring in the boss for a bit of pair programming. As we progress, she occasionally sees something I might have missed. Usually just typos which resolve in first Compile or Test, but sometimes "You sure you wanna do it that way?" She also gets to learn some of the new (to her) stuff I'm doing such as php and sql server. (Yes, this shop is SOOOOOOOOO old that that is New technology).

  • IamIT (unregistered)

    I work at a semi small business (9 offices with only the main office having more than 1 employee) where I am IT. I'm not a programmer, and we're not a software house (or I wouldn't be working here), but I do code up my own little utilities. I do a LOT of image handling from office to office. My tools are kludged together mainly using Perl, ImageMagick, and Tk/Tcl to give the end users some buttons to click. Granted there are failure modes in the some of the utilities that sometimes even I don't know how or why they happen. Looking back through the code I don't see anything that would make them even possible, but 99.95 of the time, they do what they're supposed to do, and we know how to handle the odd failures. By and large it works a lot better than the system that was in place when I was hired: Each person manually copied images to certain folders, burned them to a CD using a command line tool, then Fed-Exed them to the main office. Now at least they can open a familiar-looking window, click Upload, and the main office gets the images along with an inventory file. And I can spend my time repeatedly explaining to other users that you can't change a PDF into an editable Word doc by renaming it to file.pdf.docx......

  • EatenByAGrue (unregistered)

    All sorts of problems here:

    1. This should never have gotten through code review.
    2. Of course, it didn't, because there wasn't a code review with anybody competent enough to see how obviously boneheaded that code was.

    I have to admit, though, I guessed wrong as to the problem: I was figuring it was a missing index that wasn't noticed in a non-production environment because the test environments didn't have all the data of production, leading to table scans on what seemed like sensible SQL. Little did I know that this was one of the fools for whom a "WHERE Clause" was something for experts only.

  • Guest (unregistered)

    The RWTF is that people saw something that started working fine and over time grew sluggish and didn't immediately realize where the problem was. Pretty obvious that the program was choking on historical data, which meant the problem was with how the historical data was making it into the application. Irony is that with how optimized every other bit of the application ended, fixing the source of the issue would make the feature extremely lightweight. Maybe someone was waiting for Wile to quit so they could come in and get all the glory.

  • Ry (unregistered) in reply to Appalled

    Nice Appalled, sounds like a sweet gig. A bit like giving a toddler their own play room to build Lego in all day.

  • Developer Dude (unregistered)

    WTF? Will didn't ask for help? He didn't ask someone to do a sanity check on his code? No lead or manager asked any other dev to look at his code? They just let him fail? Repeatedly?

  • Appalled (unregistered) in reply to Ry

    Yes it is sweet. Sweetest of my 40 year career. I can actually feel good about my productivity. And you're an ignorant (how couldn't you be, it's MY job not yours) and jealous ^@#&. Lego's? This small (400+) Manufacturer went from 120 million to 180 million gross during my 6 year tenure. You think they did it in SPITE of me. Actually they couldn't have done it WITHOUT me. I'm freaking brilliant. Tell you what. I'm retiring this year or next. Let's open the bidding. Highest bidder gets the name and address of this place where they can continue the tradition.

  • Barf 4Eva (unregistered) in reply to Jonathan (submitter)

    Just as easy to fix on the DB side in a stored procedure or some view. Actually, perhaps easier if your application deployments take longer than database pieces to release in to the wild. In addition, your issue is limited to the database and not going to be as much a burden on the etwork... which has its pros and cons as well, I guess.. :P

  • Matt Westwood (unregistered) in reply to Appalled

    I'd rather eat puke than breathe anywhere you've been within 15 miles of.

  • (nodebb) in reply to IamIT

    you can't change a PDF into an editable Word doc by renaming it to file.pdf.docx

    Really? Looks like Plan A is a no-go in that case…

  • Jack (unregistered) in reply to Appalled
    Appalled:
    Let's open the bidding. Highest bidder gets the name and address of this place where they can continue the tradition.

    I bid $1. Y'all naysayers don't wanna be anywhere near where this guy has been, stby. Gonna get that cushy job for myself!
  • Sevalecan (unregistered) in reply to Guest

    Well, hindsight is always 20/20. If I were experiencing that problem, I can see having a brain-fart and it not being completely obvious, but with another person saying "Well if it gets slower with more data, ..." it would seem obvious.

    That said, I think TRWTF is the lack of analytical skills. Whenever I debug something, I tend to try and narrow down where the issue is in code first. This could've easily been done by doing some profiling to analyze the problem. I may not be a professional programmer, but that type of analytical approach to a problem seems obvious to me.

  • Olivier (unregistered) in reply to IamIT

    And I can spend my time repeatedly explaining to other users that you can't change a PDF into an editable Word doc by renaming it to file.pdf.docx......

    Of course not, we all know you should rename file.pdf into file.docx, it never works with double extension.

  • Pieter B (unregistered)

    I thought programmers know what a profiler is. Guess not.

  • Ex-lurker (unregistered) in reply to Jack

    That's a great idea! If Appalled's ego is anything to go by, you'll have submission material enough to keep this site running for years. Maybe a decade.

  • b.a. freeman (unregistered) in reply to William Furr

    lucky coder. i have never worked at any place that THOUGHT about doing code review, let alone actually doing it. i'm sure there are lots more places run badly than places that are run well, or even run somewhat according to best practices.

  • KZilla (unregistered) in reply to Appalled

    I think you're the real sucker doing the job of 4 for the price of one.

  • WhySQL (unregistered) in reply to b.a. freeman

    Agreed. I do my own code reviews: I work in a small team and am the only full-time software engineer. First I get the functionality up and running, and passing all tests. Then after a month or so, or whenever requirements change, I review my code. And more often than I'd like, I go, WTF?

  • reviewer (unregistered)

    Where I worked, code reviews were a chance to hang shit on other programmers, and explain what a bad job they had done. Kind of the like The DailyWTF. No sane person coming out of that environement would ever consent to a code review.

  • missing it (unregistered)

    For me, the article ends with a line saying

    SELECT * FROM Users

    Have I had too much to drink that I don't see the punchline in that, or is there actually something missing?

  • Appalled (unregistered) in reply to missing it

    It would have been nice with a little more context. It's all guess work and inference. Obviously Select * is frowned on. Only get the columns you use. But it had to be more than that. The only useful clue I saw was the word Filters. So, guessing away at it, why would a Select every column for every User be in the "Filters" area of the code. Obviously the number of Users increased rapidly over time. How many columns in that table? How big? god forbid any BLOBs but a couple of Char(2000) for Comments or Notes wouldn't be pretty. Especially times 500,000 Users, if "Users" meant the unique visitors to the sites they were monitoring. Final guess is I'll bet that Select All was a debugging remnant he forgot to shut off totally. I.e. he turned of the display logic but left the damn SQL alive and doing nothing useful or visible for the application.

  • tgape (unregistered) in reply to Quite

    Back in the day, I did unsolicited reviews of code my coworkers were having performance issues. I think there was only one time when I didn't find some major, obvious issue. And there were only a couple of times when it didn't result in the person with the slow code being really angry. Whether I was the primary target, or if the anger was simply misplaced on me doesn't matter: I learned my lesson, and I don't do that these days.

  • Dellappa (unregistered) in reply to Appalled

    gr8 b8 m8

  • tgape (unregistered) in reply to missing it

    The SELECT * FROM Users is probably not the real problem, though it is a horrible practice which fundamentally misses the point of a database. However, anyone who does understand the point of a database will never do that even on small tables, because there's no point - it's easier to have the database pull just the information you want than it is to write code to filter that out of the data.

    SELECT * FROM Data, on the other hand, inevitably follows the prior code smell. They didn't get it where it didn't matter, they still don't get it when it does. That code will be blazingly fast when the database only contains the data the process wants, but it's not going to do well once the database contains mostly unwanted data. Sometimes, SELECT * is the right approach, because you really do want all the columns. But just about any SELECT without a WHERE is a problem.

    Note that SELECT * FROM Dual *does* have at least one problem, but it's not the size of that table, so long as you're using the database that made that a standard table.

  • Guillaume Goulet-Vallieres (unregistered)

    Wow, this company needs a DBA/Dev. guy ASAP .... it should have taken then a single hour to find the root cause......

  • Guillaume Goulet-Vallieres (unregistered) in reply to tgape

    Never ever do SELECT * in production code... you alter the table and boom your code can fails... SELECT every column you want/need.

  • MarkSG (unregistered) in reply to EatenByAGrue

    "Select * from TABLE" is kind of the equivalent to a missing index, though. It's the same false assumption: that what works in dev with sample (and known quantities of) test data will work in live with unknown quantities of data. But either way, it's indicative of sloppy SQL.

  • MarkSG (unregistered) in reply to EatenByAGrue

    "Select * from TABLE" is kind of the equivalent to a missing index, though. It's the same false assumption: that what works in dev with sample (and known quantities of) test data will work in live with unknown quantities of data. But either way, it's indicative of sloppy SQL.

  • No Name here (unregistered) in reply to EatenByAGrue

    You should never do "SELECT * FROM..." in code. NEVER. Write down the columns that you want, in the order you want, ONCE.

    It is even more performant...

Leave a comment on “Super Lag”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article