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

The Importance of Being Challenged

In this most recent engineering, architecting and development endeavour which I simply refer to as my "job" or "contract", I have come to some conclusions which I feel require sharing.  I'll be very straightforward so as to not waste certain readers' time.  Many of the more seasoned lifetime coders will know (and have experienced many times over) that which I am writing about, which can be summed up as such:  If you are not being constantly challenged, you are atrophying as a developer.

I often write about my own experiences as I know them better than any single other developers experience(s).  This is not because I feel that I'm the end all be all of coders.  Far from it, I do feel that I'm good at what I do, however I prefer to look at my writings as a form of navel gazing, a self-reflective ascertaining how I can better grow in my art and profession.  It is exactly the same manner in which I'm going to proceed regarding today's message.

As I have mentioned, I have most recently jumped into a contract situation at the personal request of a rather successful life-long entrepreneur and given that the opportunity sounded rather interesting, I turned down a salaried position worth almost double because the challenge that was proposed.  Please don't get me wrong, I took a position fixing a half-assed php open-source hot or not style rating system because the employee responsible by no fault of his own necessarily, and due to a lack of a sense of urgency was unable to get a system such as that prescribed, in place by a contractual client deadline.  This was not the reason I took the contract, whilst simultaneously being precisely why I took the contract. 

I'm not a fan of php in its current state (though it has been improved upon since my first dealings with the language), and most definitely not a fan of a vast majority of already written php applications open source or otherwise, but the latter point is more an issue with those specific applications and their designs and integrations.  What I am referring to more so is that I was brough into an environment where it wasn't the same old same old.  Now I wouldn't have stayed were the job going to continually require php specifically and exclusively simply out of my desire at the time to branch out skill-set-wise.   I did know that while I don't consider myself a web developer, I would be required on more than one occasion to work on web applications and having come out of many back-end intensive positions wasn't sure if this is somewhere I'd want to remain.

These weren't to all be simple ones either, any moderately proficient web developer and non-web developer alike could figure a good many of these solutions out.   What really did it for me was that I would be required to not only work under a fairly frequent set of short deadlines due to the nature of the publishing industry as well as the time frame required to keep the site and features current.

The importance of all off these ramblings is this simple point.  Being experienced and disciplined as a Software Engineer/Developer/Architect, etc. ad nauseam helps me to know 'what' I need to do, and gives me insight as to how I might go about solving an issue.  It is however, the actual specifics which put those tidbits of understanding and knowledge into play which go outside a given comfort zone.  It is only then, when we find ourselves in unfamiliar territory, under threat of tight deadlines coupled with our own personal desires to do our best and produce code to which we are proud to associate our name.  

I know that earlier in my career there were times (albeit very few, which I can honestly say) that I too fell into this 'comfort zone'.  I found out though, that this comfort zone is boring and causes one to stagnate.  We code because we love it.  Coding and problem solving is in our blood, and in our hearts.  It is how we look at the world and as such isn't something from which we can remove ourselves.  

If you only know low-level languages, learn a high level language.  If you only work in functional programming paradigms, learn object or aspect oriented ones.  If you only work with interpreted languages, learn compiled langauges, etc.  I'm not saying give up your current lingua franca, I'm simply saying expand your horizons.  The more ways you have of looking at, describing and ultimately understanding a given problem, the more ways you have to solve said problem.  This doesn't solely benefit you, it benefits everyone for whom your code will be written and utilised. 

You knowledge needs to be a living, dynamic pool of information, not a static, never changing one and the way to ensure that is to aggressively fight off the status quo.  Be aggressive, absorb all that you can.  The best way to do this isn't by dipping your toes into the shallow end of the kiddie pool, it is accomplished by putting on your goggles and climbing that high dive, plunging in head first.  

Take a chance for once, you might just learn something.  

Till next time..

The New Django Powered Inked Magazine Website is Up!

This will be rather brief as it is more of an announcement than one of my more traditional journal entries. 

After a  short two or so months from start to finish, I have successfully setup my first Django powered website.  Inked Magazine has been relaunched effective January 2nd, 2008.  This replaces the Joomla powered site which existed prior to both myself and the current ownership of the magazine were involved in the project.  

Phase one has been completed, with extras.  The customer photo galleries, the cover photo application, the user profile system as well as the main magazine feature areas have been established and are active.  As of today, I will have available for all registered users the ability to host a blog on our site (using our software which I wrote in a few days), mind you it is still early in the feature process, though it without doubt serves most blog authors needs.  

I will be adding features as time progresses, but until mid-January 2008, I'm on a tight schedule to build the entire forum application so that the beginning of the "New and Improved" Inked Network can go live.  

I don't think one needs Ruby on Rails when you have Django.  Much of the same great functionality and without having to use Ruby all the while using Python.  [Update: After having revisited Ruby as a language on its own, sans Rails notoriety, I've found that my previous assertions regarding Rails specifically was unwarranted.  It simply took my experiences with Django and Python to make Ruby and Rails far clearer to me.]

I will return to my normal posting after the Forum application is up and running.  

Till then, keep on coding.

In Buildings and Software, a Poorly Designed Foundation More Oft than Not Leads to Disaster.

Recently I’ve had the misfortune of being exposed to a multitude of software packages constructed in PHP and I have to say that I am very disappointed.  I’m not talking about the language specifically as it is capable, even though I haven't always been a fanatic regarding it as some one-language-only developers have, who wax poetically about the only tool in their toolbox.  I’m talking about code that unless run in absolutely perfect conditions (a.k.a. the developer’s machine/environment), the code fails to work as described by said developer.  This point alone stresses the importance of proper testing and the benefit of peer-based code review. 

I have noticed this issue as being more common in what I refer to as the ‘lazy languages’.  These are your weakly typed dynamic languages, specifically those lacking any real enforcement of data constructs, and lacking proper exception handling.  The lack of these two key language features don’t necessarily cause bad coding to transpire, but what they do is allow poor programmers (and non-programmers alike) to continue on with poor practices because nothing (on the compiler/interpreter end of the code) will dare to call said programmer(s) on his/her problems.  Careless coders will naturally gravitate to these languages as it lets them continue to live in their own little make believe world, the world in which they are competent coders and/or designers. 

This isn’t to say that there aren’t good or even great coders that didn’t start out in the same manner as mentioned previously.  It is all part of the learning process through which we grow.  This isn’t exclusive to coding obviously, but it most definitely is applicable.  The most important point which I need to stress is that recognising poor habits and working to eradicate said habits is paramount to becoming a better coder.  Don’t wait, act now.  The code you save may be your own.

Building a Better Box for a Client

As was mentioned in a previous entry, I stated that I was willing to try being an independent contractor again sometime.  That time is now.  As such, my new corporate overlords are a media publishing group and I’ve been called in to do a ground up architecture and engineering job, along with continued long term maintenance.  Unlike before this situation appeals to me because it lacks on of the most common issues in the realm of development in general, legacy upkeep.  Sure, there is the little issue pertaining to a php application which needs to be put on a website short term, but after that we’ll be trying to limit php to specific applications on a limited (only as-needed) basis.

Ultimately we’re looking at starting with a fresh new remote server and that being said, my own experience brings me down to a quasi LAMP setup.  Traditionally I’ve found that when I want a rock solid remote host, one which I know can go years on end in a reliable manner,  I chose FreeBSD.  Nothing against Linux other than I find it fine for a Desktop or a Server, but more so the desktop than the server.  I find that there still is no substitue for Apache when it comes to matters related in pushing out pages to the web.  

Next is a point of contention, the database.  I’ve been using MySQL since version 3.23.24a (or something around that revision number), and have found that it met my needs about half of the time.  Much of it (at the time) revolved around the issues pertaining to MySQL’s myisam faults and weaknesses regarding concurrence in high insert/update environments.   I know some people out there (many actually) will start arguing this point right away, and I still say unto you that this is a known weakness.  The myisam database storage engine is designed for speed, not high-concurrecy, nor transaction safety.  When paird with the InnoDB engine, and the removal of the auto-commit flag (as it negates the whole point of using a transaction safe engine), most of those issues disappear.  The other issues pertain to foreign keys, store procedures, etc., which have been slowly addressed in versions since the 3.xx base.  Now we’re at the 5.xx family and much has improved.  

However, all of these points still cause MySQL to pale in comparison compared to PostgreSQL.  True, MySQL has proven to be very capable and very popular, especially among the Linux crowd and cheap hosting crowd.  I will be installing MySQL on the new machine to handle support of third party web applications, though when it comes to hosting any important data, there can be only one choice, and it isn’t MySQL.  PostgreSQL is the clear winner here, the closest db engine we have to Oracle without being Oracle.  

Finally, we approach the last letter in our acronym.  The ‘P’, which can stand for a multitude of langauges scripting, web and otherwise.  We have PHP which is wonderful for quick and simple (an a handful of not so quick and simple) web based applications.  It is an easy language for the novice to learn, and in the hands of an expert, proves even more so capable, though it has its faults (as any language/tool does in reality), and among those security being the top.  Much effort has been made (especially post 4.2.3 and 5.x versions/trees, and I hope to see this evolution continue, though I still don’t see myself using it much at this juncture as I don’t feel compelled by the language as a whole comparatively to its competitors across the aisle.  

Next we move to another ‘P’, which in actuality is a ‘p’, perl.  The oldest of the languages we’re discussing here, but not by that much of a time frame.  Perl grew out of the personal needs of a C programmer, Larry Wall as a combination replacement of both sed and awk (amongst other Unix utilities).  I’ve been paid to code in Perl for the better part of the past 11 or so years, and I can say after all of that time several things.  On the good side, perl is found everywhere, has a large code base, and is fast.   On the bad side, I’ll have to limit my dislikes and faults found within perl so that this entry doesn’t go on for thousands of words.  Limiting my issues with perl we will see that it allows, almost seduces people into writing ugly, cryptic code.  Yes, yes, yes, the code some perl monks/mongers write may be very crafty.  Crafty does not equate with great, let alone good quality.  

All too often we see people referring to the TIMTOWDI (There Is More Than One Way to Do It) mindset of perl as being a benefit, though I see it (time and time against, countless of codebases later, even the CPAN library) as being a flaw and weakness.  If you don’t enforce a certain level of clean design into the language itself, you end up with a mess, or as many others have stated, a write-only language, one which even the author(s) of programs cannot read/decipher down the line.  My suggestion is for perl coders to follow Java coding guidelines.  I mean, we’re talking about a language that doesn’t has several decent levels of rules and coding enforcement (such as the ‘use strict’ pragma), but is so foolish as to allow people to code in a manner contrary to that pragma when it already exists in the core language.  How about a proper exception handling system?  Eval blocks or non-core/second-class libraries do not make a proper first class handling system.  This is asinine in a language that has been around for over 20 years as of this writing.  I could go on, but I’d rather not.

This brings us to a non-p ‘P’ in LAMP, Ruby.  Ruby to me is an evolution of perl in many regards, especially its object based design and proper exception handling system, however it still fails miserably in the sense of massive overuse of tokens and pascal-esque verbatim block terminators.  Rails has made Ruby a mainstream language, and I do feel that it has considerable potential ever more so than Rails alone, but it still has a ways to go when it comes to speed and cleanliness.  Matz has be working hard on it, and I’d like to think there are great things ahead for the language from the land of the rising sun, but at the current moment, I still find it lacking as non-web specific development platform.

Finally we come to where I’m heading, and I’m sure others have already figured that one out.  Python rounds out the last ‘P’ in the equation.  Python is almost as old as Perl, and is rooted in development languages as opposed to the shell and various utilities.  In this language we see a very capable, 100% object-based development language which is capable of handling coding projects of any size which espouses clean design, human readability, code re-use, distributable byte-code compiled classes/applications and proper exception handling as a first class citizen.  

So as we can see where, the solution i find most reliable and long-term maintainable with minimal development time, maximum return for design/coding efforts, security and platform flexibility is simple.  So it isn’t technically a “LAMP” solutions, more as it is a BAMPP solution encompassing BSD for the OS, Apache for the web serving, MySQL and PostgreSQL for the database(s), and Python for application development.  

I came to the above choices after years of experimenting and experiencing and I do suggest others experiment on their own if they have that luxury/time frame available to them, but I do offer the above as a recommendation as I would (and have, and will) bet my own future livelihood on the flexibility and reliability of the aforementioned combination of technologies.