1. Home
  2. Categories
  3. Side Bar WTF
  4. New job, horrible system.

New job, horrible system.

  • B

    So, I recently started a new job. The main product developed in this office consists of a ASP.Net front end duct taped to a VB6 COM Object backend. I've been digging through the system making heads or tails of what everything does. The request pipeline for this application is... unique.

    The request pipeline starts and ends with a single ASP page. One of the things this page does is browser sniffs for IE, and if that fails, redirects to the IE page on Microsoft's site. Took me a second to figure that one out when I first loaded it in Chrome.

    This page then goes and creates a COM object, and calls it thusly:
    if io.throwaspcall(response,request,session,application) then
' all was OK
else
' all was not
end if

    From there, the pipeline is roughly (This is all VB6 code):

    1. Create COM object based on page name in Request
    2. Call ProcessRequest on created COM object
    3. COM object returns XML
    4. Database is queried for file system path of XSLT to handle this particular page.
    5. XSLT is loaded from file system
    6. XML document is then transformed via XSLT into HTML
    7. Transformed HTML is then sent out to the browser

    None of the items in this pipeline are cached. Dozens of new COM objects created every request. To handle displaying values from lookup tables, the whole table is pulled out of SQL, and put into the XML file, which is then handled by some logic in the XSLT for looking up a name to go with that value. Some of these have hundreds, and in a few cases, thousands of values. With, once again, no caching.

    Each customer (This is a SaaS solution) has it's on SQL database. Fair enough, probably easier to do that then one database with HIPPA compliance. However, the customer to database mapping is stored in the registry. And due to that, a customer can only really be set up on a single server. So, if we lose an application server, several customers won't be able to access the site. Not to mention load balancing is impossible. 

    But, sometimes pages aren't built via the XSLT method, sometimes you have this instead:
    S = S & "function SpliceURL(sURL) {" & vbCrLf
S = S & "  var sBegin; var sEnd; var sValue; var iCount; var iStart; var iEnd;" & vbCrLf
S = S & "  iStart = sURL.lastIndexOf('ReportFilterIDY');" & vbCrLf
S = S & "  iEnd  = sURL.lastIndexOf('&');" & vbCrLf
S = S & "  if (iStart < 0){" & vbCrLf
S = S & "       sValue = sURL + '&ReporFilterIDY=' + sRIDY;}" & vbCrLf
S = S & " else if (iEnd > iStart){" & vbCrLf
S = S & "       sBegin = sURL.substring(0,iStart);" & vbCrLf
S = S & "       sEnd = sURL.substring(iEnd);" & vbCrLf
S = S & "       sValue = sBegin + 'ReporFilterIDY=' + sRIDY + sEnd;}" & vbCrLf
S = S & "  else{" & vbCrLf
S = S & "       sBegin = sURL.substring(0,iStart);" & vbCrLf
S = S & "       sValue = sBegin + 'ReporFilterIDY=' + sRIDY;}" & vbCrLf
S = S & "  return sValue;}" & vbCrLf
    Most of the dates in the files place most of this written around 2002-2003. I won't fault them for not writing .Net, since this system is older than that. I will fault them for re-inventing Classic ASP for some reason.

    Passwords for the system aren't hashed, but encrypted via CAPICOM, with a single key used application wide, hard-coded everywhere. I can tell you that "password" is a very popular password. Along with "welcome". Various month + year combinations are also very popular.

    On the plus side, they're using source control. On the downside: SourceSafe. Which after saying they never had any corruption issues with it, it decided to eat a 3MB SQL script today. I also can't commit any code until they've finished with the current software release, since the changes I'm working on are slated for the next version. I'm planting the seeds of trying to move them to a source control solution that can actually handle branching well, along with at least moving towards some sort of numbered SQL script solution at least.

    There is one bright patch in this: They know this system is awful, and it seems one of the reasons they hired me was to get this system into shape, and at least into the current millennium. It seems I've already won over the network ops guy that has to manage the servers this thing runs on, just from him showing me something (The system stores customer uploaded pictures all in one directory, even though there's per-customer image directories, making it impossible to move a customer from one server to the other), and my reaction being "That's awful".
    0
  • configurator

    @bardofspoons42 said:

    There is one bright patch in this: They know this system is awful, and it seems one of the reasons they hired me was to get this system into shape, and at least into the current millennium.

    Don't worry, they'll probably forget all about it in a few weeks and refuse to do any changes you suggest. You'll have plenty of stuff for us then.

    0
  • G

    Damn... this is one of the worse horror stories I've read in recent times. How exactly did this happen to you? Was your need of employment just a little too urgent for you to be even a little bit picky?

    Passwords for the system aren't hashed

    This really ought to be considered a form of criminal negligence at this point. Getting caught doing this should be such a black mark on one's career that it would be easier to retrain in a new profession.

    0
  • J

    @bardofspoons42 said:

    The main product developed in this office consists of a ASP.Net front end duct taped to a VB6 COM Object backend. I've been digging through the system making heads or tails of what everything does. The request pipeline for this application is... unique.

    I didn't know we'd taken on a new developer - have we been introduced yet?

    @bardofspoons42 said:

    Dozens of new COM objects created every request. To handle displaying values from lookup tables, the whole table is pulled out of SQL, and put into the XML file, which is then handled by some logic in the XSLT for looking up a name to go with that value. Some of these have hundreds, and in a few cases, thousands of values. With, once again, no caching.

    You've just accurately described how our core software deserializes an xml file off disk into a POCO. At home I water my plants with tears before standing naked in front of a mirror, carving C# code into my chest with a USB key.

    0
  • B

    @GNU Pepper said:

    Damn... this is one of the worse horror stories I've read in recent times. How exactly did this happen to you? Was your need of employment just a little too urgent for you to be even a little bit picky?

    Passwords for the system aren't hashed

    This really ought to be considered a form of criminal negligence at this point. Getting caught doing this should be such a black mark on one's career that it would be easier to retrain in a new profession.

    The need for employment was rather urgent (My former employer decided to stop paying me, and also threatened to sue me... that's a whole WTF in itself).

    However, no one here really seems to like this system. It came from some other company the parent company bought, pretty much everyone in that company was canned for various reasons, and then it ended up in this office's lap. The network guy doesn't like it, the devs don't like it. However, until I was hired, there were only two other devs, and they seemed to have their hands full keeping this thing on life support. During the interviews, shortly after they mentioned there was a legacy VB6 app, they also mentioned they wanted to migrate away from it. I've only been here for less than a week, so I'm still learning my way around, but it does seem they want me to help lead away from this mess.

    As for the password mess, I wouldn't be surprised if that bit of code was almost 15 years old. This system has been around for awhile, so that probably predates the common knowledge that you should hash passwords. In all honesty, I was expecting plain text passwords, or some home grown "encryption". At least they used CAPICOM.

    I'm going to remain hopeful that I will be able to start helping them move away from this mess. I'm sure I'll have more posts to come for here and I spelunk through more of this code.

    0
  • R

    @JimLahey said:

    You've just accurately described how our core software deserializes an xml file off disk into a POCO. At home I water my plants with tears before standing naked in front of a mirror, carving C# code into my chest with a USB key.

    This guy knows how to party!

     

    0
  • B

    XSLT builds the user interface... that's horrible. WTF is COM there for? It's not like there's much risk of "DLL Hell" when you're writing all the DLLs. And I love the vbCrLfs in the Javascript. I'm pretty sure you could just delete most of those and the end result would be the same... anyone who's ever done "View Source" in IE should realize that.

    0
Log in to reply