Legacy is the dark beast of the development world. It's not a 'dark side', as a 'side' - whether good or evil, implies a balance. No, I'm talking about an actual living entity that will eat you alive the second you turn your back on it, and laugh maniacally while it does, for no other reason than it wants to and will get many LOLz.

All those rushed decisions made years ago in the heat of the moment, for whatever reason (deadlines, money, laziness, lack of perspective), come back to bite you so hard in the ass so hard it brings tears to your eyes. Usually, the person who made the application has moved on, and here you are looking at a screen with an overwhelming sense of dread.

The biggest problems with Legacy applications are (in no particular order);

  • Learning Curve
  • Ancient Technology
  • The Gotchas.
  • Documentation (or lack thereof)

Learning Curve:

This is the teething process of actually being proficient to write code for this application; knowing the structure of the code and where to look when things go wrong (because, you know, its Legacy and will usually go horribly wrong). This can vary greatly depending on the size, scope and complexity of the application, as well as understanding unnecessary complexity which seems to feature as standard in all Legacy applications in the Multiverse. This learning curve is compounded when the application has complex business processes driving it, with a good percentage of the knowledge in a select few people's heads. This is the time when you simply need to grit your teeth and fumble your way through until you see a light. Somewhere. At least, that's what I've heard.

Ancient Technology:

While the tech in which the Legacy application was written might sort of resemble what you're comfortable with, don't make the mistake of having the attitude of 'ah, its similar enough ill handle this no problem'. No. Just stop. While the technologies might seem similar, proficiently coding in whatever arcane tech is in question has its own bunch of little quirks which need to be learnt. Case in point; the ADO record sets used in Classic ASP?... RecordSet.MoveNext tripped me up more times than I'm proud of. Now, in a land of LINQ, nHibernate and even ADO.Net such a basic thing of moving to the next item in the bloody recordset might seem simple, but again, with how much of the heavy lifting today's technologies give us its an easy thing to miss. And an annoying thing given that if you forget, Classic ASP (in all its infinite wisdom) will spike the CPU to 100% and you'll be scratching your head as to why your PC has suddenly become non-responsive. And don't even get me started on switching entire languages (ie. C# to VB.net or VB6). All languages have their own little 'ways' of accomplishing things, and each is juuuuust enough different to feel like the equivalent of stubbing your toe on a really sharp knife.

(Side Note: If you are smart enough to hit the ground running with something like that good for you. But the rest of us mere mortals require an 'acclimatization period' :) )

The Gotchas:

In a way, this is related to Learning Curve but usually occurs well after you can actually find your way around a legacy solution. The Gotchas are the things that someone with a small amount of experience in this Legacy application will wisely nod their head and say "oh yeah, in this [insert really specific situation here], you need to [insert really obscure solution/hack/workaround]". Which brings me to my final point...

Documentation (or lack thereof):

Ahh documentation. Many a MB has been wasted on the internet with discussion of developers and their love/hate (OK, mostly hate) relationship with documentation. Personally, I don't see the big the deal... You write an application, you document it. Is it really that hard? I know people say "oh I hate writing doco"... well toughen up, princess. Its the support developers that will have to deal with what you've written, and giving them NO starting point is inexcusable as a developer. Coming from a support background, I suppose I appreciate good documentation more than most as I have felt the pain of being in an environment (several environments in fact) of no documentation. But seriously, I think we as developers need to grow the heck up. Goddamnit, document your stuff. ESPECIALLY the obscure stuff.

(Side Note: If you do encounter an environment with no doco, don't just leave it in that state. Use the 'Boy Scout Rule'; leave the place in a cleaner state than when you arrived. Document a few things (even if it is in your own time), and let the relevant people know where you have put the doco. Its just the right thing to do!)

Despite its frustrations, legacy can teach you a lot (of good things, that is) about software development if you approach it the right way. The good things it can teach you are (again, in no particular order);

  • Good Documentation Practices
  • Learning how to learn
  • How not to do something

Good Documentation Practices:

This is fairly simple. You encounter an area that isnt documented (or is documented poorly), and you fix it. And you fix it right. Legacy will make you document something in excruciating detail (more so than project development), as the emotional scars of what you've discovered give you a driving urge to make sure the next poor bastard that has to do something similar doesn't go through the agony and pain you went through. Document templates come in handy here as having a standard format will make you look awesome.

Learning How To Learn:

Legacy applications (and this can be applied to any application you haven't written personally) are a great way to hone your skills in understanding the various solutions and implementations that people come up with. You gain the ability to understand complex (even unnecessarily so) situations, and ensures your mind stays agile as we are all in a career where you can stagnate very easily.

How Not To Do Something:

If you are looking through an application, and you realize there is a great deal of pain (note; i said pain, not complexity) involved in what you are trying to understand, you probably want to avoid this way of doing things in future. This forms a 'lessons learned' aspect of software development... Something I wish more of us did at the end of each Next Big Thing(TM) as there are always mistakes made along the way. There's nothing wrong with mistakes (even massive ones) provided you learn from it and don't do it again.

While the agony of Legacy sometimes might not be worth the benefit, I think its good to be reminded of that beast waiting in the background for you to slip and gobble you up. At the very least the thought of that dark beast will keep you on your toes when writing the Next Big Thing (TM).

Night all :)