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

51–60 of 76 posts

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

#51

Post by avgDev »

mattmanser wrote: post #45
avgDev wrote: post #14

I am currently rewriting a 10 year old VB application, which is in web forms. That application communicates with AS400 DB2 database. I get to use as400 here and there. My application is in .NET Core 2. There are some issues as anything IBM can be a pain in the ass to work with. Also, the as400 dev and me have a tremendous knowledge gap. I know everything new such as unit testing, proper source control, dependency inj…

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.

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

#52

Post by avgDev »

larrik wrote: post #17
avgDev wrote: post #14

I am currently rewriting a 10 year old VB application, which is in web forms. That application communicates with AS400 DB2 database. I get to use as400 here and there. My application is in .NET Core 2. There are some issues as anything IBM can be a pain in the ass to work with. Also, the as400 dev and me have a tremendous knowledge gap. I know everything new such as unit testing, proper source control, dependency inj…

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.

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

#53

Post by rocky1138 »

magashna wrote: post #3

It's kinda dumb but I do like this children's book retelling of software development

I wanted to update my comment but for some reason I can't. I mistakenly said Java Koans when I actually meant The Codeless Code, located here http://thecodelesscode.com/contents. Sorry about that!

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

#54

Post by lsh »

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…

I think you missed the point. Whatever you call your code, monolith or microservice, it's still code and tomorrow or next year it will be legacy code. I'm not sure if the size of the codebase actually matters, developers just want to develop and will move on quickly to the next thing. It takes time and patience and persistence to maintain legacy code and the systems it's embedded in and it's far from sexy or exciting. The young dominate IT and are way more idealistic and filled with enthusiasm and new ideas than those of us who are getting on. They want to make their mark and solve the world's problems and that means more and more code! But new code! This new code will be better, you'll see.

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

#55

Post by zadokshi »

mattmanser wrote: post #45
avgDev wrote: post #14

I am currently rewriting a 10 year old VB application, which is in web forms. That application communicates with AS400 DB2 database. I get to use as400 here and there. My application is in .NET Core 2. There are some issues as anything IBM can be a pain in the ass to work with. Also, the as400 dev and me have a tremendous knowledge gap. I know everything new such as unit testing, proper source control, dependency inj…

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…

100% test coverage is not so valuable. But, I would argue that test coverage for the bits of complex logic that people are “afraid to touch for fear of breaking it” are valuable. Create tests for this code before you change it for assurance you haven’t broken it. If there are weird border cases the original developer wants to ensure remain supported, you need a test case for it.

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

#57

Post by touristtam »

backslash_16 wrote: post #16

For anyone who wants to learn about working with and on a "legacy" code-base, check out Michael Feather's book "Working Effectively with Legacy Code" In the beginning it goes over code smells and how to find refacing seams in your language of choice (C, C++, or Java) and then each chapter is a group of techniques you can use. Working on a service that had both a very old monolith and some brand new microservices, I f…

> I think the first lesson I applied from it was using pinning tests for safer refactoring.

Thanks for the book recommendation. Funny to realize I have done this in the past without prior knowledge; it just made sense.

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

#58

Post by Animats »

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 virtual world, has that problem. It's written in C++, and some very good people wrote it about 10-15 years ago. They're all gone. The people who maintain it today are struggling to fix serious bugs that have been outstanding for 5-8 years. It's not just "legacy", it's "not web-like". It's a distributed system with tens of thousands of servers in one data center. It's a tightly coordinated soft real time system. There's a huge amount of in-memory state, which is changeable in real time yet is constantly being backed up. This is totally alien to people who only know transaction-type web-based systems. So they can't hire anybody and have them be productive quickly.

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

#59

Post by bjt »

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 devs I'd imagine.

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

#60

Post by burnto »

8note wrote: post #47
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…

one skill I've learned working on/deprecating and replacing legacy code is what I'd call Code Archaeology: the practice of identifying what a legacy system does given some edge case; why it does it; whether that's the right thing to do, given that the ecosystem has changed significantly; and whether that section can be safely turned off. I haven't seen the results of putting that on a resume yet though.

Author Vernor Vinge describes a future "programmer–archaeologist" role in his books. The idea being that humans just keep building layer upon layer of abstractions and systems, and in the distant future there's value in exploring, understanding, and potentially modifying the older layers.
Post reply on HN