4 ms·

Legacy code from 2009. I'm getting old.

by tus88 7y ago

EliRivers 7y ago
Admittedly playing around with the definition of "legacy code" (and I get what you meant - I'm just playing with the words!), this particular set of code is legacy code from 2009, but I think I could argue that some of the world's legacy code was written yesterday, and there is code from decades ago that is not legacy code. This particular set, though, was legacy code pretty much the week after it was written :(
- olikas 7y ago
  I have played with this idea recently lately. I consider almost all code out there as legacy. I was talking about it at a conference also explaining how I like working with legacy code. (https://youtu.be/n0XCMHrSbwc https://youtu.be/n0XCMHrSbwc) I think I’m the odd one who actually like working with legacy code.
  - repsilat 7y ago
    > I think I’m the odd one who actually like working with legacy code. I had a fun bit of legacy code wrangling a month or so back. I looked at production profiles of some very compute-heavy jobs (we have great tools for that) and found we were spending ~half of my pay on cloud compute in this one library function -- deep equality checks for a kind of object. The equality-checking code itself is very slow, significantly slower than hand-written alternatives, but the objects are complicated (though luckily tree-like in structure) so hand-writing equality comparison functions would be a nightmare. Many of these structures had "id" fields, though. Gasp, could we just compare ids instead of doing deep equality checks? So I asked around, and nobody knew. Nobody even knew what the code was for. It'd be trivial to replace the deep equality checks with id comparisons, but we can't do it. Seeing how some legacy code works is one thing. Data comes in here, data goes out there. Knowing which invariants the code is trying to maintain, though, what properties it assumes about the data here or there (Sorted? Unique? Up to date? All belongs to the same user?) makes making changes difficult, though. It means you need to write defensive code that the original authors would find ridiculous, because you don't have their institutional knowledge, and can't derive it locally in the code, and can't inspect it at runtime (or be sure that prod won't send a counter-example the day after you deploy to production.)
pault 7y ago
To me, "legacy" just means undocumented code that isn't well understood by anyone currently working in the code base. By that definition, pretty much anything written by your average contractor is legacy code.
WalterBright 7y ago
I'm still running/maintaining code I originally wrote in the 1980's. https://github.com/dlang/dmd/tree/master/src/dmd/backend https://github.com/dlang/dmd/tree/master/src/dmd/backend
- tus88 7y ago
  Wow, I didn't realize D went back that far. I thought C++ came in the early 90s and D naturally followed as a "better version" after that. Very cool.
  - WalterBright 7y ago
    It was originally for a C compiler, and work started on it in 1983 or so.
labster 7y ago
I'm pretty sure I'm writing some legacy code from 2019 right now.
- TheBones 7y ago
  Every time I go back to write code I had previously worked on. I go, did I write this!? Everyday is legacy code! Truth
  - cjfd 7y ago
    Although this is normal in the sense that it often happens it should not be considered normal in the sense that it is a situation that should be allowed to endure. You should educate yourself up to the point that it no longer is true. The thing that greatly increased my quality as a programmer is to learn TDD and also the book 'Working Effectively with Legacy Code' by Michael Feathers. It might be something different for you but you should go find out what it is.
    - davidjnelson 7y ago
      Great book. I think a lot of people want to test, but lack skills. Testing software is actually quite difficult. You have to know what to test, then how. I love tdd, but I find it takes too long for businesses to tolerate, so usually I have to test after to hit deadlines. Tdd works great for pure functions with logic. But things like ui integration tests (not to be confused with functional tests) are very time consuming to write with red green rafeactor tdd.
      - cjfd 7y ago
        I am not sure TDD really takes that much longer. Writing the tests certainly takes time but if you don't write tests you will have to spend more time testing the software manually. If the test is a sequence of 20 click in a web interface and you have to do that multiple times before it works that also costs time and you are probably not going through every scenario in that case so errors can remain undiscovered for some time. I don't always do TDD in a 100% strict way. The duration of the TDD cycle varies for me mainly depending on how practical a very short cycle is and also depending on how complex the software is. I have found that overly obsessing about very short cycles can be inefficient. Also, I tend to test a cluster of multiple classes instead of a single class or a single method. I think the subject that a test is about should be something at a level that is a bit higher, perhaps even something that the customer could recognize as something they value. If you do not do that you might be testing implementation details that are very much subject to change. Testing at the right level also can save quite a bit of time. I don't write user interfaces that often and when I do they are mostly not that fancy. In that case I have sometimes written tests that check that the HTML output is correct. In the case of things that are purely visible I quite often first fix the thing and then write a test because the browser in my head is not always quite good enough to write a correct test beforehand. I have generally found that management was encouraging towards writing test in places where I have worked. Occasionally I have been praised for writing high quality software but also sometimes got the remark that sometimes things were taking a longer than expected. Everybody should be able to understand that there is a trade-off here. I would not want to work in a place where they produce as much crap as possible in as little time as possible. Lack of quality is quite hard on me emotionally.

Legacy code from 2009. I'm getting old.

by tus88 7y ago

Legacy code from 2009. I'm getting old.

Admittedly playing around with the definition of "legacy code" (and I get what you meant - I'm just playing with the words!), this particular set of code is legacy code from 2009, but I think I could argue that some of the world's legacy code was written yesterday, and there is code from decades ago that is not legacy code. This particular set, though, was legacy code pretty much the week after it was written :(

olikas 7y ago
I have played with this idea recently lately. I consider almost all code out there as legacy. I was talking about it at a conference also explaining how I like working with legacy code. (https://youtu.be/n0XCMHrSbwc https://youtu.be/n0XCMHrSbwc) I think I’m the odd one who actually like working with legacy code.
- repsilat 7y ago
  > I think I’m the odd one who actually like working with legacy code. I had a fun bit of legacy code wrangling a month or so back. I looked at production profiles of some very compute-heavy jobs (we have great tools for that) and found we were spending ~half of my pay on cloud compute in this one library function -- deep equality checks for a kind of object. The equality-checking code itself is very slow, significantly slower than hand-written alternatives, but the objects are complicated (though luckily tree-like in structure) so hand-writing equality comparison functions would be a nightmare. Many of these structures had "id" fields, though. Gasp, could we just compare ids instead of doing deep equality checks? So I asked around, and nobody knew. Nobody even knew what the code was for. It'd be trivial to replace the deep equality checks with id comparisons, but we can't do it. Seeing how some legacy code works is one thing. Data comes in here, data goes out there. Knowing which invariants the code is trying to maintain, though, what properties it assumes about the data here or there (Sorted? Unique? Up to date? All belongs to the same user?) makes making changes difficult, though. It means you need to write defensive code that the original authors would find ridiculous, because you don't have their institutional knowledge, and can't derive it locally in the code, and can't inspect it at runtime (or be sure that prod won't send a counter-example the day after you deploy to production.)

pault 7y ago

To me, "legacy" just means undocumented code that isn't well understood by anyone currently working in the code base. By that definition, pretty much anything written by your average contractor is legacy code.

WalterBright 7y ago

I'm still running/maintaining code I originally wrote in the 1980's. https://github.com/dlang/dmd/tree/master/src/dmd/backend https://github.com/dlang/dmd/tree/master/src/dmd/backend

tus88 7y ago
Wow, I didn't realize D went back that far. I thought C++ came in the early 90s and D naturally followed as a "better version" after that. Very cool.
- WalterBright 7y ago
  It was originally for a C compiler, and work started on it in 1983 or so.

labster 7y ago

I'm pretty sure I'm writing some legacy code from 2019 right now.

TheBones 7y ago
Every time I go back to write code I had previously worked on. I go, did I write this!? Everyday is legacy code! Truth
- cjfd 7y ago
  Although this is normal in the sense that it often happens it should not be considered normal in the sense that it is a situation that should be allowed to endure. You should educate yourself up to the point that it no longer is true. The thing that greatly increased my quality as a programmer is to learn TDD and also the book 'Working Effectively with Legacy Code' by Michael Feathers. It might be something different for you but you should go find out what it is.
  - davidjnelson 7y ago
    Great book. I think a lot of people want to test, but lack skills. Testing software is actually quite difficult. You have to know what to test, then how. I love tdd, but I find it takes too long for businesses to tolerate, so usually I have to test after to hit deadlines. Tdd works great for pure functions with logic. But things like ui integration tests (not to be confused with functional tests) are very time consuming to write with red green rafeactor tdd.
    - cjfd 7y ago
      I am not sure TDD really takes that much longer. Writing the tests certainly takes time but if you don't write tests you will have to spend more time testing the software manually. If the test is a sequence of 20 click in a web interface and you have to do that multiple times before it works that also costs time and you are probably not going through every scenario in that case so errors can remain undiscovered for some time. I don't always do TDD in a 100% strict way. The duration of the TDD cycle varies for me mainly depending on how practical a very short cycle is and also depending on how complex the software is. I have found that overly obsessing about very short cycles can be inefficient. Also, I tend to test a cluster of multiple classes instead of a single class or a single method. I think the subject that a test is about should be something at a level that is a bit higher, perhaps even something that the customer could recognize as something they value. If you do not do that you might be testing implementation details that are very much subject to change. Testing at the right level also can save quite a bit of time. I don't write user interfaces that often and when I do they are mostly not that fancy. In that case I have sometimes written tests that check that the HTML output is correct. In the case of things that are purely visible I quite often first fix the thing and then write a test because the browser in my head is not always quite good enough to write a correct test beforehand. I have generally found that management was encouraging towards writing test in places where I have worked. Occasionally I have been praised for writing high quality software but also sometimes got the remark that sometimes things were taking a longer than expected. Everybody should be able to understand that there is a trade-off here. I would not want to work in a place where they produce as much crap as possible in as little time as possible. Lack of quality is quite hard on me emotionally.