22 January, 2009

Dealing with Horrible Legacy Code

I know, I know.. it has indeed been a while.  What can I say, I've been busy with work.  Even though the US is deep in a recession so bad that Microsoft and IBM are executing mass layoffs (Microsoft's ever), there are those of us; especially on the Unix side of things (I gather Linux users as well) who are swamped with new projects.  

As many readers would know, I have for the past year and a half been offering my software engineering services to an international publishing firm based out of New York with branches in Pennsylvania and Japan.  Yesterday I was in Manhattan for a meeting of introductions to the individuals with whom I would be coordinating on not one, nor two nor even three projects, but four new magazine entities.   This now brings my overall responsibility in terms of publications I  handle to a clean half dozen.  

I'm glad I'm not in the Microsoft world (for multiple reasons not to mention primarily because I refuse to work with junk and this includes any MS OS), but for the reason that with all of these layoffs, a mass amount will be MCSE's and VB/.NET programmers, architects and engineers.  This does however segue into my first point (trust me, there is a relation).  

In my most recent project, a sister publication of it actually needed some work done to their rss feeds.  Apparently this was first and foremost to fix a broken rss subscription page (where one could select which 'feeds' to follow).  This problem had been present for over a year from what I've told, and it was so bad that the page itself was throwing a PHP debug page when accessed.  This is wrong on many levels, most immediately that the debug mode was still on in the server configuration (the other errors being that they were using PHP, and allowed something to go on for over a year, broken.)  

Not wanted to reinvent the wheel as well as having a sense of right and wrong I contacted the original developers of the software and let them know that since they were the only individuals with write access to the entire group of applications involved (not to mention this was custom built by them), that it was their fault 100%, and their responsibility to fix it, and quickly at that.  As a side note, I had been informed by my client that they had made repeated requests to said developers about this problem for over the past year and were informed that it would take 'a lot of time', and that they would be billed accordingly.  Long story short, I got in the developers faces about professionalism, the fact that had they any procedures in place for regression testing when changes were made and a proper set of document and qa tests, this problem would have been squashed the moment it was introduced.  Three hours after sending my well crafted letter, I received an email back from said development house that the problem was rectified, all is working and that there was no charge.  No charge indeed, I wouldn't accept one if they tried as it was entirely on them.  

This brings me on to point number two as I could rant about the prior issue if left to my own devices.  Such heavy use of PHP in this specific application has raised some concern.  I know it was a great idea that filled a niche when it was created, but in its current iteration, it has grown to be something potentially problematic: the sucessor to visual basic.  I say this because as with VB, the purpose was to make creating software in said language possible, even 'easy' for the 'non-programmer'.  This is a simple point to remember so I won't waste additional time stating it.  Non-programmers shouldn't be programming, period.  You either are a programmer, or you aren't.  If you aren't, you have no business behind the keyboard writing code for anything that ever goes into use in a company by anyone, including yourself.  Engineering isn't a child's game and it requires discipline and continual study and exercising of one's skills.  We won't pretend to do your job, you don't pretend to do ours as you are only making things worse. I will however point out that PHP has been making non-stop strides towards a feature rich set of functionalities of its peer languages, though the battle has been uphill since it entered the ring having only the web server integration has a core plus.

This came about because while looking at the code to find the original rss problem (which was fixed without having to write any code in that monstrosity),  I became disgusted at how hackish the whole application was.  It was guilty of all of the following and more:

- ambiguous variable names
- includes of code snippets where objects should have been 
- nested structures 4+ levels deep
- very few if any comments in the code
- very little meaning in those few comments that actually pass as informative. 
- non-sensical file hierarchy for modules, includes, etc.
- hardcoding of parameters in both equality tests and branch based if statements. 
& much, much more.

It is enough to make one partake in an involuntary protein spill reflexively.  The good news of it all is that this old code base (I use the term code VERY loosely) will be redesigned and re-implemented by me and I can guarantee (because I DO guarantee my work) that it will be faster, cleaner, easier-to-use, easier-to-upgrade (including maintenance) than the existing system and will be constructed in a considerably shorter period of time. 

It is times like these where I'm glad that these other places exist.  It is hard to not look good when everyone else is so hideously bad.  I just feel bad for the poor companies and individuals who utilise these companies' services. 

recent job, nasty code built hackish bit by bit, quickly

no comments