Legacy Code — It’s Everywhere

-
“Legacy Systems” mean different things to different people, with the variation usually being based on backgrounds
  1. 1. Something the previous person wrote: Common in “startup culture”, and typically used for libraries and/or apps that were written by somebody else. A variant of this is when you are the “previous person” — remember, code is either growing or staling.
  2. 2. Something that the company used to rely on: Common in “larger” companies or enterprises, and refers to systems/components that were part of a business-line that is just not the focus anymore — and have, consequently, most of their development focused on maintenance. A variation of this theme is when the business-line is so “mature” that the underlying code is a few tech-generations old (“CORBA? Good god!”)
  3. 3. Something running on mainframes: This isn’t just a variation of -2-. For a lot of people (especially folks that came from the dawn of the internet age), “legacy” specifically refers to mainframe stuff.
Legacy isn’t just a pejorative. The longer you’re around as a viable business, the more legacy stuff you accumulate. Think of all the code you’ve written, all the frameworks from the past, all the processes that exist to deal with edge cases, all the skills that you no longer use, and then multiply that by all the people that work in (or ever have worked in!) your company. That is all legacy. As Damon Edwards puts it , Legacy is the historical record of an organization’s success!

/via http://www.commitstrip.com/en/2016/02/15/our-companys-greatest-project/
The common thread across everything “legacy” is that they tend to be used as black-boxes, until the time comes to actually patch, update, or replace it — which is when the swearing starts. And there are a lot of these black-boxes scattered in your company. After all, it’s not just “no man is an island” — virtually everything in your company is interconnected with everything else.
Keep the above in mind the next time you’re upset at that piece of legacy code that you have to deal with. Sometime soon — maybe even right now! — somebody else is probably going to be doing the same thing with your code.
Update: There is a corollary to the above — when you’re working on a legacy system, and find something you admire, make note of it. Add it to your tool-chest — after asking yourself why it wasn’t already there in the first place. And most importantly, let the author(s) know, they’ll appreciate it!

Comments

Post a Comment

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

-
Image
The nice thing about garbage-collection is that it is makes memory management absolutely transparent to you Of course, the above is true right up to the point when it stops being transparent, at which point it does a phase change from nice to clusterf**k of biblical proportions .  There are entire posts, books, and suicide notes that have been written about this, and I have no great desire to add to them, save with the minor comment that paranoia about garbage-collection is still justified , albeit only in the edge-cases for most people. That said, I'll give you that Erlang GC is in many ways much, much better positioned in this regard than, oh, Java, but it still rears up and bites you in the butt when you least expect it. ( More information about Erlang's GC vis-a-vis Java here , and Jesper's truly excellent description of Erlang's GC here ).  A story from the past should serve to illustrate this. Once upon a time, in a magical land far far away - well, Her
Read more

Visualizing Prime Numbers

-
Image
From Jason Davies , we have El Patron de Los Primos , probably one of the coolest prime number visualizer that I've seen.  For every Natural number, he draws a periodic curve that intersects at that number and each of its multiples.  Needless to say, prime numbers are touched by only two curves (itself and 1 ). You can scroll to the right, and move up the prime food change. (The image above is a screen grab.  Go here to see the actual thing)
Read more

Its time to call Bullshit on "Technical Debt"

-
Image
Seriously. You know what " Technical Debt " is, right? Ok, heres the (official?) Wikipedia definition   Technical debt   (also known as   design debt   or   code debt ) is a   neologistic   metaphor referring to the eventual consequences of poor or evolving   software architecture   and   software development   within a   codebase . The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future. And in this - somewhat purist - sense, " Technical Debt " is absolutely valid. The problem arises in the way it is almost invariably used, viz., as an excuse to not do something. Herewith a simple exercise - the next time you hear someone cite &quo
Read more