It's clustered, Jr!



  • I submitted this as a daily WTF but it did not get posted, so I figured I would share the story here.



    Recently a client, Biller Cunts (as I like to refer to them, due to their employment base being 99% female and extremely mean/rude/etc), was complaining about slow performance in an application, that was (you guessed it) written by a friend of one of their higher ups.



    After receiving this report, we of course did performance analysis of their SQL server and network. We found the server was bottlenecked about 85% of the time waiting on disk I/O. For weeks, we tried all the different configurations and optimizations we possibly could to improve disk performance to no avail. We got the server reading at an average of 60 or so MB/sec (that's megabytes, not bits), which in our opinion was very good for a RAID 5 array running from an onboard controller with 128 MB cache. We could not optimize anymore other than to recommend the client upgrade their hardware. The application was still running slow and the client was growing increasingly unhappier.



    Our theory was the server was spending all of its time reading from the disk due to poorly coded software, poorly written SQL queries and bad database design. At this point, we wanted to go through the database design and make recommendations, but the client would not allow it. We informed the client of this and our theory why the performance was slow and of course the client had a theory for the issues as well (or rather, an anti-theory) - "We have no idea what is going on but at this point I am finding it hard to believe that all of our problems are related to the [application name] software", M wrote.



    And so we ran SQL Server Profiler (because the client had no idea what it did, they allowed it) and watched the horror of the database queries that were unoptimized, riddled with LEFT OUTER JOINs, and constantly querying based on unindexed columns. We informed the client about the performance data we gathered from SQL Server Profiler and pointed out where the program would run the same poorly written query, that took 50 seconds to execute, not 1, not 2, but 6 or 7 times in a row, no more than a second after it had received the results from running it the previous time. But the client insisted "[application name] is not the cause of all of the problems", "we need to have a pow wow again".



    At this point we looked through the database design (while the client wasn't looking), since we couldn't look through the code, and found amazing table definitions like the following:




    CREATE TABLE [dbo].[Client Info](

    [Id] [int] IDENTITY(1,1) NOT NULL,

    ...

    [Jr] nvarchar NULL,

    ...

    CONSTRAINT [aaaaaClient Info3_PK] PRIMARY KEY NONCLUSTERED (

    [Id] ASC

    ))...



    CREATE CLUSTERED INDEX [Client Info1] ON [dbo].[Client Info] (

    [Jr] ASC

    )



    CREATE TABLE [dbo].[Unit Entries] (

    [ID] [int] IDENTITY(1,1) NOT NULL,

    ...

    [File Number] nvarchar NULL,

    ...

    CONSTRAINT [aaaaaUnit Entries_PK] PRIMARY KEY NONCLUSTERED (

    [ID] ASC

    ))...



    CREATE CLUSTERED INDEX [Unit Entries11] ON [dbo].[Unit Entries] (

    [OrgID] ASC,

    [File Number] ASC

    )




    There were many more just like it. The next time the client asked why their network (read [application name]) was running slow, I couldn't help but respond: "It's clustered, Jr!"



  • I just read up on MS SQL's requirement for [ and ], as far as I can tell it isn't necessary for names like OrgID, but for names like Unit Entries11 it is (because of the space), so why does every identify on every MS SQL query I've seen here have those hideous things every-fuck-where?



  • @Lingerance said:

    I just read up on MS SQL's requirement for [ and ], as far as I can tell it isn't necessary for names like OrgID, but for names like Unit Entries11 it is (because of the space), so why does every identify on every MS SQL query I've seen here have those hideous things every-fuck-where?

    Probably because, when you ask SSMS to generate a script for you, it puts them there for everything (I guess it's easier/more consistent than only adding them if it finds a space in the identifier. So a lot of what you've seen is probably copy-and-pasted from SSMS.



  • Indeed, I used SSMS to generate what I copy pasted for the snippets above. If that is fail, I apologize.



  • @Lingerance said:

    I just read up on MS SQL's requirement for [ and ], as far as I can tell it isn't necessary for names like OrgID, but for names like Unit Entries11 it is (because of the space), so why does every identify on every MS SQL query I've seen here have those hideous things every-fuck-where?
    You could say the same thing about MySQl and back ticks



  • @npinchot said:

    Indeed, I used SSMS to generate what I copy pasted for the snippets above. If that is fail, I apologize.
    I wouldn't apologize for SSMS .. I think it's a great product and love it for long time whenever I do MS SQL work.



  • @OzPeter said:

    You could say the same thing about MySQl and back ticks
    I haven't seen a MySQL query with backtics in 6 years. But yeah, I remember seeing every query like that, at least they're more subtle.



  •  Wait, so, let me get this straight:

    1. "Application XYZ is slow!"
    2. "We've optimized the harware, it's the application."
    3. "It can't be the application!"
    4. "Can we verify that?"
    5. "No, it's not the application!"
    6. "According to the database profiler, it's the application."
    7. "No, it's not the application!"
    8. "Further, according to the database tables, it's the application"
    9. "No, it's not the application!"

    If that's correct, I will hypothesize the Epilogue to this, uh, clustered fuck:

    1.  "We've found another consultant who agrees that it's not the application, so we no longer need your services."
    Edit: I should like to point out that I don't actually know what the CLUSTERED/NONCLUSTERED bits are, since my database experience is limited to MySQL. But, I assume it's one of those "It's here, in the off-chance that you know what limited circumstances it's a good thing to use in" things.


  • You can lead a horse to water, but you can't make him drink.

    Client's like that will go through many service providers, replacing those that don't tell them what they want to hear, and those that tell them what they want to hear but can't fix the problem via any other mechanism. Either way you're f*ked. You may as well not take crap over it.



  • @pkmnfrk said:

    Edit: I should like to point out that I don't actually know what the CLUSTERED/NONCLUSTERED bits are, since my database experience is limited to MySQL. But, I assume it's one of those "It's here, in the off-chance that you know what limited circumstances it's a good thing to use in" things.


    I believe that clustered index is the one which's used to define order of the rows on-disk. I think in MySQL order is either random, or dictated by the PK?



  • @pkmnfrk said:

    Edit: I should like to point out that I don't actually know what the CLUSTERED/NONCLUSTERED bits are, since my database experience is limited to MySQL. But, I assume it's one of those "It's here, in the off-chance that you know what limited circumstances it's a good thing to use in" things.




    As bannedfromcoding pointed out, the clustered index will set the row order on the physical disk. Clustered indexes aren't the devil in and of themselves, and all of the Microsoft database designer tools that I know of will create a clustered index on your PK by default when designing a table. It is however, the devil to set a clustered index on a VARCHAR that has 95% of its data null and then not index the columns that you are using in your WHERE clauses. Oh and not a single one of the UPDATE statements sent by that application uses the PK to find the record it is updating.



  • @npinchot said:

    Oh and not a single one of the UPDATE statements sent by that application uses the PK to find the record it is updating.

    Then what DO they use? And is it unique?



  • @bannedfromcoding said:

    @npinchot said:
    Oh and not a single one of the UPDATE statements sent by that application uses the PK to find the record it is updating.

    Then what DO they use? And is it unique?



    Unique? Yea right. The UPDATE statements use WHERE clauses similar to what you would expect to see when a user was searching for data. Dates, Type Ids, Customer Ids, etc.


  • @snoofle said:

    You can lead a horse to water, but you can't make him drink.

    Client's like that will go through many service providers, replacing those that don't tell them what they want to hear, and those that tell them what they want to hear but can't fix the problem via any other mechanism. Either way you're f*ked. You may as well not take crap over it.

    Well Put.

    Honestly from my experience it is best to show up on their doorstep (suck it up) with a few people and lots of flashy gadgets and laptops. Do your work, say were going to assume nothing and test every possibility. Say we found the problem: This query is running incredibly slowly caused by application XYZ it is destroying your database and we have hardware that can possibly optimize it but it will cost u a few hundred million dollars, no promises. However you can solve the software problem for a few days worth of work (hopefully).

    The idea is to give them some VIP treatment so they feel special and are more likely to listen to you, even if it is the same exact thing you already told em. We did that a few times and it works.



  • @npinchot said:

    Biller Cunts
     

     Fucking hilarious!



  • @Lingerance said:

    @OzPeter said:
    `You` `could` `say` `the` `same` `thing` `about` `MySQl` `and` `back` `ticks`
    I haven't seen a MySQL query with backtics in 6 years. But yeah, I remember seeing every query like that, at least they're more subtle.

    Then clearly you haven't seen a file made with mysqldump.  Or a schema generated by most programs.  Or a binlog.



  • @morbiuswilters said:

    Then clearly you haven't seen a file made with mysqldump

    I generally don't look at those. If it imports correctly and I can query for the same data when I test loading it then I have no need to.
    @morbiuswilters said:
    Or a schema generated by most programs.

    We do all ours by hand.
    @morbiuswilters said:
    Or a binlog.

    ... this I'm curious about. Why would I look at that?



  • @npinchot said:

    As bannedfromcoding pointed out, the clustered index will set the row order on the physical disk. Clustered indexes aren't the devil in and of themselves, and all of the Microsoft database designer tools that I know of will create a clustered index on your PK by default when designing a table. It is however, the devil to set a clustered index on a VARCHAR that has 95% of its data null and then not index the columns that you are using in your WHERE clauses. Oh and not a single one of the UPDATE statements sent by that application uses the PK to find the record it is updating.

    This properly explains TRWTF. You ought submit this again emphasising this.



  • @npinchot said:

    ...
    At this point we looked through the database design (while the client wasn't looking), since we couldn't look through the code, and found amazing table definitions like the following:

    CREATE TABLE [dbo].[Client Info](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    ...
    [Jr] [nvarchar](5) NULL,
    ...
    CONSTRAINT [aaaaaClient Info3_PK] PRIMARY KEY NONCLUSTERED (
    [Id] ASC
    ))...

    CREATE CLUSTERED INDEX [Client Info1] ON [dbo].[Client Info] (
    [Jr] ASC
    )
    Oh My Fairy Godmother, that hurts! There can be good reason to create the primary key with a nonclustered index and create a clustered index on another column (e.g. a compound PK and an identity column with a clustered index, so that additional indices utilise the identity column for referencing the clustered data) but... I don't think they quite get what this clustering thing is about :( (unless all queries against / joins to table Client Info access by column Jr instead of the Id, which is possible, but I'm assuming that is not the case or you wouldn't have posted this here)

    @pkmnfrk said:

    I should like to point out that I don't actually know what the CLUSTERED/NONCLUSTERED bits are, since my database experience is limited to MySQL.
    MySQL supports clustered indices in the InnoDB engine, but it works only on the primary key or first unique index; you can't nominate which index is clustered, or specify that you want to have a non-clustered PK and cluster on some other unique index.



  • @astonerbum said:

    Well Put.

    Honestly from my experience it is best to show up on their doorstep (suck it up) with a few people and lots of flashy gadgets and laptops. Do your work, say were going to assume nothing and test every possibility. Say we found the problem: This query is running incredibly slowly caused by application XYZ it is destroying your database and we have hardware that can possibly optimize it but it will cost u a few hundred million dollars, no promises. However you can solve the software problem for a few days worth of work (hopefully).

    The idea is to give them some VIP treatment so they feel special and are more likely to listen to you, even if it is the same exact thing you already told em. We did that a few times and it works.

     

    ^^^^ this ftw.



  • @npinchot said:

    @pkmnfrk said:
    Edit: I should like to point out that I don't actually know what the CLUSTERED/NONCLUSTERED bits are, since my database experience is limited to MySQL. But, I assume it's one of those "It's here, in the off-chance that you know what limited circumstances it's a good thing to use in" things.




    As bannedfromcoding pointed out, the clustered index will set the row order on the physical disk. Clustered indexes aren't the devil in and of themselves, and all of the Microsoft database designer tools that I know of will create a clustered index on your PK by default when designing a table. It is however, the devil to set a clustered index on a VARCHAR that has 95% of its data null and then not index the columns that you are using in your WHERE clauses. Oh and not a single one of the UPDATE statements sent by that application uses the PK to find the record it is updating.

    Won't a few CREATE INDEX queries alleviate the performance issues? Would doing it without permission from the client be unethical because of the sysadmin's hippopotamus oath?



  • @joeyadams said:

    Won't a few CREATE INDEX queries alleviate the performance issues? Would doing it without permission from the client be unethical because of the sysadmin's hippopotamus oath?




    It would alleviate a lot of the performance issues, yes. I agree this would be the ethically right thing to do and we would like to do it (with or without permission from the client). However, this will probably get us nowhere other than fired from said client.



    There are a few possible outcomes from this and none of them are good for us.

    1. The client sees a performance improvement and informs us. We tell them we made the changes - they fire us.
    2. The client sees a performance improvement and says nothing. If we ask them if performance is better, they will deny it. We tell them we made some changes - they fire us.
    3. The client sees a performance improvement and says nothing, until the moron who wrote the software comes out in a few weeks and does some "optimizations". They will then give him credit for the software running better. Now, because he got the software running better, they fire us.



      I could go on all day with possible scenarios and outcomes, none of them end good for us if we do the changes without notifying them.


  • @Lingerance said:

    @morbiuswilters said:
    Then clearly you haven't seen a file made with mysqldump
    I generally don't look at those. If it imports correctly and I can query for the same data when I test loading it then I have no need to. @morbiuswilters said:
    Or a schema generated by most programs.
    We do all ours by hand. @morbiuswilters said:
    Or a binlog.
    ... this I'm curious about. Why would I look at that?

    So basically you admit to having to little experience that your original comment was worthless.  Hey, guess what: I've never flown an airplane but I have lots of ignorant opinions about how they should work!



  • @morbiuswilters said:

    So basically you admit to having to little experience that your original comment was worthless.  Hey, guess what: I've never flown an airplane but I have lots of ignorant opinions about how they should work!
    More like, I read quite a bit of FOSS code that happens to use MySQL, and over the years I've seen much less of them using backticks. Hell, MySQL's examples don't even use backticks. Also, you appear to claim that not using a program to generate a schema is a sign of inexperience, which strikes me as odd.



  • @rosko said:

    @npinchot said:

    ...
    At this point we looked through the database design (while the client wasn't looking), since we couldn't look through the code, and found amazing table definitions like the following:

    CREATE TABLE [dbo].[Client Info](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    ...
    [Jr] [nvarchar](5) NULL,
    ...
    CONSTRAINT [aaaaaClient Info3_PK] PRIMARY KEY NONCLUSTERED (
    [Id] ASC
    ))...

    CREATE CLUSTERED INDEX [Client Info1] ON [dbo].[Client Info] (
    [Jr] ASC
    )
    Oh My Fairy Godmother, that hurts! There can be good reason to create the primary key with a nonclustered index and create a clustered index on another column (e.g. a compound PK and an identity column with a clustered index, so that additional indices utilise the identity column for referencing the clustered data) but... I don't think they quite get what this clustering thing is about :( (unless all queries against / joins to table Client Info access by column Jr instead of the Id, which is possible, but I'm assuming that is not the case or you wouldn't have posted this here)

    There's the distinct possiblility that you don't know what this clustering thing is about.  The primary key is rarely the best choice for clustering.  The best choice is usually a foreign key.  Getting a single row using a clustered index is like killing an ant with a howitzer - it leaves your artillery brigade to kill tanks with their shoes.  A non-clustered index is just fine for getting a single row.  However, accessing range queries, like getting all of the order records for June 12th, can be sped up by several orders of magnitude by using a clustered index.  A non-clustered index is useless for a range query unless it has excellent selectivity.



  • @morbiuswilters said:

    Hey, guess what: I've never flown an airplane but I have lots of ignorant opinions about how they should work!
    First of all, they don't flap their wings nearly enough.  Second, it'd be much faster if they just took off and landed vertically instead of this running start nonsense.  Third, we could save a lot of fuel if they just glided the second half of the trip.



  • @Jaime said:

    The primary key is rarely the best choice for clustering.

    Their current clustered index is on a nullable nvarchar(5) where 95% of the data is null. Maybe the PK is not the best choice for the clustered index here, but it sure would be a hell of a lot better than what it currently is.



    Also, there's the distinct possibility that someone shit in this guy's cheerios this morning.



  • @npinchot said:

    @Jaime said:
    The primary key is rarely the best choice for clustering.
    Their current clustered index is on a nullable nvarchar(5) where 95% of the data is null. Maybe the PK is not the best choice for the clustered index here, but it sure would be a hell of a lot better than what it currently is.

    Also, there's the distinct possibility that someone shit in this guy's cheerios this morning.

    I don't doubt that the Jr column is a bad choice.  But rosko was taking his fairy godmother's name in vain about the general idea of not putting a clustered index on the primary key.  Normally, if you put the clustered index on the primary key, it means you simply couldn't find a place where it would be useful.  Most of the time, the system will be faster if you simply don't have a clustered index than if you put the clustered index on the primary key.


  • @Lingerance said:

    More like, I read quite a bit of FOSS code that happens to use MySQL, and over the years I've seen much less of them using backticks.

    And I've read quite a bit that does.

     

    @Lingerance said:

    Also, you appear to claim that _not_ using a program to generate a schema is a sign of inexperience, which strikes me as odd.

    1) I didn't say anything about using a tool to generate schema.  I was talking about working with schema thus generated.  And anyone with much experience surely encounters generated schemas frequently.

    2) Experienced programmers can use tools to automatically generate good schema; inexperienced devs can write poor schema by hand.  Whether one uses a tool or not is irrelevant and is not indicative of the quality of the code.  However, the fact your only "experience" is working on your own personal projects (where you write all your own SQL by hand, apparently) only reinforces my point: your original comment about not seeing backticks in six years is meaningless as you have little experience to draw from.



  • @bstorer said:

    @morbiuswilters said:

    Hey, guess what: I've never flown an airplane but I have lots of ignorant opinions about how they should work!
    First of all, they don't flap their wings nearly enough.  Second, it'd be much faster if they just took off and landed vertically instead of this running start nonsense.  Third, we could save a lot of fuel if they just glided the second half of the trip.

    Also, they're made out of flimsy aluminum!  No wonder when they crash everyone dies!  I'd build my planes out of 3-inch, reinforced steel.



  • @morbiuswilters said:

    @bstorer said:
    @morbiuswilters said:
    Hey, guess what: I've never flown an airplane but I have lots of ignorant opinions about how they should work!
    First of all, they don't flap their wings nearly enough.  Second, it'd be much faster if they just took off and landed vertically instead of this running start nonsense.  Third, we could save a lot of fuel if they just glided the second half of the trip.
    Also, they're made out of flimsy aluminum!  No wonder when they crash everyone dies!  I'd build my planes out of 3-inch, reinforced steel.
    I'd make them so massive that they cannot fall down to the Earth.  Instead, the Earth would fall up into them.  Also, I'd replace the jet fuel with water so that it doesn't burn.  And since they'd be so big, you'd be free to move around all you want, maybe fashion a crude fort for yourself.  If you'd like to move to a different seat, you can go ahead and walk there.  Hell, you could drive there.



  • @bstorer said:

    Third, we could save a lot of fuel if they just glided the second half of the trip.
    The Canucks tried this once .. fortunately it didn't all end in tears: Gimli Glider



  • @morbiuswilters said:

    I was talking about working with schema thus generated.  And anyone with much experience surely encounters generated schemas frequently.
     

    You mean a graphically generated schema with lost of boxes and arrows? I've never seen any backticks in those.



  • @OzPeter said:

    @bstorer said:
    Third, we could save a lot of fuel if they just glided the second half of the trip.
    The Canucks tried this once .. unfortunately it didn't all end in tears: Gimli Glider
    FTFY



  • @npinchot said:

    The next time the client asked why their network (read [application name]) was running slow, I couldn't help but respond: "It's clustered, Jr!"

    That was the best thing you could think of to say?

    I'd have said "It's because your database is a clusterfuck"



  • @Cintax said:

    @npinchot said:
    The next time the client asked why their network (read [application name]) was running slow, I couldn't help but respond: "It's clustered, Jr!"

    That was the best thing you could think of to say?

    I'd have said "It's because your database is a cluster, you stupid fuck"

     

     

    FTFY



  • @npinchot said:

    @joeyadams said:
    Won't a few CREATE INDEX queries alleviate the performance issues? Would doing it without permission from the client be unethical because of the sysadmin's hippopotamus oath?




    It would alleviate a lot of the performance issues, yes. I agree this would be the ethically right thing to do and we would like to do it (with or without permission from the client). However, this will probably get us nowhere other than fired from said client.

    Yer doin' it wrong.

    <quote>"Hey, you were right!  We found a problem with one of our switches.  We're fixing it tonight."</quote>

    *THEN* you make the indexes.


    If you really want to stick to your guns: "If your so certain it's not your application, it would not hurt to let me see the source code under NDA for one day."

    I managed one of those back in the day.  I got access to the app Wednesday COB.  I fixed about 10 major performance issues that evening.  In the morning, I told them, "You were right.  There is no performance problem in the application."

    Of course, I didn't say that until after their upper management checked their morning email, and found their nightly reports - sent at about 12:15AM - that normally took until 2-3PM to arrive.

    I did later on admit that there were still issues - I'd only had time to fix the really gratuitous things, like how it slurped a file nearly the size of the system's memory into perl, then sliced off one line of the file at a time, instead of just reading the file in line by line in the first place.


  • Discourse touched me in a no-no place

    @tgape said:

    Of course, I didn't say that until after their upper management checked their morning email, and found their nightly reports - sent at about 12:15AM - that normally took until 2-3PM to arrive.
    In the context, realistically, would upper management have cared what time they were sent, as long as they got them by morning? Or were said management unable to go to bed until they'd seen the daily reports?



  • @PJH said:

    @tgape said:
    Of course, I didn't say that until after their upper management checked their morning email, and found their nightly reports - sent at about 12:15AM - that normally took until 2-3PM to arrive.
    In the context, realistically, would upper management have cared what time they were sent, as long as they got them by morning? Or were said management unable to go to bed until they'd seen the daily reports?
    Comprehension fail.


    Instead of the reports arriving half way through the afternoon, they were there waiting for management in the morning - and had been ready for hours even then.


  • Discourse touched me in a no-no place

    @Scarlet Manuka said:

    Comprehension fail.
    Oh bollocks. FPA 'am', not 'pm'.



  • @PJH said:

    @Scarlet Manuka said:
    Comprehension fail.
    Oh bollocks. FPA 'am', not 'pm'.
    My alarm clock has a mark for AM but not PM.  The LCD image is of the letters "AM" rather than just a blob or an LED that toggles, so I know that AM really means AM and is not just a arbitrary meridian indicator.



  • @tgape said:

    Yer doin' it wrong.

    "Hey, you were right!  We found a problem with one of our switches.  We're fixing it tonight."

    *THEN* you make the indexes.

    No, yer doin' it wrong.
    "Perception is reality" -Stephen Foster

    Consider we do what you have suggested and let's look at it from the client's perspective:

    1. We will look like fucking morons for not finding an issue with the switches sooner.
    2. We will look like extreme fucking douchebags and complete idiots for blaming the software and then "finding out" it was the switches.
    3. The guy who wrote the software, who we have been saying programmed horrible software all this time, will now look like a hero if the real issue was the switches.
    4. The guy who wrote the software will now constantly talk us down to the client and we will probably get fired relatively quickly, possibly with him replacing us.
    5. They will continue to let the guy write horribly performing software for them.

    @tgape said:

    If you really want to stick to your guns: "If your so certain it's not your application, it would not hurt to let me see the source code under NDA for one day."


    Great idea except the client thinks this guy walks on water compared to us - as I said in the original post, he is a friend of one of the higher ups. So even if we document all the issues with the code, there is no point. Since the client is not a programmer and will not understand at a technical level, they will just agree with their friend who will give excuses for all the issues found.



  • @Xyro said:

    @PJH said:

    @Scarlet Manuka said:
    Comprehension fail.
    Oh bollocks. FPA 'am', not 'pm'.
    My alarm clock has a mark for AM but not PM.  The LCD image is of the letters "AM" rather than just a blob or an LED that toggles, so I know that AM really means AM and is not just a arbitrary meridian indicator.


    But what if AM == "Arbitrary Meridian"?



  • @bannedfromcoding said:

    @Xyro said:
    @PJH said:
    @Scarlet Manuka said:
    Comprehension fail.
    Oh bollocks. FPA 'am', not 'pm'.
    My alarm clock has a mark for AM but not PM.  The LCD image is of the letters "AM" rather than just a blob or an LED that toggles, so I know that AM really means AM and is not just a arbitrary meridian indicator.
    But what if AM == "Arbitrary Meridian"?
    Hmm... but what would it mean when the AM mark was disabled?



  • @Xyro said:

    @bannedfromcoding said:

    But what if AM == "Arbitrary Meridian"?
    Hmm... but what would it mean when the AM mark was disabled?

    That it's specific, not arbitrary.



  • @npinchot said:

    Great idea except the client thinks this guy walks on water compared to us - as I said in the original post, he is a friend of one of the higher ups. So even if we document all the issues with the code, there is no point. Since the client is not a programmer and will not understand at a technical level, they will just agree with their friend who will give excuses for all the issues found

    Don't *document* the issues.  *FIX* them - at least, the biggest easy to fix issues that can be fixed safely in short order.

    When the friends of the programmer see how much of a difference one gets from fixing a few of those problems, if they have any hope of salvation, they will receive enlightenment.  If you're just telling them about it, they can't understand it any more than if you were speaking a foreign language.  You have to *show* them.

    Yes, it's cowboy programming - but it's what's required here.  If they really care about cowboy programming, they'll have a test environment in which the demo can be run.

    However, if they have no hope of salvation, they'll never forgive you for showing that their friend is a moron.  That's why it's safer to find some way of saying that you found something that could, in their minds, be the problem - but do your best to find something that nobody competent could cause it.


Log in to reply