16 ms·

Somewhat related question you might be able to answer - what are good examples of really resilient code bases a junior developer can look at to learn? Old code

Somewhat related question you might be able to answer - what are good examples of really resilient code bases a junior developer can look at to learn? Old code still in production just sounds antifragile to me and that's the sort of code I'd like to write

xiphias2 6y ago
It's just the opposite. Old code is so fragile because you don't know what's important in it. An example is Bitcoin's concensus critical code: anything that goes in there probably has to be maintained forever (or for the life of Bitcoin)
- segfaultbuserr 6y ago
  > Old code is so fragile because you don't know what's important in it. An example is Bitcoin's concensus critical code I don't think Bitcoin is a perfect example here, the Bitcoin consensus rule is fragile because it's Bitcoin, not because it's old. The unchangeable consensus code is a result due to the fundamental property of Bitcoin itself (every client must run in lockstep, even the slightest deviance cannot be tolerated, which means there should be one and only one Bitcoin client whose behavior shall remain consistent for as long as Bitcoin exists), this outcome is independent from its code quality, age, and other factors. ...Nevertheless, on second thought, the Bitcoin analogy isn't too far from the truth. If an aged legacy system is the dependency of many other systems and serves a critical role, it effectively becomes Bitcoin-like.
  - xiphias2 6y ago
    Of course, regulations help old code to remain as well, which is probably the case in finance. Just think about Boeing's case where the company is trying to fit new code into the memory of a 8086 chip.
    - segfaultbuserr 6y ago
      I thought it was the 80286, not the original 8086. Don't underestimate the computing power of an aircraft too much...
      - xiphias2 6y ago
        Probably you are right, I was lazy to check it :)
libraryofbabel 6y ago
I’m not the best person to answer this - others should chime in too. I think sadly you won’t be able to read the preeminent examples of really old antifragile code that’s still powering the world. That stuff is mostly proprietary - banks and governments and so on. Hence this article. BUT - there are still plenty of mature open source codebases to read, especially operating systems, databases, and Unix utilities. Sure, they’re living projects that now look quite different from the original, but they’re descended from code a few decades old and written in the same language — C. There’s Emacs (35 yrs old), GCC (33 yrs), the Linux kernel (29 yrs), MySQL (25 yrs), and Postgres (a youngster, only 24). And then there’s the programming languages. C itself is now 48 years old! Since it’s the language of the Linux Kernel and Postgres and so much else, I’d be willing to bet it’ll be around for another 48 years. (Yes, I love Rust, and I’d use it over C for any new project, but this is the Linux Kernel folks!) But - since this is Hacker News - I should note that C is beaten by a long long way by Lisp, which is 62 years old. That’s older than COBOL - and people still love it. John McCarthy really had programming figured out.
- abhinav22 6y ago
  Lisp is amazing. John McCarthy played an amazing role, but there were others too - eg Alonzo Church and the guys that later made Lisp what it is (Common Lisp), with a significant extra set of features including lexical scope. For those who want to learn it - check out this short guide. Highly recommended language!: https://github.com/ashok-khanna/common-lisp-by-example https://github.com/ashok-khanna/common-lisp-by-example
  - goatinaboat 6y ago
    Lisp is amazing. John McCarthy played an amazing role But in terms of real world production code it is barely a footnote whereas COBOL fills entire libraries. So while it might be great there just isn’t a lot of examples to look at
    - onei 6y ago
      Lisp as a language might be a footnote, but the ideas the language proposed were revolutionary. Recursion, REPL and even conditionals all came from Lisp (FORTRAN had a conditional entity at the time, but not what we'd recognise as a conditional today and I believe they later adopted Lisp-style conditionals anyway). IIRC, Lisp could be expressed in 5 small base functions defined in assembly, from which the entire language could be defined in turn, making it outrageously portable. It's hard to understate how seminal Lisp was.
deepspace 6y ago
The sqlite codebase is often mentioned as an example of well-written, well-tested antifragile code.
- mlvljr 6y ago
  Tests appear to only be available to paying customers though.
orange8 6y ago
"Antifragile" doesn't feel like a very robust word to me.
- sgt 6y ago
  Google it. It's a commonly used word that needs definition.
- hestefisk 6y ago
  Good pun.
jl6 6y ago
I’m mid-30s, working for a finance megacorp and we have a few production codebases older than me. Some observations: * Sadly, as others have said, these are proprietary internal systems and members of the public won’t ever be able to see them. * Although the codebases have ancient lineage, the code doesn’t stay static and has been extended and patched over the years, and sometimes transplanted wholesale to a different technology using automated tools (e.g. mainframe to .NET, although that particular one was an unmitigated disaster for maintainability). * Ancient code usually persists in production for reasons unrelated to its technical qualities, and usually in spite of them. For example, an insurance company managing a closed book of pensions has very few compelling reasons to change its technology because the product it supports doesn’t change, and regulatory changes can be handled by tweaks and auxiliary reporting systems. * Having said that, ancient code was usually written with a great deal more discipline than modern code, and I believe this stems from the division of labor between Programmer and Analyst, which no longer exists. By having two people involved in every part of the system, you had all the benefits of rubber ducking, peer-review, documentation, and the simple act of talking to another human about what you are doing. * Ancient systems tend to be very rigorously tested for functionality that directly supports business activity. Ancillary functionality such as management information reports, less so. These systems change infrequently enough that the major defects have all been flushed out and fixed, over the years. There is very little feature churn, which does wonders for stability. * The code at the heart of these systems usually wasn’t designed with a modern threat model in terms of security. Security is often bolted-on by isolating these systems behind other systems, and they get a lot of mileage out of obscurity too. * The code is often the least interesting thing about ancient systems anyway. Few are performing rocket science tasks - they are usually just doing batch data processing and green screens. More interesting is the ecosystem of infrastructure, interfaces, job schedules, copybooks and data models, resilience features, and documentation. These are the things that make the system really work. Lines of COBOL are usually unilluminating.
- est31 6y ago
  Regarding your point about ancient systems having higher quality, maybe there has been a selection effect? The systems that were crap might have been rewritten years ago before you even came to the company.
jacobwilliamroy 6y ago
Old codebases are really more about exploiting the sunk cost fallacy, nepotism and cultivating a fear and uncertainty of new technology. That is to say, old codebases are mostly about organizational politics and social dynamics, rather than anything inherently stable or high-quality about the codebase itself. So basically, if you want your codebase to still be in production 50 years from now, here's what you do: build something important and mission critical. It should be something that could cost millions if it ever fails. Make the design so bespoke and specialized that only you and people trained by you actually know how it works and how to fix it. Fraternize with the management and use nepotism to grease the wheels and convince them to overlook the inefficiencies inherent in your project. This works well in government projects where you can offer kickbacks in the form of campaign donations. Once you are providing a necessity, and there is a real financial risk associated with your system failing, you're set for life. Expect your contract to be renewed next year, and every year after that, forever and ever and ever and ever.
Litost 6y ago
I'm not the best person to answer this either, but whenever anyone says old code is fragile and we should just throw it all out and start over, I always point at this, possibly famous post, by Joel Spolsky: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Couple of key comments for me "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed." "It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version." A similar analogy might be Chesterton's Fence, it's important to know why it's in the state it's in before you decide to alter it?: https://fs.blog/2020/03/chestertons-fence/ https://fs.blog/2020/03/chestertons-fence/
necheffa 6y ago
It is not at all remotely "antifragile". It's extremely brittle and after so many years you just know the happy path through the code. Any deviation results in spectacular failure and bug reports get closed as "wontfix". I can't show you examples because copyrighting, licensing, and I'd lose my job.
- bregma 6y ago
  It has been my experience that modern new software is just like this, only it's more ubiquitous.

xiphias2 6y ago

It's just the opposite. Old code is so fragile because you don't know what's important in it. An example is Bitcoin's concensus critical code: anything that goes in there probably has to be maintained forever (or for the life of Bitcoin)

segfaultbuserr 6y ago
> Old code is so fragile because you don't know what's important in it. An example is Bitcoin's concensus critical code I don't think Bitcoin is a perfect example here, the Bitcoin consensus rule is fragile because it's Bitcoin, not because it's old. The unchangeable consensus code is a result due to the fundamental property of Bitcoin itself (every client must run in lockstep, even the slightest deviance cannot be tolerated, which means there should be one and only one Bitcoin client whose behavior shall remain consistent for as long as Bitcoin exists), this outcome is independent from its code quality, age, and other factors. ...Nevertheless, on second thought, the Bitcoin analogy isn't too far from the truth. If an aged legacy system is the dependency of many other systems and serves a critical role, it effectively becomes Bitcoin-like.
- xiphias2 6y ago
  Of course, regulations help old code to remain as well, which is probably the case in finance. Just think about Boeing's case where the company is trying to fit new code into the memory of a 8086 chip.
  - segfaultbuserr 6y ago
    I thought it was the 80286, not the original 8086. Don't underestimate the computing power of an aircraft too much...
    - xiphias2 6y ago
      Probably you are right, I was lazy to check it :)

libraryofbabel 6y ago

I’m not the best person to answer this - others should chime in too. I think sadly you won’t be able to read the preeminent examples of really old antifragile code that’s still powering the world. That stuff is mostly proprietary - banks and governments and so on. Hence this article. BUT - there are still plenty of mature open source codebases to read, especially operating systems, databases, and Unix utilities. Sure, they’re living projects that now look quite different from the original, but they’re descended from code a few decades old and written in the same language — C. There’s Emacs (35 yrs old), GCC (33 yrs), the Linux kernel (29 yrs), MySQL (25 yrs), and Postgres (a youngster, only 24). And then there’s the programming languages. C itself is now 48 years old! Since it’s the language of the Linux Kernel and Postgres and so much else, I’d be willing to bet it’ll be around for another 48 years. (Yes, I love Rust, and I’d use it over C for any new project, but this is the Linux Kernel folks!) But - since this is Hacker News - I should note that C is beaten by a long long way by Lisp, which is 62 years old. That’s older than COBOL - and people still love it. John McCarthy really had programming figured out.

abhinav22 6y ago
Lisp is amazing. John McCarthy played an amazing role, but there were others too - eg Alonzo Church and the guys that later made Lisp what it is (Common Lisp), with a significant extra set of features including lexical scope. For those who want to learn it - check out this short guide. Highly recommended language!: https://github.com/ashok-khanna/common-lisp-by-example https://github.com/ashok-khanna/common-lisp-by-example
- goatinaboat 6y ago
  Lisp is amazing. John McCarthy played an amazing role But in terms of real world production code it is barely a footnote whereas COBOL fills entire libraries. So while it might be great there just isn’t a lot of examples to look at
  - onei 6y ago
    Lisp as a language might be a footnote, but the ideas the language proposed were revolutionary. Recursion, REPL and even conditionals all came from Lisp (FORTRAN had a conditional entity at the time, but not what we'd recognise as a conditional today and I believe they later adopted Lisp-style conditionals anyway). IIRC, Lisp could be expressed in 5 small base functions defined in assembly, from which the entire language could be defined in turn, making it outrageously portable. It's hard to understate how seminal Lisp was.

deepspace 6y ago

The sqlite codebase is often mentioned as an example of well-written, well-tested antifragile code.

mlvljr 6y ago
Tests appear to only be available to paying customers though.

orange8 6y ago

"Antifragile" doesn't feel like a very robust word to me.

sgt 6y ago
Google it. It's a commonly used word that needs definition.
hestefisk 6y ago
Good pun.

jl6 6y ago

I’m mid-30s, working for a finance megacorp and we have a few production codebases older than me. Some observations: * Sadly, as others have said, these are proprietary internal systems and members of the public won’t ever be able to see them. * Although the codebases have ancient lineage, the code doesn’t stay static and has been extended and patched over the years, and sometimes transplanted wholesale to a different technology using automated tools (e.g. mainframe to .NET, although that particular one was an unmitigated disaster for maintainability). * Ancient code usually persists in production for reasons unrelated to its technical qualities, and usually in spite of them. For example, an insurance company managing a closed book of pensions has very few compelling reasons to change its technology because the product it supports doesn’t change, and regulatory changes can be handled by tweaks and auxiliary reporting systems. * Having said that, ancient code was usually written with a great deal more discipline than modern code, and I believe this stems from the division of labor between Programmer and Analyst, which no longer exists. By having two people involved in every part of the system, you had all the benefits of rubber ducking, peer-review, documentation, and the simple act of talking to another human about what you are doing. * Ancient systems tend to be very rigorously tested for functionality that directly supports business activity. Ancillary functionality such as management information reports, less so. These systems change infrequently enough that the major defects have all been flushed out and fixed, over the years. There is very little feature churn, which does wonders for stability. * The code at the heart of these systems usually wasn’t designed with a modern threat model in terms of security. Security is often bolted-on by isolating these systems behind other systems, and they get a lot of mileage out of obscurity too. * The code is often the least interesting thing about ancient systems anyway. Few are performing rocket science tasks - they are usually just doing batch data processing and green screens. More interesting is the ecosystem of infrastructure, interfaces, job schedules, copybooks and data models, resilience features, and documentation. These are the things that make the system really work. Lines of COBOL are usually unilluminating.

est31 6y ago
Regarding your point about ancient systems having higher quality, maybe there has been a selection effect? The systems that were crap might have been rewritten years ago before you even came to the company.

jacobwilliamroy 6y ago

Old codebases are really more about exploiting the sunk cost fallacy, nepotism and cultivating a fear and uncertainty of new technology. That is to say, old codebases are mostly about organizational politics and social dynamics, rather than anything inherently stable or high-quality about the codebase itself. So basically, if you want your codebase to still be in production 50 years from now, here's what you do: build something important and mission critical. It should be something that could cost millions if it ever fails. Make the design so bespoke and specialized that only you and people trained by you actually know how it works and how to fix it. Fraternize with the management and use nepotism to grease the wheels and convince them to overlook the inefficiencies inherent in your project. This works well in government projects where you can offer kickbacks in the form of campaign donations. Once you are providing a necessity, and there is a real financial risk associated with your system failing, you're set for life. Expect your contract to be renewed next year, and every year after that, forever and ever and ever and ever.

Litost 6y ago

I'm not the best person to answer this either, but whenever anyone says old code is fragile and we should just throw it all out and start over, I always point at this, possibly famous post, by Joel Spolsky: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Couple of key comments for me "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed." "It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version." A similar analogy might be Chesterton's Fence, it's important to know why it's in the state it's in before you decide to alter it?: https://fs.blog/2020/03/chestertons-fence/ https://fs.blog/2020/03/chestertons-fence/

necheffa 6y ago

It is not at all remotely "antifragile". It's extremely brittle and after so many years you just know the happy path through the code. Any deviation results in spectacular failure and bug reports get closed as "wontfix". I can't show you examples because copyrighting, licensing, and I'd lose my job.

bregma 6y ago
It has been my experience that modern new software is just like this, only it's more ubiquitous.