[pgsandstrom]

> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old.

Is it just me, or is less that four years not "really old"?

[Fradow]

There is a real difference between a properly maintained, up-to-date project that happened to be started four years ago, and a project that was started four years ago, has never seen any dependencies update (not even security fixes), and is dirty hack over dirty hack.

By the tone of the article, the author is clearly talking about the second kind.

[user5994461]

There was barely anything new outside of web development.

Java code, C++ and python from 2014 could be untouched and still working fine.

[jacquesm]

The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another.

Software does not age well when it isn't constructed properly.

[philbarr]

My favourite quote from, "Working Effectively With Legacy Code" by Michael Feathers:

"They're writing legacy code, man!"

[jacquesm]

I've - unfortunately - seen a case like that a couple of weeks ago. Very sad, moreso because they did not realize they were simply replaying the past. With all the best intentions of course.

[justherefortart]

My company is hiring a company for the 5th or so time to outsource IT to this new wonder app that will replace us. It's being built in Cold Fusion. Lmfao, 22 years old out of the gate.

So far they're about 2-3m in trying to replace us. Never gets far. Worst managed company I've ever seen. And as a consultant/contractor for 25+ years I've seen a lot of horribly run companies.

[troels]

CF still exists?

[justherefortart]

Apparently. I just started laughing when I heard about it. I'm going to pitch an ASP (classic) project next!

[troels]

I don't know if you're joking or not about the ASP classic.

[justherefortart]

I'm joking. I would not start a new project in Classic ASP in 2003, much less 2018.

I did like it back in the day though and it was still a better choice than .Net 1.0. .Net 1.1 was okay, by 2.0 it was pretty decent. 4.0 beyond is fantastic IMO. I'm a bit of an MS fan though. I like their tools.

[jimmy1]

In my opinion, when speaking of "legacy software", we should place a stronger emphasis on the actual meaning of the world legacy rather than the usual pejorative. Meaning that: this software has created a "legacy", in some form or fashion. Whether that legacy was it was used in the past to build the business, it paved the way for some standard or better practice, or it simply outlived it's time.

Downvotes are usually reserved for when a comment is low quality or not relevant to the conversation at hand. Could you please explain if my comment fit into these categories for my own learning? Thank you.

[eitland]

Like it or not but legacy has taken a new meaning in software.

I think it is Michael Feathers who defines it as code without tests in "Working Effectively With Legacy Code".

(That said, I didn't downvote you and I'm also tired of the abuse of the downvote button. I think in your case they downvoted because it seemed like unproductive nitpicking.)

[jimmy1]

Oh I know, that's why I am rebelling! I think words mean very specific things. I know it may seem like unproductive nitpicking, but in my experience the hundreds of discussions I have witnessed and been a part of myself in discussing legacy systems, bringing the pejorative version of the term to the table usually hinders the discussion more than anything, and it is this attitude that greatly contributes to the "software is eating the world" problem we soon to experience with everyone recreating the same library every day instead of reusing existing, proven solutions -- talk about unproductive!

"Back in my day", legacy systems were admired! I mean, heck, they were still there because some team(s) were using them every day, more often than not, they were there because they made money.

As one famous software engineer once said, "'Legacy code' often differs from its suggested alternative by actually working and scaling."

NASA was reusing code written from the 70's all the way up to 2011! Surely there is something in this wonderful land of legacy code that is worth saving? Or how about our operating systems? Full of wonderfully working legacy software that might just need a touch of love, rather than the usual thrashing of "how stupid those other devs were" and a total rewrite, which is what usually happens sadly.

In any case, I think another poster may have touched on it, I think we as engineers should try to refrain from flippantly labeling anything that is essentially "old" (where "old" might be 6 months, 2 years, or 10 depending on the organization) as the pejorative form of "legacy software", and just call it what it is -- bad software, some of which may also be legacy to your organization. But the conflation of the two terms is not helpful and adding to the confusion.

[jacquesm]

I've worked on old but very well maintained code that could easily go another two decades or more. Probably the original writers have long departed this world. But what they put together was put together with either incredible forethought or impeccably kept up-to-date. It was hard to tell which because this stuff was built before the age of version control, which gives you a bit of an idea how old it was. I would consider that 'mature' code, but not necessarily legacy.

Legacy code to me is code that has become hard or even impossible to maintain. Code that people avoid working on, not because it works, but because they are afraid of it.

Sure there are still lessons to be learned from such code, and you will learn those lessons the hard way if you have the temerity to mess with it. But every now and then someone is tasked with fixing a bug or adding a feature that can no longer be avoided and the send-offs are comparable to talking for the last time to people that are about to descend into a mine or something to that effect. Everybody knows there is a good chance we won't be seeing them again for the near future, if the axe of demotivation doesn't cull them from our ranks.

[jacquesm]

I like that definition. Maybe another one: code that nobody knows intimately.

[Clubber]

I've always known it as software that exists and is actively being rewritten, so a mainframe system would be the legacy system while writing a new Windows application to replace it.

[bethly]

Anyone can pitch a tent: building a house is harder.

Given that we need a lot of housing and we don't have many home builders, there are a lot of tents floating around this industry.

[dwc]

Of course it's not really old. Though in my experience age has only a loose correlation to overall code quality. Some really old programs were well architected to start and have been carefully maintained. OTOH, I've worked with devs who are one-person technical debt factories, and allowed to work on relatively young and sparse applications will quickly make it an unmaintainable monstrosity.

[stochastic_monk]

My lab has a tool which has been actively maintained for 10 years and has a full-time employee supporting it and a related follow-up from 3 years later.

It takes a lot of effort to keep cross-platform support while continuously improving it. Granted, not every project deserves that kind of effort, but I respect the effort it takes to keep software up-to-date.

[sesutton]

I suppose it is for webdev. I regularly work on C code that's nearly as old as I am.

[_asummers]

As an Elixir dev, popping open old Erlang code bases is always an interesting experience. Some of those haven't even been touched in the last 4 years!

[shadowmint]

Funny how no one has any meaningful advice, just some snark about those dang young developers. Get off my lawn!

That line wasn't the important part of this post. This one was:

> You should also have a global self-development plan. If you can’t put it into practice under the scope of the project, you should spend your free time on it.

Damn straight.

If you work somewhere with tight deadlines and rubbish code quality, and you're just sucking it up and writing rubbish code, you're part of the problem.

You should always have a plan about how to become a better more effective developer where ever you end up working. Sometimes that means plan to spend 10 minutes a day talking to your project manager. Maybe review code the last 1/2 hour of the day. Maybe make some internal tools to help automate your job.

Don't just sit there and be miserable; if your job/company sucks and you can't find a way to change it, at the very least make it a stepping stone to something better.

Some idle advice from my experiences working in places which sucked:

- If you write code, it should be good code. Even if other code is bad, that's no excuse to stop caring.

- ...but, you dont need to refactor that. Just do what you have to do, and make it as good as it can be under the circumstances. Don't break other things when you make things cleaner and better; that makes PMs think that 'good code' = 'break features'. Disaster.

- If you ship rubbish to 'come back and fix later', you'll never come back and fix it.

- Don't just comment out code and replace it a quick fix. Don't [Ignore] failing tests. If code is going away, take responsibility of actually delete it.

- Don't leave 'TODOs' in your code; either do it, or don't. No one is ever going come back and do your TODO. Not even you. That's what issue trackers are for.

- Some developers don't like running with 'trainer wheels' or 'guard rails' as they refer to unit tests. Ignore these people. Always write tests. The worse the place you work is, the more desperately you need those tests.

- Project managers (unless utterly incompetent) don't care about deliverables per se; they care about managing expectations. Estimate. Review your estimates. Try to deliver on your estimates.

- Don't work overtime unless it'll actually make a tangible difference for a specific deadline. :)

[ndh2]

This is very good advice.

I would change the last point to: Don't work overtime unless you, personally, get something out of it. That something might be not getting fired. But if it doesn't get you anything... Don't do it.

[pjc50]

Hah! The code I'm working on at the moment is full of banners saying

// Copyright (C) 1991 - 1999 Rational Software Corporation

I think it actually originated in 2002 and those are junk left over from the use of Rational Rose code generation. Revision history only goes back to 2007.

[vorg]

> Revision history only goes back to 2007

Perhaps a former programmer deleted the revision history when they were about to move into a management role at your organization. I once stumbled upon a manager's name in the history of a 1970's Cobol program which had a goto statement every 5 lines, and it usually took half a day to make a simple change. All of the other similar-looking programs had had their history purged. When I showed the history notation to the manager, the look on his face wasn't nostalgia but fear.

[sametmax]

Not old. The author is probably young. Or a js dev. Or both.

[dentemple]

The author clearly explained his background in the article.

[fodoj]

it's she :)

[s73v3r_]

How software is constructed has a huge impact on how well it ages. It can age like a Tolkien elf, or it can age like a fruit fly.

[user5994461]

What the software is constructed has a huge impact on how well it ages. If it's javascript...

[dspillett]

That is barely out of adolescence. Part of my day job is shepherding a large legacy web application into final retirement. 18 years and still trundling on, longer if you count the desktop applications that came before in the product line. Still getting new development time allocated to it too, most recently implementing improvements to help the clients comply fully with GDPR. Traced a problem in production back to a bug introduced 13 years ago just the other day...

[bethly]

I worked on code that had been in active development for sixteen years, but it only got to be sixteen-year-old code because it was reasonably well-written and maintained. Code quality and developer skill is what lets software become older than four years old without collapsing under its own weight.

[hiccuphippo]

That's like 20 years in JavaScript years.

[yoodenvranx]

> Is it just me, or is less that four years not "really old"?

In the JS world 4 years is very old bu in the C/C++ world 4 years are still quite fresh.

[Terr_]

That seems pretty fresh to me, but I may just be jaded: I'm working with a mission-critical PHP project with portions -- including fossilized third-party libraries -- fossilized since 2009.

[bbarn]

It is for the author who got his first paycheck last year.

[JoeAltmaier]

My sister (contracting to a large global tire company) texted me yesterday, that she'd had to modify a module that was 30 years old!

[chii]

the javascript mentality!

software isn't old until it breaks 10 yrs!

[oblio]

Debatable. Just as people, some software ages badly. Heck, sometimes it's just born old :-)

[kabes]

It's just that the javascript language, frameworks and ecosystems have seen massive changes over the last couple of years. C for example hasn't seen this change. So yeah, C code from 5 years ago would look the same if written today, while javascript of just 2 year old might seem outdated.