Pray for my soul



  • So, the huge application my company has is bad enough, being written in Classic ASP by an Access developer who had no clue how to program.  Here's another snippet from this behemoth, from a six or more deep If/Then statement (not really sure how many levels, since he didn't bother to indent most of it):

     

    if left(aryUPS(i),2)="2 " then
    tctr=tctr+1
    	ctr2=ctr2+1
    	if ctr3=ctr2 then
    		ctr3=ctr3+5
    		redim preserve itmary(5,ctr3)
    	end if
    	pqty = cint(arylitm(3))
    	pitm = trim(left(arylitm(5),3) & "-" & mid(trim(arylitm(5)),4,len(trim(arylitm(5)))-3))
    	aitm = trim(arylitm(5))
    	pNetPrice= formatcurrency(arylitm(11))
    'Response.Write "Our Order/Quote#: " & pOurOrdNum & "
    " & "Quantity: " & cint(arylitm(3)) & "
    " & "UOM: " & arylitm(4) & "
    " & "Item Number: " & pitm & "
    " & "Description: " & arylitm(10) & "
    " & "Net Price: " & formatcurrency(arylitm(11)) & "
    " LineTotal=LineTotal+(cint(arylitm(3))*formatnumber(arylitm(11),2))
    ' SNIP a bunch of other If/Then statements that go on for several hundred lines 

    Not so much a WTF but the cryptic variable names are disgusting. But wait, here's a real gem. Every page has the "On Error Resume Next" directive, and I just found out that this particular piece of code dies with a NullReference error if On Error is removed, because this jackass checks an ADO Recordset object for its EOF before creating it. I mean, who in the fuck writes code that DEPENDS on ignoring errors in order to work properly (not that it's working properly anyways)?? Not to mention the thing is so cryptic I can't even understand what the fuck it's supposed to be doing in order to rewrite it properly!

    Add in the fact my bosses don't seem to understand just how bad this piece of shit system is and don't seem to want to realize that we really, really need to redo the whole thing from scratch, but are more concerned with starting new businesses on the side and making deals, all the while their system is a rotting zombie that should be put to rest. I like the company and my co-workers, but they need to get it through their mind that unless this system is fixed, and fixed soon, it's going to seriously hurt their business.

    What on Earth did I do to deserve this hell? Well, okay, I know what I did to deserve it, but still. I'm tempted to start wearing a crucifix to work to ward off the demons that must infest this code.  I thought the job I had where my boss wrote an entire ERP system in VbScript like 8 years ago was bad (variables like oConn113 throughout it), but I'd take that over this pile of shit any day of the week.    



  • Feel better now that you have that off your chest?



  • @MasterPlanSoftware said:

    Feel better now that you have that off your chest?

     

    As a matter of fact, yes I do! :)



  • Get the book "Working Effectively with Legacy Code" by Martin Fowler.  Absolutely.  Right now.  Then start writing characterization tests, which are essentially unit tests that document the way the code works.  Once you have that in place you can begin to get a handle on things.



  • @ObiWayneKenobi said:

    I mean, who in the f*ck writes code that DEPENDS on ignoring errors in order to work properly (not that it's working properly anyways)??

     

    The ones that give VB developers a bad reputation.



  • @ObiWayneKenobi said:

    I mean, who in the f*ck writes code that DEPENDS on ignoring errors in order to work properly (not that it's working properly anyways)??

    I do that all the time, the real challenge (and fun part) is finding the perfect way to crash the app so that it can trigger the most unlikely error handler.  Normally I just let the OS handle the crash so the user has to manually restart the app.  That also has the benefit of clearing those memory leaks I leave in for kicks :¬)



  • @ObiWayneKenobi said:

    ...snip

    Well, okay, I know what I did to deserve it, but still. I'm tempted to start wearing a crucifix to work to ward off the demons that must infest this code....more snipping

     

    I think you've got it all backwards man, this application IS your crucifix and you're hanging on it. It's incredibly difficult to convey the technical shortcommings of a system to buisness users / management types for the most part. You're much better off taking the characterization tests idea and running with it.

    I feel for your brain, having to sift through this code all day durring the week, but good luck! 



  • @ObiWayneKenobi said:

    Not so much a WTF but the cryptic variable names are disgusting. But wait, here's a real gem. Every page has the "On Error Resume Next" directive, and I just found out that this particular piece of code dies with a NullReference error if On Error is removed, because this jackass checks an ADO Recordset object for its EOF before creating it. I mean, who in the fuck writes code that DEPENDS on ignoring errors in order to work properly (not that it's working properly anyways)?? Not to mention the thing is so cryptic I can't even understand what the fuck it's supposed to be doing in order to rewrite it properly!
     

    Yeah but y'know...if you start from scratch it means you're throwing away all the time and money that's already been invested.  I mean that would be a waste, wouldn't it?

    oh yeah...</sarcasm> 



  • @upsidedowncreature said:

    Yeah but y'know...if you start from scratch it means you're throwing away all the time and money that's already been invested.  I mean that would be a waste, wouldn't it?

    oh yeah...</sarcasm> 

     

     No, the issue is that I don't quite understand wtf it's doing in order to rewrite it!  I'm working on deciphering it, the hard part is getting a full handle on what the business needs in order to accomplish its goals and then convincing management that the code really is that bad and should be rewritten from the ground up.  



  • @ObiWayneKenobi said:

    Add in the fact my bosses don't seem to understand just how bad this piece of shit system is and don't seem to want to realize that we really, really need to redo the whole thing from scratch, but are more concerned with starting new businesses on the side and making deals, all the while their system is a rotting zombie that should be put to rest.
     

    You mean they are too busy doing new things to sell and make money on, instead of rewriting an old application that is very unlikely to sell enough now to make back the cost of rewriting it.  Yeah, you're right, they are morons. 

    So basically you have two problems:

    1.  indention is terrible.
    2.  variable names are terrible and there are magic numbers everywhere.

     every heard of refactoring?



  • @tster said:

    You mean they are too busy doing new things to sell and make money on, instead of rewriting an old application that is very unlikely to sell enough now to make back the cost of rewriting it.  Yeah, you're right, they are morons. 

    The decision should be based more on the amount of work required to fix the app vs the amount of work required to rewrite the app rather than simply whether or not that product is making money. If it is making money and you can improve the products ability to generate income by rewriting than that should help sway the direction of the decision in favour of rewriting. Just make sure your estimates are accurate and take into account the host of new bugs you're going to introduce!

     If the organisation is essentially killing off the product and just producing bug fixes for the sake of fulilling support obligations, than they certainly shouldn't be rewriting the application.



  • I disagree.  Even if you will end up spending twice as much in the next 10 years if you don't rewrite it, I'd still stick with what I had for the following reasons:

    1. For the next year that your rewriting you going to be leaving a lot of bugs and not adding any new features.  You'll probably loose a lot of customers in that period unless you have the manpower to work on both at the same time.
    2. over the years that application has been extremely well tested by running tests and by customer sites.  Most corner cases and crazy code paths have probably already been gone down many times.
    3. Very little risk in continuing with the same code base.  Who is to say you actually make it better the second time?  Hell, it could get worst!
     



  • Sure, it's not the best code in the world, but it is not particularly obscure (at least the section you quoted was not).

    This code is part of a loop that seems to be producing an invoice or something similar.

    It seems that data arrives in a string array called aryUPS which starts with some sort of control code - the quoted code is part of the handling for those lines starting with "2 ". I suspect that there is code further up (not quoted) that splits the current line into arylitm (Line Item Array) according to some delimiter or even by fixed size fields. This data interprets those fields for a type 2 line.

    The third field is the quantity and gets converted to an integer and stored in pqty (Part Quantity).

    The fifth field is the item number and gets formatted by trimming and adding a dash between the third and fourth character, and is stored in pitm (Part Item Number).  The version without the dash is also stored in aitm (Not sure what the 'a' stands for, but looking at more code could make it clear).

    The eleventh field is the net unit price and gets converted to currency format and stored in pNetPrice (sure, the pseudo hungarian notation sucks a bit!)

    The total for the current line is calculated and stored in LineTotal (using per-item rounding rather than per-line rounding).

    It seems that at some time these items were displayed (perhaps as debug) but this is commented out.

    Earlier in the code an array itmary (Item Array) was prepared so I assume that these extracted figures are now stored there. The preparation involves incrementing a count of items in itmary (cnt2) and checking if this will fit in the current array (size stored in cnt3). If it will not fit an extra 5 slots are added to the array.

    A total of lines processed is kept in tctr (Total Counter).

     

    It seems that programmers are tought how to write programs and how to design complex systems, but not how to maintain systems that have been written by someone else. It is worth learning this skill as it is one you are going to need in your career.



  • @Tann San said:

    @ObiWayneKenobi said:

    I mean, who in the f*ck writes code that DEPENDS on ignoring errors in order to work properly (not that it's working properly anyways)??

    I do that all the time, the real challenge (and fun part) is finding the perfect way to crash the app so that it can trigger the most unlikely error handler.  Normally I just let the OS handle the crash so the user has to manually restart the app.  That also has the benefit of clearing those memory leaks I leave in for kicks :¬)

    Spidey sense tingling... I smell evil programmers afoot.



  • I should have mentioned, this is not a software company.  This application is an ERP based off of some open-source package (it's an e-commerce business) with some customization the old Access guy threw in (although half the time his code didn't work - the owners have said as much to me).  In addition the database is inconsistent, and what should be related data often has completely different attributes depending on what section of the appliciation you look it up in.

    FWIW I have heard of Refactoring, and I'm making an attempt to do this.  But the problem is deeper than a badly-written VBScript application - the problem is that their database has no integrity whatsoever (nearly every table has just been imported in from Access, so there are no constraints and everything allows null values, which often aren't checked).  A lot of the code relies on using On Error Resume Next (more than the snippet I posted) to work at all, because the original programmer evidently had no clue what he was doing.

    I am this company's MIS Director, so when things don't work properly in the application I get the call to look into it and fix it.  And what I've found is a huge behemoth.  Refactoring and "this guy didn't know wtf he was doing" aside, IMO the only real way to fix this is to rewrite the whole thing from scratch, and do it properly.  Especially the database, that's the worst of them all.  Find out what the real business requirements are, and work them out.   The hard part is IMO getting management to understand just how bad this shit is and now badly it's affecting them.



  • @DaEagle said:

    @tster said:

    You mean they are too busy doing new things to sell and make money on, instead of rewriting an old application that is very unlikely to sell enough now to make back the cost of rewriting it.  Yeah, you're right, they are morons. 

     If the organisation is essentially killing off the product and just producing bug fixes for the sake of fulilling support obligations, than they certainly shouldn't be rewriting the application.

     

    That's essentially where I am right now.  I started out picking up someone's rewrite of the app, worked a month or two on that, and then they canned the rewrite.  I wholeheartedly agree with the decision.  There is WAY too much to do when it comes to rewriting a highly polished turd of a codebase.  So many pointy edges have been filed down by the wear-and-tear of being out in the wild.

    Rewriting rarely pays off the way programmers wish it would.  It's tempting because the best way to understand code is to write it yourself.  Everybody else's code looks like gibberish :)



  • @ObiWayneKenobi said:

    I am this company's MIS Director, so when things don't work properly in the application I get the call to look into it and fix it. 

    I hope you don't take this too personally.

    A typical MIS Director's job involves tracking the costs and benefits of the company's technology operations.  You have an application that is making the company X number of dollars per year.  It costs you Y number of dollars to maintain.  It will cost an estimated Z number of dollars to replace, with an unknown future maintenance cost.

    As a Director, you feel the pain of maintenance and think the company will be better served by replacement.  Fine. 

    Now look at the big picture and put yourself in the shoes of the CEO:

    As long as X is greater than Y and has a high probability of continuing sales then you absolutely do not go down the unknown path.  There is no concrete benefit.

    If Y is approaching X and has a high probability of being phased out either before or soon after that point, then again you do not reinvent it for the same reasons.

    However, if Y is approaching X and has a high probability of continuing sales then, as a Director, it is your responsibility to show this to your boss.  Use the financial numbers because that is all that matters.  If he/she still decides not to go ahead, then you might want to find out what else is going on because either you don't have the complete picture or the boss is an absolute idiot and you need to find a new job before the company goes kaput.

     

    Later,

     



  • @tster said:

    I disagree.  Even if you will end up spending twice as much in the next 10 years if you don't rewrite it, I'd still stick with what I had for the following reasons:

    1. For the next year that your rewriting you going to be leaving a lot of bugs and not adding any new features.  You'll probably loose a lot of customers in that period unless you have the manpower to work on both at the same time.
    2. over the years that application has been extremely well tested by running tests and by customer sites.  Most corner cases and crazy code paths have probably already been gone down many times.
    3. Very little risk in continuing with the same code base.  Who is to say you actually make it better the second time?  Hell, it could get worst!
     

     

     

    You're a moron. Break your fingers.

     @tster said:

    You'll probably loose a lot of customers

    Exhibit A

     



  • BTW, if you happen to have access to some BA resources, then you might consider doing the architecture design piece on the sly; provided the financial benefit is still there.  Once that is done, you'll have something to provide "firmer" estimates against which would help you lay out a replacement case.



  • @Lysis said:

    @tster said:

    I disagree.  Even if you will end up spending twice as much in the next 10 years if you don't rewrite it, I'd still stick with what I had for the following reasons:

    1. For the next year that your rewriting you going to be leaving a lot of bugs and not adding any new features.  You'll probably loose a lot of customers in that period unless you have the manpower to work on both at the same time.
    2. over the years that application has been extremely well tested by running tests and by customer sites.  Most corner cases and crazy code paths have probably already been gone down many times.
    3. Very little risk in continuing with the same code base.  Who is to say you actually make it better the second time?  Hell, it could get worst!
     

     

     

    You're a moron. Break your fingers.

     @tster said:

    You'll probably loose a lot of customers

    Exhibit A

     

     

    Way to express your opinion. I love the intelligent rebuttal.

    tster is absolutely correct. Many programmers have a short sighted view of every piece of code they didn't write should be rewritten. This is NOT always the best case for the company. Especially in a case like this where the code obviously works and is generating revenue.

    Refactoring various pieces of code over time is a much more efficient way to gradually 'tame' the codebase. In most cases if you cannot understand the code, it is your fault. Not the person who wrote it. If you commonly look at code and think "This doesn't make any sense, I should rewrite it" you might be the problem, not the previous programmer. Of course, as we have all seen on this site, there is such a thing as 'stupid code' that should be fixed. But this does not require a rewrite. Refactor as you go.



  • I don't take it personally - it's a small company so while I'm "MIS Director" I also am the IT Department.  I've also never had what amounts to a managment (in a thin sense of the word, anyway) level position before, so I'm still transitioning from "code monkey" to "director".  I'm making a whole-hearted attempt to A) Figure out the nuances of the business and how IT/MIS can help achieve it, B) Take an inventory of our current situation so I know where we stand (read: Find out what software we're running without proper licenses, and then finding out what it costs to get legit), and C) Evaluate the current infrastructure so I can make an informed decision and present that to my bosses.  It's somewhat hard though, as most of my day is spent fixing weird quirks that pop up in the system, such as a product not showing the correct price, or the stock being off by a few dozen.

    I realize that it's a common sight for a programmer to look at any code that he didn't write and say "This is garbage, let's rewrite it!".  I went through that phase once or twice.  The current situation is worse, because I want to rewrite the code not because it's garbage (although it is), but because its written wrong to begin with and doesn't work properly.



  • @Lysis said:

    You're a moron. Break your fingers.

    Please don't overwhelm us with the power of your logic.



  • I must say that I agree with those who say to refactor rather than rewrite.

    I'd start with simple things like correcting the indentation, improving variable names etc. Hopefully while you're doing that you'll learn a lot about how it's meant to work. Then, when you find bugs, you may be able to find a guilty function or two, characterise them, and then rewrite THOSE functions if necessary. (Making sure you've got a good source control system in place, so you can reverse your changes when you find you've just broken everything).

    Rewriting from scratch is probably only a good idea if you think there's a big market in it, and that you'll greatly improve sales by doing so.



  •  Well, it would improve sales (and everything, really) to do it right from scratch rather than continue to patch holes in a system that was badly written in the first place (I liken patching holes in a bad system to putting duct tape over a leaky pipe - sooner or later you're going to have to replace the thing, and the longer you wait the more damage replacing it will cause and the more it will cost you to do it).   Refactoring the Classic ASP stuff would patch it for the moment, but in the end a full rewrite is the best possible solution to ensure that it's functioning properly. 



  • @ObiWayneKenobi said:

     Well, it would improve sales (and everything, really) to do it right from scratch rather than continue to patch holes in a system that was badly written in the first place (I liken patching holes in a bad system to putting duct tape over a leaky pipe - sooner or later you're going to have to replace the thing, and the longer you wait the more damage replacing it will cause and the more it will cost you to do it).   Refactoring the Classic ASP stuff would patch it for the moment, but in the end a full rewrite is the best possible solution to ensure that it's functioning properly. 

     

    It is not very likely that a rewrite would have a substantial impact on sales.

    In fact, is likely to have the opposite effect.



  • Maybe it's just inexperience speaking, but I don't really understand that train of thought.  I mean, teh system as it now stands has incorrect/inconsistent data, is poorly written, doesn't accurately improve business processes, and to top it off is written in what is pretty much a dead-and-buried language, using 10-year old worst practices as its coding style.  I really don't see how taking the time to properly document and create a robust infrastructure can hurt this business, when it's already being slowly killed by this cancerous system.

    But again, I'm still wet behind the ears so maybe I'm not seeing the "whole picture".  I've often heard developers be against rewrites, but then how can you take advantage of new things that come down the pipe; things that might help your business grow?  Maybe I am confusing "rewrite it" with "design a new and better system"?



  • Can you quantify the sales increase? How quickly would the sales increase cover the cost of re-writing it? What is the guarantee this piece of software will be in use in X years? What is the chance that a re-write will not significantly improve the software? Will other projects you are/will be working on increase sales MORE than re-writing this piece of software?

    While it's hard for you to see, there is a risk factor to the company for you to spend the time on this project.



  •  I can see that much.  The current system has been used for about 5 years (maybe more, not 100% certain).  Given that 90% of my projects involve "<Critical Part> of the system isn't working" scenarios, I think a new version is probably justified, for maintainability if not increased benefit overall to the company by having reliable data to work with.  

    Sadly this is just part of my "vision" of things - there are a truckload of manual processes that I'm looking to get automated, and lots of vendors systems to interact with (EDI, yuck!) on a daily basis.   Things like stock updates, cost updates, pricing changes, etc. should be done on a daily basis to ensure our competitiveness.



  •  @ObiWayneKenobi said:

     I can see that much.  The current system has been used for about 5 years (maybe more, not 100% certain).  Given that 90% of my projects involve "<Critical Part> of the system isn't working" scenarios, I think a new version is probably justified, for maintainability if not increased benefit overall to the company by having reliable data to work with.  

    Sadly this is just part of my "vision" of things - there are a truckload of manual processes that I'm looking to get automated, and lots of vendors systems to interact with (EDI, yuck!) on a daily basis.   Things like stock updates, cost updates, pricing changes, etc. should be done on a daily basis to ensure our competitiveness.

    No matter how you justify it, it is unlikely your management will ever see things your way. You might as well plan to start working with what you have.

    Welcome to the struggle.



  • @MasterPlanSoftware said:

    No matter how you justify it, it is unlikely your management will ever see things your way. You might as well plan to start working with what you have.

    Welcome to the struggle.

     

    Sadly I'm starting to see that.  It's a wonder people who have this mindset get to be successful in business, when the truth is that they're totally ignorant and clueless in the long run.  



  • @ObiWayneKenobi said:

    @MasterPlanSoftware said:

    No matter how you justify it, it is unlikely your management will ever see things your way. You might as well plan to start working with what you have.

    Welcome to the struggle.

     

    Sadly I'm starting to see that.  It's a wonder people who have this mindset get to be successful in business, when the truth is that they're totally ignorant and clueless in the long run.  

    You're so young :)

    So am I, but I got whacked with the cluebat early on. 



  • @ObiWayneKenobi said:

    @MasterPlanSoftware said:

    No matter how you justify it, it is unlikely your management will ever see things your way. You might as well plan to start working with what you have.

    Welcome to the struggle.

     

    Sadly I'm starting to see that.  It's a wonder people who have this mindset get to be successful in business, when the truth is that they're totally ignorant and clueless in the long run.  

     

    Actually, it sounds to me like that is why they are in charge and you are not.

    If it makes money, keep doing it. If you could present them with a direct, factual analysis on ROI and they said no, I would say they might not be very smart. But you are only arguing that you should rewrite it, based on your opinion, and not on real world cost analysis.

    No matter how smart or dumb they MIGHT be, it sure sounds to me like they are doing the right thing for the business.



  • Perhaps I am just young.  It seems to me (and take this as you will) that the current system isn't making money (it's not a part of the money-making process, but of the administration/back-end operations.  We could 'make money' using paper and pens).  It's costing money because of errors (We have proof of this).  If it was properly architected (and that's not to toot my own horn, as I'm not sure if I could pull it off 100%, although I doubt I could get approval to hire anyone to help me.) it would completely integrate our systems together, provide reporting (something that is now accomplished by "I got an Excel file, FTP it to the database, import it into a table, run a query, export it back to Excel, FTP it back to my workstation, format it, email it back to my co-worker"), provide a stable way to grow the business.

    Again, call me wet behind the ears but I don't see how that wouldn't improve the busines compared to the cesspit they're working with now.  I was hired to improve the business's IT operations (or so it seems).

    I'm not really trying to argue (it might come across that way). 



  • @ObiWayneKenobi said:

    I got an Excel file, FTP it to the database, import it into a table, run a query, export it back to Excel, FTP it back to my workstation, format it, email it back to my co-worker

     

     

    Surely the FTP bit could be eliminated ...  



  • @ObiWayneKenobi said:

    Perhaps I am just young.  It seems to me (and take this as you will) that the current system isn't making money (it's not a part of the money-making process, but of the administration/back-end operations.  We could 'make money' using paper and pens).  It's costing money because of errors (We have proof of this).  If it was properly architected (and that's not to toot my own horn, as I'm not sure if I could pull it off 100%, although I doubt I could get approval to hire anyone to help me.) it would completely integrate our systems together, provide reporting (something that is now accomplished by "I got an Excel file, FTP it to the database, import it into a table, run a query, export it back to Excel, FTP it back to my workstation, format it, email it back to my co-worker"), provide a stable way to grow the business.

    Again, call me wet behind the ears but I don't see how that wouldn't improve the busines compared to the cesspit they're working with now.  I was hired to improve the business's IT operations (or so it seems).

    I'm not really trying to argue (it might come across that way). 

     

    You could be right, but you will have more luck convincing someone to allow you to refactor and do incremental changes to the system, instead of starting from scratch.

    If you spend that much time maintaining the system, you won't have enough time to rewrite the whole thing anyway.



  • This might actually be one of those rare cases where a total rewrite would be good, depending on the size of this thing.  Sounds like it really doesn't work in the first place, so it's not like the new version is guaranteed to be buggier.  It's not a commercial product so you don't have to worry about upgrading customers (i.e. supporting 2 products now) or breaking backwards compatibility.

    Maybe you can rewrite the thing piece by piece.  See if you can divide the program into smaller components with well-known interfaces.  Then, next time a bug report comes in, fix that bug but try to refactor that whole component a bit so you're in a little better shape than you were before.  If you can pinpoint the interfaces with the other components you could even rewrite the whole damn thing and not worry about breaking a whole bunch of stuff while you're at it. 



  • @medialint said:

     

    Surely the FTP bit could be eliminated ...  

     

    You would think so, but our server is hosted in a data center (although they don't seem to do much that I can't do myself, and it costs us a fair bit of cash) and they won't allow it to be part of our domain (We own the server, they're just housing it), so the only way to hit it is via Remote Desktop/VNC or FTPing files.

    I actually am considering suggesting that we move it back in-house, since it's difficult to maintain sometimes due to not physically being located here. 



  • @MasterPlanSoftware said:

    you will have more luck convincing someone to allow you to refactor and do incremental changes to the system, instead of starting from scratch.

    Or at least, that's what you TELL them you're doing...  :)



  •  @ObiWayneKenobi said:

    You would think so, but our server is hosted in a data center (although they don't seem to do much that I can't do myself, and it costs us a fair bit of cash) and they won't allow it to be part of our domain (We own the server, they're just housing it), so the only way to hit it is via Remote Desktop/VNC or FTPing files.

    Transferring over a shared drive in RDP would be easier (IMO) than FTP.

    Don't forget  that by moving the server to your location, you become responsible for it. I am sure the data center is doing more than you think.

    Monitoring failures, providing bandwidth, physical security, and climate control (and many other things) are all major things that should not be taken lightly in a production environment.

     



  • I agree with what the majority of people are saying. And the product may need to be rewritten. But I think you should go the incremental way first. Refactor sections to make it better to understand. Every programmers instinct wants to write something better, but you can't always give into that too quickly unless you understand every piece of the system. Although I do agree with you that sometimes the business requirements need a new look (as there may be a bunch of baggage that does nothing for the system). I still say take it in steps. Focus on refactoring it incrementally, starting with the most critical parts. Gradually work your way through the system, using good source control to help maintain everything. If nothing else, make it easier to read, and more reliable. Start testing it without the OnError declaratives.  Make it bomb in your face so you can shake out what is wrong and correct that. You can still put proper exception Handling by specifying a handler for it. If it hits the handler, log it while you're debugging. 

    Once you're done all this, it should free up the time that you are spending fighting the system. And you have  a much clearer picture of what every component does and why. The big problem is that by doing that, you almost kill your chance for a complete rewrite, unless you can convince management that moving to new technologies will benefit their business in a tangible way.



  • I'll take my time, then, and see what I can do (although the database is something that needs to be fixed.  You'd understand more if I could show you it).  The most annoying thing, funnily enough, is the reliance on MS Access for most day to day stuff.  For example right now I need to check a list of some 1,000 items in an Excel spreadsheet to see if their already contained in our database.  This involves having to import the file to Access and run the query, then export it back again to Excel.  It's not so much a hassle as it is annoying, because I'd prefer to get away from Access entirely to save money when we upgrade Office (so we can get Small Business instead of Professional)

    I will consider the server location, as well, but the sheer fact that to do anything aside from basic maintanence requires me to travel about 40 minutes to where it's hosted makes me really want to save us a few thousand dollars and bring it back in-house.  But I see the points with leaving it. 



  •  @ObiWayneKenobi said:

    I'll take my time, then, and see what I can do (although the database is something that needs to be fixed.  You'd understand more if I could show you it).  The most annoying thing, funnily enough, is the reliance on MS Access for most day to day stuff.  For example right now I need to check a list of some 1,000 items in an Excel spreadsheet to see if their already contained in our database.  This involves having to import the file to Access and run the query, then export it back again to Excel.  It's not so much a hassle as it is annoying, because I'd prefer to get away from Access entirely to save money when we upgrade Office (so we can get Small Business instead of Professional)

    I will consider the server location, as well, but the sheer fact that to do anything aside from basic maintanence requires me to travel about 40 minutes to where it's hosted makes me really want to save us a few thousand dollars and bring it back in-house.  But I see the points with leaving it. 

    Why not make your first priority automating all the imporying?

    That is what I would do. Hit the worst parts first. Taking care of something like that would have a real ROI not to mention your own satisfaction and comfort.



  • Yeap that is my plan.  :)

    What makes it difficult though is the knowledge that the database itself has integrity problems and duplicates data in several places.  I've been looking into SQL Server Integration Services, but I feel like if I automate it now, I'll just have to do it all over again if/when (hopefuly when) I can properly architect the database.  But you are right, automating all that stuff would at least be a step in the right direction. 



  • @ObiWayneKenobi said:

    Yeap that is my plan.  :)

    What makes it difficult though is the knowledge that the database itself has integrity problems and duplicates data in several places.  I've been looking into SQL Server Integration Services, but I feel like if I automate it now, I'll just have to do it all over again if/when (hopefuly when) I can properly architect the database.  But you are right, automating all that stuff would at least be a step in the right direction. 

     

    As long as you do a good job planning out and documenting the new code, it should be easy to make changes later. I wouldn't worry too much about that. If you free up a bunch of time by automating things, that is more time you have to work on the bigger plans.



  • I think that is what I'll start doing.  Thanks for the advice, I really appreciate it! Like I said, this is my first "director" (relatively speaking...) position.  :) 



  • One last piece of advice (at least from me), is that as a MIS Director you have to stop thinking about what the code actually looks like and instead focus entirely on whether the business need is met.  (Say this next part to yourself once every 5 minutes until you believe it) "It doesn't matter if the code is pretty or in the latest language as long as the business is able to use it."

    This is perhaps the hardest thing about transitioning from being a grunt to ordering grunts around.  It's compounded when you are the only one in the department.  The very first thing you should do is a simple assessment of all systems in light of company priorities.  Make sure you include your boss(es) in this assessment.  Then start putting time against it.  When you have that go to management about expanding your department beyond just you.  All other tasks except for a major crisis (meaning immediate lost revenue) should be shelved until this is done.

    A few years ago I walked into a very similiar situation.  I contracted with a company to provide some technical leadership.  On the first day my boss asked me to fire everyone in the IT department ( 15 people ); which I did except for 1 support guy.  Attitudes were beyond bad, and they needed to be encouraged to move on.  On the second day my boss asked me to start fixing one of their problems.  Instead, I told her it would be better to do a full assessment to see how everything was going.  It took about a month.

    After I had been there for 4 months, the IT department was up to a full staff of 20 people.  At which point I was offered a full time job at more than my contract rate plus bonuses, etc.  Due to other opportunities I declined and simply hired my replacement.  The point is, I never wrote a single line of code in that time and I certainly never debugged any of the absolutely garbage systems.  Because of that my boss didn't look at me as a programmer who also does some management.  She saw me as a manager who got things done; which is a completely different attitude.

    BTW, Good luck and congratulations in your new job! 



  • I'll really keep that in mind, thanks again.  Although I doubt I can hire people... we were talking of "cutting costs" and I don't think they would see the need for another IT person (and to be honest, as much as I want some help I don't know what they would do - most of my day consists of running reports handed to me in Excel against Access or SQL Server to pull product data for inventory loads, or the occasional break-fix with the behemoth).  But we'll see what transpires. 



  • As an aside, does anyone know if there's a way to import data from another data source into Excel and filter it based on an Excel column?  I know how to import data into Excel 2007,  but I don't think there's a way to filter it like that.  For example, today I had a list of some 300 products my boss sent in a spreadsheet and needed to obtain the price of them.  The only way I know to do this is to import the spreadsheet into SQL Server (into a table called tmp_PriceReport or something), run the query (in this case joining it with the Products table), saving that into another table, then exporting it back to Excel.  I would love for an easier way to do this as most of my day consists of being given some products in Excel and being asked to give a list of cost/prices/etc. for various business-related purposes.  It takes up a lot of my time.  Maybe I'm just having a brain freeze, but I can't think of an easier way to do this.

    Oh well, I've hijacked my own thread it seems :)

    And btw the real WTF is still the forum software.  Who the hell has an expiration on being able to edit posts??



  • That sounds like one of the few cases for using a macro to me...make it query the database from excel and have it fill in the prices, at least for a quick-and-dirty solution.

    Not sure if vba can do this, but it might work. 



  • @ObiWayneKenobi said:

    And btw the real WTF is still the forum software.  Who the hell has an expiration on being able to edit posts??

    It's a good idea in general, to prevent disgruntled users from editing threads so they make no sense. I think a more sane timeout is about an hour, though.


Log in to reply