Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The little legacy code that could: a fable of software ownership

circleci.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: The little legacy code that could: a fable of software ownership

#61

Post by mattmanser »

avgDev wrote: post #51
mattmanser wrote: post #45

Earlier quoted context omitted.

Having been someone who's had to "setup" the db, app, etc. before ORMs were mainstream, you're wildly overestimating how complicated it was. It doesn't actually take very long, you'd maybe save a couple of days or so on a month project, having to write a a CREATE TABLE and then the corresponding class are actually trivial. You make the design decisions when you write the create statement, the class is simply a copy o…

Interesting perspective. I do agree that it is not good that he did not keep updating his skills but he has a few clients even bigger than us and is going to retire soon, AS400 has served him very well.

I've met programmers who've done the same thing (for COBOL).

I personally would not enjoy it as all you end up doing is maintenance and working with nasty old code bases.

Re: The little legacy code that could: a fable of software ownership

#62

Post by amelius »

simion314 wrote: post #19
larrymyers wrote: post #6

This is one of those interesting paradoxes that I haven't figured out yet. Owning the legacy software that runs the business tends to provide job security at your current job, but can hinder your professional growth at both your current job as well as any future jobs. Getting on to projects that are intended to replace legacy software tends to get you a lot of positive visibility politically and the ability to learn…

I take pleasure in refactoring code, fixing bugs that customers hit and the satisfaction I have when that user gets a quick fix or solution for his problem.

This only works when you have a test suite with total coverage. Otherwise, you're bound to introduce bugs and annoy users and colleagues.

Re: The little legacy code that could: a fable of software ownership

#63

Post by oaw-bct-ar-bamf »

on_and_off wrote: post #46
noir_lord wrote: post #36

Earlier quoted context omitted.

Most of my career has been working on legacy projects (or fixing broken ones), I like greenfield well enough but I’ve no preference for it over maintenance. There is as much pleasure in making something broken work properly as creating the thing (imo). It’s a steady career as well, most programming is maintenance outside of the fail fast world of startups.

Even at my current job in a startup, 90% of the code I own can be considered legacy. The startup is 7 yo, I joined almost 2 years ago. The gap between old and new features is enormous .. and it will take years to reach some cohesion.

I am relatively new to a project that is being sold and used in the order of millions for approximately 25 to thirty years.

It was refreshing to find out that one of the approximately 7 languages that contribute to the final executable that was abandoned in ~2007 has been revived and is now (2016ish) being maintained by Eclipse

These kind of things make you realise that the Silicon Valley way of doing things is not the silver bullet.

Re: The little legacy code that could: a fable of software ownership

#64

Post by simion314 »

amelius wrote: post #62
simion314 wrote: post #19

Earlier quoted context omitted.

I take pleasure in refactoring code, fixing bugs that customers hit and the satisfaction I have when that user gets a quick fix or solution for his problem.

This only works when you have a test suite with total coverage. Otherwise, you're bound to introduce bugs and annoy users and colleagues.

Tests are nice to have but there are not that many tests in the projects I work. Sometimes the code is not that critical, no lives and money at risk. Then I do not refactor the entire project but only 1 section and I refactor it because it is required, like I discover a function with 5 level of nesting and 500 lines of code, if I do not rush then refactoring should be simple and I can reduce the big function in a few smaller functions , reduce some big unclear code in something that is readable like a story.

I agree that someone handing you a project that you have no idea what it does, what the features are and going and randomly refactor is stupid.

Re: The little legacy code that could: a fable of software ownership

#65

Post by zbentley »

urthen wrote: post #5

Cute story, but I detect a certain bitterness and refusal to accept the "future" of software engineering is actually the "now." People didn't think up microservices yesterday, they aren't some hot new fad that'll be forgotten in a year, and they aren't being developed because people just have nothing better to do. They're replacing legacy systems which nobody wants to touch at a rapid clip. People don't like working…

> In the context of this story, well... your protagonist is actually on life support. But not to worry! They'll be taken off it soon...

"Soon" is often...not soon. I have never, ever seen a legacy system of any substantial complexity taken fully offline. Nor have I seen even partial replacements for such a system deliver a reliable alternative anywhere close to on time. In fact, I've seen more half-baked successors be either scrapped or put on life support themselves than I have seen get even into the ballpark of what could generously be considered success.

Re: The little legacy code that could: a fable of software ownership

#66

Post by larrik »

yellowapple wrote: post #32
larrik wrote: post #17

Earlier quoted context omitted.

I worked at an AS/400 shop out of college (this was in the 2000's, though). The other programmers there did NOT have a better understanding of low-level programming than me. In fact, it was hard to call them programmers at all.

Yeah, a lot of AS/400 programming is actually pretty high-level (comparatively speaking). COBOL in general was meant to be accessible to end users (or at most power users) such that they could readily define business logic without having to resort to something like assembly or PL/I or what have you.

Yeah, these guys didn't really know COBOL either. They used RPG (an AS/400 exclusive language).

Re: The little legacy code that could: a fable of software ownership

#67

Post by larrik »

avgDev wrote: post #52
larrik wrote: post #17

Earlier quoted context omitted.

I worked at an AS/400 shop out of college (this was in the 2000's, though). The other programmers there did NOT have a better understanding of low-level programming than me. In fact, it was hard to call them programmers at all.

Is there any resources you could recommend? I would interested in maybe learning more.

What are you looking to learn more about?

When I learned RPG, it was through physical audio tapes. In 2005, with broadband. I haven't come across to many good places to learn from (but I haven't really been looking, either).

Re: The little legacy code that could: a fable of software ownership

#68

Post by on_and_off »

oaw-bct-ar-bamf wrote: post #63
on_and_off wrote: post #46

Earlier quoted context omitted.

Even at my current job in a startup, 90% of the code I own can be considered legacy. The startup is 7 yo, I joined almost 2 years ago. The gap between old and new features is enormous .. and it will take years to reach some cohesion.

I am relatively new to a project that is being sold and used in the order of millions for approximately 25 to thirty years. It was refreshing to find out that one of the approximately 7 languages that contribute to the final executable that was abandoned in ~2007 has been revived and is now (2016ish) being maintained by Eclipse These kind of things make you realise that the Silicon Valley way of doing things is not t…

Yep .. it is always painful to hear stuff like "if you don't use [insert whatever is hype right now]; then you are not a real engineer" coming from a colleague.

People that have spent their careers in the silicon valley have a very distorted view of tech.

Re: The little legacy code that could: a fable of software ownership

#69

Post by Animats »

bjt wrote: post #59
Animats wrote: post #58

The underlying technology doesn't have to be obsolete to have legacy code problems. Linux, Windows, GCC, Microsoft Office - all have serious internal problems from legacy code, and are tough to maintain. It's not so bad for big projects with enough staff. It gets tough when the legacy code does something hard, and the maintenance team doesn't really understand why something was done in some way. Second Life, the virt…

Doesn't that describe a lot of MMOs too, though? The inventory/transaction systems seem like they'd have similar needs (but with a LOT more items in the Second Life database). And the in-world state is a lot more variable than in an MMO. But compared to MMOs, those seem more like differences in degree than differences in kind. Programmers with that background should be able to get productive a lot quicker than web de…

Most major games are built on one of a few game engines (Unity, UE4, etc.) which have their own ecosystems. People become Unity or UE4 experts. They have forums, conferences, tech support. SL is its own pocket universe.

Second Life is divided into "regions", 256m on a side, each managed by a separate process constantly communicating with its neighbors. This geographical distribution system is unique to Second Life. User avatars and objects can move from one region to another. You can look across region boundaries. Running Mono programs inside objects are stopped, frozen, copied across the network, and restarted on a different machine.

Most big-world MMOs cheat somehow so that they don't have to really solve the distribution problem. They're often sharded, so that the number of players that can interact is limited. Or they're smaller. Second Life's world is 100x the size of GTA V. Or they're portal based; you can only get somewhere via a controlled portal. In Second Life, you can fly over the whole world. (Mostly. Fast vehicles hit bugs the devs have been unable to fix for a decade. Another "legacy" problem.)

This is what the machinery for a "Ready Player One" or "Snow Crash" world looks like.

It's not parallel enough, and the servers keep running out of CPU time on the main thread. Everything then gets sluggish in world. The system needs an overhaul to be more parallel internally on the core functions, and that's really hard, expensive, and needs a dev team the company lacks. Yet another legacy problem.

The technology is all unique to this one system. The only thing that works even vaguely like this is the new Spatial OS from Improbable, which took 150 people to develop, is proprietary, and hasn't been shown to really scale yet. We'll know late this year, as Nostos, a new game from China, rolls out, how well it really scales. That's the first AAA title to use Spatial OS. Spatial OS has a deal with Google where it has to run on Google Cloud servers, which is scaring off most of the big game development shops. That costs too much, and betting your business on a lesser Google product usually ends badly.

Hence the recruiting problem Linden Lab faces. You want to tie your career to this one-off strange system?

Re: The little legacy code that could: a fable of software ownership

#70

Post by bjt »

Animats wrote: post #69
bjt wrote: post #59

Earlier quoted context omitted.

Doesn't that describe a lot of MMOs too, though? The inventory/transaction systems seem like they'd have similar needs (but with a LOT more items in the Second Life database). And the in-world state is a lot more variable than in an MMO. But compared to MMOs, those seem more like differences in degree than differences in kind. Programmers with that background should be able to get productive a lot quicker than web de…

Most major games are built on one of a few game engines (Unity, UE4, etc.) which have their own ecosystems. People become Unity or UE4 experts. They have forums, conferences, tech support. SL is its own pocket universe. Second Life is divided into "regions", 256m on a side, each managed by a separate process constantly communicating with its neighbors. This geographical distribution system is unique to Second Life. U…

I'm familiar with Second Life's distinctive traits. I played there for years, and did contract programming for the Linden Department of Public Works for a couple of them (including coding around those janky region crossing issues you mention).

They pay an incredibly high price for some design decisions that I think users don't even get much value from. It turns out that most users would rather have a private island than live on a continuous continent where neighbors are always putting up eyesores. If you were to start with that fact, remove the requirement that private regions even exist on the global map, and let them spin down when no one's home, then you could give paying users a lot more space for their money while also reducing the company's spend on servers.

While I take your point about work on Second Life not being super transferrable to any of the AAA game engines, it seems like it would be very transferrable to creating such engines themselves. And what engineer wouldn't want to help build the world of Snow Crash or Ready Player One?

I think the deeper problem is that Linden Lab has stopped prioritizing investment in the SL platform. They've set their sights on creating VR-focused Sansar instead. But it's tough to convince people to move over to a new world when it means leaving behind the bigger community, the bigger economy, and all the clothes in their inventory.

Post reply on HN