8 ms·

All Software is Legacy

120 points by leejo 11y ago

t3hprogrammer 11y ago
I share a similar sentiment with a different phrase: "code is a living history of past ideas, good and bad."
- pluma 11y ago
  Code is a liability. The best code is code that doesn't need to be written.
  - ktRolster 11y ago
    If it doesn't need to be rewritten, if it is that good, then it is an asset because you can depend on it.
    - ciroduran 11y ago
      Problem is... that code is an asset, until it's not. As most cases, it depends on the project, but changes in requirements have insidious effects on code, which might turn your asset in a liability before you realise it.
  - amelius 11y ago
    Ideas are more important than code.
- akkartik 11y ago
  One of my favorite quotes: "the future is a disagreement with the past about what is important." (http://carlos.bueno.org/2010/10/predicting-the-future.html http://carlos.bueno.org/2010/10/predicting-the-future.html)
doxcf434 11y ago
I recently had to maintain some new perl code. I didn't think it would be a big deal, but found a number of things I take for granted today that perl hasn't kept up with: 1) The perl cpan module doesn't resolve dependencies 2) The cpan module has parsing errors when passing in a list of CPAN packages 3) You have to manually grep your perl code to see what modules it depends on 4) Module installs take a long time since they can compile and unit test the code, unit tests can even make connections to the internet or try to access databases and fail, so you just have for force them to install 5) Non-interactive installs of CPAN modules requires digging in the docs and learning you need to set an env var to enable 6) CPAN modules aren't used that heavily and can have bugs that would be caught in wider used modules. (e.g. the AWS EC2::* modules don't page results from AWS so results sets can be incomplete, whereas the wider used boto lib works correctly and is better maintained.) 7) Perl devs don't think twice about shelling out to an external binary (that may or may not be installed) 8) Even if regexs are not needed, inevitably the perl dev will use them since that's the perl hammer, and it's hard to know what the intention is with regexes or what the source data even looks like 9) You have to manually include the DataDumper package to debug data structs 10) You have to manually enable warnings and strict check, it's not on by default. Anyhow, I think we've made a lot of progress since the 1990s. :)
- zzzcpan 11y ago
  > Perl devs don't think twice about shelling out to an external binary No, most of them do. Perl ecosystem has a killer feature called cpantesters, that allows everyone to see which modules work on which systems out of the box. You should always check cpantesters matrix before choosing a particular dependency. > Even if regexs are not needed They got overly complicated over the years, but they are needed. They are DSLs to make things easier when working with strings. I.e. so you wouldn't have to write 20 lines of hard to grasp code with bytes.Index(), bytes.HasSuffix(), bytes.TrimRight(), etc., like people do in Go, but a single nice regexp and therefore reduce your chances to make a mistake in that code.
  - paulryanrogers 11y ago
    Less code is generally better. But I've noticed a lot of folks still using ^ or $ when what they really mean is \A or \z
egraether 11y ago
In my opinion the biggest problem with legacy code is understanding its implementation as someone who hasn't worked on it before. In a lot of cases it's not documented well and the original authors have already left, so there's no one to ask. You are left with reading code written by someone else, which takes a lot of time. This is not Perl related, but I'm currently working on a developer tool that makes this part of the job easier. It's a source explorer for C/C++ named Coati that simplifies navigation within source code and thereby makes understanding the implementation faster and easier. https://www.coati.io/ https://www.coati.io/
- akkartik 11y ago
  Your first paragraph totally resonated. I've been thinking about this problem for several years. However, my approach is diametrically opposed to yours. I think our problems in software all stem from focussing on the code as the tangible artifact to maintain control over. We should instead be focusing on the space of possible inputs that the code is intended to work for. This is something you can't deduce from the code (and automatically using the computer to deduce it, well forget about it), it requires cooperation with the original author to present things in a way that makes the state space more explicit. This is why I love projects with lots of tests. I can't be bothered to analyze static code structure, either manually (what people call 'reading'[1]) or automatically. Just show me how the program is supposed to run in all the different situations that you've considered. Let me change it and rerun the tests to find out if I broke something. Modern programming practice emphasizes tests, which is great. However, not all kinds of tests can be written so far. So we end up doing manual certification work everytime we release or publish a new version of software, for performance, fault tolerance, etc. I want to make it all automatic. Some links about my project in case you'd like to learn more: http://akkartik.name/about; http://akkartik.name/about; http://github.com/akkartik/mu#readme http://github.com/akkartik/mu#readme. I'd love to hear your thoughts, either here or over email (address in profile). [1] http://akkartik.name/post/readable-bad http://akkartik.name/post/readable-bad
  - reledi 11y ago
    Tests significantly help with understanding a codebase and safely making modifications. Unit tests describe the behavior and usage of the individual systems, while integration tests describe business use cases in core workflows (usually just the happy paths). Integration tests should ideally be written in a gherkin style with feature description and acceptance criteria clearly outlined. Tests should be optimized for readability foremost. For example, most people try and make their tests DRY (which is an abuse of DRY because it should only apply to concepts, not code, but I digress) while they should instead be making them DAMP. Each test should be able tell a story without jumping up and down around the file and outside the file. It's a lot more dangerous to misunderstand a test than it is to have a little bit of code duplication in your tests. When I come across a project that has no documentation, I look at the tests. This isn't an excuse not to write proper documentation of course.
milesf 11y ago
A softer phrase that might work better is "All Software is Experimental". It has less pejorative connotations, and could be a shibboleth among seasoned developers.
- akkartik 11y ago
  Yeah, exactly. But what does it mean if even seasoned developers rely on interfaces in all this experimental software staying fixed for all time? The article falls for this disconnect as well, with its great enumeration of the problems contrasting with the repeated references to interfaces as a solution. Interfaces are part of the problem. (Or more precisely, our propensity to freeze interfaces, and our reluctance to rethink interfaces at will.) My favorite bit of the article is something I've been thinking about for years: ..paradoxically the cleaner and saner your interface the more likely it is to succeed and thus more likely to become constrained by its users, to solidify. I've been idly dreaming of a future where we decouple modules not by their interfaces but by their behavior. The major failure mode of our age is premature freezing of interfaces, and it happens because it's hard to judge how done the interface is from the outside. An interface that looks really clean can be exposed by a detailed look at the implementation that covers a corner case that hasn't been addressed yet. I'm trying instead to think about the input space of a function. I'd like in future to be able to make guarantees like this: > The behavior of this function is fixed when argument foo is less than 5. However, for larger values we're still nailing down some details. The argument foo might shift from being the first to the third, or its type may change in some subtle way (that still preserves previous guarantees). So upgrading will often cause some pain. However, the upside is that the pain is bounded. You never end up in some 1% situation where upgrading your OS borks up your Rails app and takes days to fix, or breaks things in subtle ways that you don't notice for months. You know that the upgrade effort will be bounded because you know that as long as you pass in the right value into the right slot, and as long as it's less than 5, behavior won't change and all your tests will pass. That seems like it might be superior to an interface, even if it adds a little extra work up-front. More details, in case you have any thoughts: http://akkartik.name/about http://akkartik.name/about http://akkartik.name/post/libraries2 http://akkartik.name/post/libraries2
  - 11y ago
vinceguidry 11y ago
I used to fantasize about having a code base I'd maintain for the next X0 years. Something like Dwarf Fortress, or hell, even TempleOS. Then I slap myself and come to my senses. Who knows how different coding will be 10 years from now? Do I really want to get married to something that's bound to be obsolete sooner rather than later?
- my5thaccount 11y ago
  If you aim to create great software that is flexible and powerful from the beginning, you'll be fine. Many businesses are still running very well on my 10 year old code and will be 10 or even 20 years from now I'm sure. Let this inspire you: http://www.bricklin.com/200yearsoftware.htm http://www.bricklin.com/200yearsoftware.htm
  - mkramlich 11y ago
    if this is who I think it is, Dan Bricklin, I want to chime in to say thank you for VisiCalc, sir! I was a user and big fan of your work. for the kids/newbs: effectively the (co)inventor of The Spreadsheet. and consider that spreadsheets were easily the killer app for the first PC's, thus giving them much more business value, in turn causing more money to flow in, helping to create many more paying jobs, etc, in a happy snowball effect which leads to Linux, Google, AWS... here's where you might say, "sorry, different Bricklin." oops
- spc476 11y ago
  I've been maintaining my blogging engine [1] for sixteen years now, and very little of the original code base (from 2000) exists. It's been an interesting experiment. [1] https://github.com/spc476/mod_blog https://github.com/spc476/mod_blog
- pjc50 11y ago
  I've joined a company with a multi-decade code base, one of whose original devs is still here. Much of it is untouched for a decade.
tariqali34 11y ago
Legacy software is successful software. What's the point of building a program that will be discarded after a few months because its users fled to the next big thing? That just means more lines of code being written overall, needlessly.
- bottled_poe 11y ago
  Legacy software is software that served a purpose but no longer meets the business objectives. Some common factors that influence the decision to replace a legacy system with a new one include: maintenance cost, scalability, flexibility. The usual approach in startups is to build something at minimal cost, then replace it later if the business requires it. Everyone has a different opinion regarding the importance of these factors at various stages of software life.
mooreds 11y ago
We should all be so lucky as to write legacy code because the alternative is worse: code that is never deployed, or deployed only for a short time. A project and website I worked on for about 10 years was recently shuttered, and I am extremely proud of what that code did for the business which paid me.
gaius 11y ago
Legacy means "in production, making us money".

120 points by leejo 11y ago

t3hprogrammer 11y ago

I share a similar sentiment with a different phrase: "code is a living history of past ideas, good and bad."

pluma 11y ago
Code is a liability. The best code is code that doesn't need to be written.
- ktRolster 11y ago
  If it doesn't need to be rewritten, if it is that good, then it is an asset because you can depend on it.
  - ciroduran 11y ago
    Problem is... that code is an asset, until it's not. As most cases, it depends on the project, but changes in requirements have insidious effects on code, which might turn your asset in a liability before you realise it.
- amelius 11y ago
  Ideas are more important than code.
akkartik 11y ago
One of my favorite quotes: "the future is a disagreement with the past about what is important." (http://carlos.bueno.org/2010/10/predicting-the-future.html http://carlos.bueno.org/2010/10/predicting-the-future.html)

doxcf434 11y ago

I recently had to maintain some new perl code. I didn't think it would be a big deal, but found a number of things I take for granted today that perl hasn't kept up with: 1) The perl cpan module doesn't resolve dependencies 2) The cpan module has parsing errors when passing in a list of CPAN packages 3) You have to manually grep your perl code to see what modules it depends on 4) Module installs take a long time since they can compile and unit test the code, unit tests can even make connections to the internet or try to access databases and fail, so you just have for force them to install 5) Non-interactive installs of CPAN modules requires digging in the docs and learning you need to set an env var to enable 6) CPAN modules aren't used that heavily and can have bugs that would be caught in wider used modules. (e.g. the AWS EC2::* modules don't page results from AWS so results sets can be incomplete, whereas the wider used boto lib works correctly and is better maintained.) 7) Perl devs don't think twice about shelling out to an external binary (that may or may not be installed) 8) Even if regexs are not needed, inevitably the perl dev will use them since that's the perl hammer, and it's hard to know what the intention is with regexes or what the source data even looks like 9) You have to manually include the DataDumper package to debug data structs 10) You have to manually enable warnings and strict check, it's not on by default. Anyhow, I think we've made a lot of progress since the 1990s. :)

zzzcpan 11y ago
> Perl devs don't think twice about shelling out to an external binary No, most of them do. Perl ecosystem has a killer feature called cpantesters, that allows everyone to see which modules work on which systems out of the box. You should always check cpantesters matrix before choosing a particular dependency. > Even if regexs are not needed They got overly complicated over the years, but they are needed. They are DSLs to make things easier when working with strings. I.e. so you wouldn't have to write 20 lines of hard to grasp code with bytes.Index(), bytes.HasSuffix(), bytes.TrimRight(), etc., like people do in Go, but a single nice regexp and therefore reduce your chances to make a mistake in that code.
- paulryanrogers 11y ago
  Less code is generally better. But I've noticed a lot of folks still using ^ or $ when what they really mean is \A or \z

egraether 11y ago

In my opinion the biggest problem with legacy code is understanding its implementation as someone who hasn't worked on it before. In a lot of cases it's not documented well and the original authors have already left, so there's no one to ask. You are left with reading code written by someone else, which takes a lot of time. This is not Perl related, but I'm currently working on a developer tool that makes this part of the job easier. It's a source explorer for C/C++ named Coati that simplifies navigation within source code and thereby makes understanding the implementation faster and easier. https://www.coati.io/ https://www.coati.io/

akkartik 11y ago
Your first paragraph totally resonated. I've been thinking about this problem for several years. However, my approach is diametrically opposed to yours. I think our problems in software all stem from focussing on the code as the tangible artifact to maintain control over. We should instead be focusing on the space of possible inputs that the code is intended to work for. This is something you can't deduce from the code (and automatically using the computer to deduce it, well forget about it), it requires cooperation with the original author to present things in a way that makes the state space more explicit. This is why I love projects with lots of tests. I can't be bothered to analyze static code structure, either manually (what people call 'reading'[1]) or automatically. Just show me how the program is supposed to run in all the different situations that you've considered. Let me change it and rerun the tests to find out if I broke something. Modern programming practice emphasizes tests, which is great. However, not all kinds of tests can be written so far. So we end up doing manual certification work everytime we release or publish a new version of software, for performance, fault tolerance, etc. I want to make it all automatic. Some links about my project in case you'd like to learn more: http://akkartik.name/about; http://akkartik.name/about; http://github.com/akkartik/mu#readme http://github.com/akkartik/mu#readme. I'd love to hear your thoughts, either here or over email (address in profile). [1] http://akkartik.name/post/readable-bad http://akkartik.name/post/readable-bad
- reledi 11y ago
  Tests significantly help with understanding a codebase and safely making modifications. Unit tests describe the behavior and usage of the individual systems, while integration tests describe business use cases in core workflows (usually just the happy paths). Integration tests should ideally be written in a gherkin style with feature description and acceptance criteria clearly outlined. Tests should be optimized for readability foremost. For example, most people try and make their tests DRY (which is an abuse of DRY because it should only apply to concepts, not code, but I digress) while they should instead be making them DAMP. Each test should be able tell a story without jumping up and down around the file and outside the file. It's a lot more dangerous to misunderstand a test than it is to have a little bit of code duplication in your tests. When I come across a project that has no documentation, I look at the tests. This isn't an excuse not to write proper documentation of course.

milesf 11y ago

A softer phrase that might work better is "All Software is Experimental". It has less pejorative connotations, and could be a shibboleth among seasoned developers.

akkartik 11y ago
Yeah, exactly. But what does it mean if even seasoned developers rely on interfaces in all this experimental software staying fixed for all time? The article falls for this disconnect as well, with its great enumeration of the problems contrasting with the repeated references to interfaces as a solution. Interfaces are part of the problem. (Or more precisely, our propensity to freeze interfaces, and our reluctance to rethink interfaces at will.) My favorite bit of the article is something I've been thinking about for years: ..paradoxically the cleaner and saner your interface the more likely it is to succeed and thus more likely to become constrained by its users, to solidify. I've been idly dreaming of a future where we decouple modules not by their interfaces but by their behavior. The major failure mode of our age is premature freezing of interfaces, and it happens because it's hard to judge how done the interface is from the outside. An interface that looks really clean can be exposed by a detailed look at the implementation that covers a corner case that hasn't been addressed yet. I'm trying instead to think about the input space of a function. I'd like in future to be able to make guarantees like this: > The behavior of this function is fixed when argument foo is less than 5. However, for larger values we're still nailing down some details. The argument foo might shift from being the first to the third, or its type may change in some subtle way (that still preserves previous guarantees). So upgrading will often cause some pain. However, the upside is that the pain is bounded. You never end up in some 1% situation where upgrading your OS borks up your Rails app and takes days to fix, or breaks things in subtle ways that you don't notice for months. You know that the upgrade effort will be bounded because you know that as long as you pass in the right value into the right slot, and as long as it's less than 5, behavior won't change and all your tests will pass. That seems like it might be superior to an interface, even if it adds a little extra work up-front. More details, in case you have any thoughts: http://akkartik.name/about http://akkartik.name/about http://akkartik.name/post/libraries2 http://akkartik.name/post/libraries2
- 11y ago

vinceguidry 11y ago

I used to fantasize about having a code base I'd maintain for the next X0 years. Something like Dwarf Fortress, or hell, even TempleOS. Then I slap myself and come to my senses. Who knows how different coding will be 10 years from now? Do I really want to get married to something that's bound to be obsolete sooner rather than later?

my5thaccount 11y ago
If you aim to create great software that is flexible and powerful from the beginning, you'll be fine. Many businesses are still running very well on my 10 year old code and will be 10 or even 20 years from now I'm sure. Let this inspire you: http://www.bricklin.com/200yearsoftware.htm http://www.bricklin.com/200yearsoftware.htm
- mkramlich 11y ago
  if this is who I think it is, Dan Bricklin, I want to chime in to say thank you for VisiCalc, sir! I was a user and big fan of your work. for the kids/newbs: effectively the (co)inventor of The Spreadsheet. and consider that spreadsheets were easily the killer app for the first PC's, thus giving them much more business value, in turn causing more money to flow in, helping to create many more paying jobs, etc, in a happy snowball effect which leads to Linux, Google, AWS... here's where you might say, "sorry, different Bricklin." oops
spc476 11y ago
I've been maintaining my blogging engine [1] for sixteen years now, and very little of the original code base (from 2000) exists. It's been an interesting experiment. [1] https://github.com/spc476/mod_blog https://github.com/spc476/mod_blog
pjc50 11y ago
I've joined a company with a multi-decade code base, one of whose original devs is still here. Much of it is untouched for a decade.

tariqali34 11y ago

Legacy software is successful software. What's the point of building a program that will be discarded after a few months because its users fled to the next big thing? That just means more lines of code being written overall, needlessly.

bottled_poe 11y ago
Legacy software is software that served a purpose but no longer meets the business objectives. Some common factors that influence the decision to replace a legacy system with a new one include: maintenance cost, scalability, flexibility. The usual approach in startups is to build something at minimal cost, then replace it later if the business requires it. Everyone has a different opinion regarding the importance of these factors at various stages of software life.

mooreds 11y ago

We should all be so lucky as to write legacy code because the alternative is worse: code that is never deployed, or deployed only for a short time. A project and website I worked on for about 10 years was recently shuttered, and I am extremely proud of what that code did for the business which paid me.

gaius 11y ago

Legacy means "in production, making us money".