Ridiculous Coding Process

[tmm]

I work for the largest health insurer in the U.S. Actually, we are now global. Our claims system is a relational DB and is normalized. Our DD is pretty close to being perfect and I know it is impossible to come up with every scenario on the planet to add to a DD. Here is the issue;

When we hit numerous tables, whether doing an inner join, left join or left outer join, often times the data that is in the main claims table is duplicated. Example, we hit our member table and it will cause the claim number and monetary values to come over 2 or more times. My Assoc. Director is trying to say this is a DD problem and our DD is incomplete or not accurate. I have asked for examples and until this very moment, he has provided 0. However, another analyst on my team provided me with 1 example. I was able to trace back to the member table and found the reason it was returning duplicates was because on our finc_arng_cd column, the member had an A for ASO and null for the 2nd line. I explained you need a filter for A on the finc_arng_cd. She did that and it worked. I included my Assoc. Director in the information and explained if you get duplicate returns on our main claims table (which contains 6 primary keys and our BA's have stated there are no duplicates in the main claims table. It is set up to make sure that never happens) then it is something wrong with his code. Of course, he is arguing with me about this. So, instead of doing some simple research and back tracking to see what is causing the duplication and then re-coding appropriately, he has so far created a 19 1/2 page SAS code that hits so far 11 table separately. He has no joins at all. He is simply hitting the claims table first and pulling out what he wants. Then a separate query to hit the provider table and pulling what he wants. And so on. He also put these macros and loops in and right now the code does a loop and looks at 100 records at a time.

1) The way he is coding tells me that he is treating our claims system as though it contain no relationships and is not normalized.

2) His coding to me is old and if he receives duplicates then his code is wrong.

3) This looping 100 records at a time is inefficient because our projects return millions of records. I have one project that returns over 8 million records. Using his 100 at a time looping, I think my computer would crash or it would take forever to run and I would probably use all the temp space in the database and the admins of our claims system would shut me down.

Does anyone have any input they can provide that can further my proof that he really has no clue what he is doing and proposing we code this way to our director is going to cost time and time is money.

[Doc_Duke · Accepted solution]

TMM,

Technically, you are probably right.  However, this is mostly an HR problem.  I suspect the Assoc. Director (AD) is senior to you (in both tenure and age).   It is hard to teach old dogs new tricks (I'm an "old dog" and I stumble a lot more than I used to).  It is also difficult for some people to take advice (or criticism) from below (the HR reference).  Knowing when you can help is part of the "art" of working in big organizations.

As long as the AD's code is working, though inefficient, it is probably best to just let it go.  Provide advice or help when solicited, but don't try to impose yourself.  Computer resources are a lot cheaper than people ones these days and the AD may bring more that is positive to the table than just rusty coding techniques.

Doc Muhlbaier

Duke

[tmm]

Oh, and actually he has only been with the org a couple years and is really young. I have tenure and 8yrs exp with SAS. 2 SAS certs, an MBA in Computer Science and 1 year from my doctorate. Like I said if he pushes us to program this way, I will have to take it to a higher level because ultimately he is going to cost us time and time is money. Regardless of his coding the old way or wrong way, money is the ultimate player here. Talk about that to my managers and they listen.

[tmm]

He has cost us money 1 time before. He has only been on the team since Dec 11th of last year and wasted 10k on a server as well as the SAS license. We told him after testing it was useless to us and at the end of this year to scrap it and save the money. He said no, I use it. Of course I looked at his file and nothing in it. I think he does not want to scrap it because it will show management he was wrong. But, who cares. If I pushed the SAS server through and discovered what I was told was not accurate, you better believe I would say I apologize but I was wrong and this SAS server is of no use to us, so I had the internal SAS team close it out so we don't continue wasting 10k a year on the server plus the SAS license.

[Reeza]

Here's a good blog on the topic. I can guarantee there are people on here who would look at your code and say you're doing it all wrong as well.

http://blog.teamtreehouse.com/youre-doing-it-all-wrong

I find it very hard to believe that with 300 million records/year a SAS server isn't of use as well.

[tmm]

Thanks. And you and this article are correct. There are 101 different ways to code. As long as the end result is accurate and done in a timely manner because time is money. That is the issue here. The way the norm coding is done in my area, we take up less CPU hours and things run efficieintly. This programmer wants to hit every table 1 at a time. My counterpart tested his methodology over the weekend and her computer crashed. The problem is not SAS server. If I was in an office where I connected to the server, it would be useful. But we are telecommuters. We already VPN from local machine to the claims database. Using the SAS Server we have to VPN, SAS Server to claims database. SAS Server introduced middleman. So, this is why we dogged that whole SAS Server. Works if in the office but our team is not. Now, the problem arises with his code. Yes, his results are the same but it takes longer to get those results and as I said time is money. Looking at his cold is really the 'old' method of doing things, but does that make it right or wrong? I guess it is up to mgmnt to make the call if they want to use his way or the norm. I look at his code as driving 20 miles to take a train to a destination that is just across the street. I just wanted input on this because we have a meeting this afternoon where he is going to share what he has done and explain it to us. Why, we have no earthly idea. We assume it is to force us to code this way. We will both at that point decline and I will then show my proof as to why it is not efficient to code like this. Not to mention he is hitting 11 tables and used 1 day as his testing and it took 2hrs to run the 19 1/2 pages and get results. That is just 1 day and 1 proc cd. My counterpart has applied his methodology to her project and she said her computers has halted 3 times since this morning and the 4th time she got the blue screen of death. Bottomline is this guy has no clue what he is talking about he has no understanding of our claims system and the DD. but he wants to tell everyone he does. he also lacks intuition. He gave my mgr 16 of 20 id's market information and said that is all I can find so that should be good enough. when she said no I need the other 4 he came to me for help. I looked at his code and based on my intuition said i'll bet the other 4 have termed. told him remove the >=12/31/9999 in his mbr cov row end dt and there they were. then he went on and on about how our DD was wrong and misleading. I said no. 12/31/9999 is the norm. as a programmer you need to be intuitive and think outside the box. I told him I believe programming is 15% coding and 85% intuition. but that is MO. he has done this b4 with other projects and I just say look if our BA's put every possible scenario in the DD it would be a document that would go on forever. bottomline is he really has no clue what he is doing. he might know SAS but he does not understand the claims system so he really cannot make any conclusions and that is what he is doing. he reminds me of a dog that chases their tail and never catches it.

[Astounding]

tmm,

Perhaps you should be counting your blessings.  I once heard about a manger that would only let programmers use coding techniques that the manager understood.  As a result, MERGE was banned because it was too complex, and SAS code had to use IF/THEN statements instead.

Good luck.

[Haikuo]

OK, I will just shut up and consider myself lucky. :smileysilly:

[tmm]

Thanks. I will let it go but he is meeting with me and the other analyst today because he WANTS us to code this way and I have one project that hits 30 tables and is 76 pages as of right now. I can see with his proposal pushing 200 pages of code. What a QA nightmare. We shall see what he says on the meeting today. If he pushes us, then I will have to push back and show my management team this is not efficient and will cost the team time and time is money. His way of coding is like driving 20 miles to take a train to a destination thats just across the street because thats the only way he knows.