3 ms·

Mostly it's inspiring because most people sit back and say "It can't be done, it's impossible" or "wow, they must have had a shit ton of luck to get this out of

Mostly it's inspiring because most people sit back and say "It can't be done, it's impossible" or "wow, they must have had a shit ton of luck to get this out of the door" instead of looking for solutions or ways to circumvent or exploit the million little problems along the way that seek to obstruct the endgame. Kudos to these guys for sticking at it long enough and persevering to achieve their vision.

understand17 11y ago
bla bla
nerdy 11y ago
My inspiration from massive science projects is more like: "With that in mind, debugging this 1500-line function is nothing!"
- balabaster 11y ago
  Dude... refactor that shit. There is no place in today's development world that a 1500 line function is okay :P
  - Practicality 11y ago
    Indeed. It will save you from needing inspiration to debug it as well. It's much less cognitive load when you break those crazy things into understandable parts.
    - joelberman 11y ago
      The potential speedup on those old F2C routines is amazing. The ability to use much more memory, understand cache levels, etc. have a huge impact.
  - TeMPOraL 11y ago
    When was the last time you've seen pure Assembly? Also, JavaScript namespacing shenanigans & stuff... :P.
    - nerdy 11y ago
      I make 3rd party/unsanctioned mods for video games in my free time, which involves plenty of Assembly :)
  - fsloth 11y ago
    Not all functions are refactorable. A 'purely hypothetical' scenario: a numeric routine of several klocs on length, that takes in 20 parameters with 1-3 letter obscure variable names, was written 30 years ago in fortran, was f2c:d 20 years ago into c and has been doing it's 'stuff' correctly ever since somewhere in the bottom of mission critical code in a codebase of millions of lines. Commercial codebase. Only a handful of developers. Management expect new features and expedient, safe bugfixes that do not change end user functionality.
    - TeMPOraL 11y ago
      That's actually simple. All you need is to npm yeoman to generate a proper skeleton for grunt and gulp to work using Mockito.js, C2F.js and Fortran.js, then you can auto-generate unit tests that will be paralelly distributed over AWS. More seriously though, the kind of code you described will be what I imagine the first subject of study of the software archeology field in the future. http://akkartik.name/post/deepness http://akkartik.name/post/deepness
    - annnnd 11y ago
      The scenario you describe is a disaster waiting to happen. Refactor it, preferably yesterday - but make a "shadow deploy". For each set of input / output parameters run both functions and compare them. If they differ, use the old one and go back to figuring out where it went wrong. After some time you can be quite sure that the new clean function works as it should - then you just switch.
      - HerpDerpLerp 11y ago
        I am not sure the above idea is mentioned by Michael Feathers in his amaze book "Working Effectively with Legacy Code" but it is a great idea, and combined with the things that Michael does cover will do you a lot of good! http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-F...
  - nerdy 11y ago
    It's a legacy system developed by someone who is lucky he lives 4300 miles away! I've been working at the system to free it from that subsystem with an eventual replacement. There are all kinds of single-letter variables and Russian words, refactoring wouldn't be economical or sane.
TeMPOraL 11y ago
I guess different people see different things in such projects. What I see: - *massive* success of coordination and cooperation - illustration of potential humanity has - that careful and methodical approach can make even such monsters of recursive complexity work Luck does not enter the picture. Will and determination do though.
- balabaster 11y ago
  You'd be surprised how often will and determination is more of a factor of success than luck. [Your level of surprise may vary]

understand17 11y ago

bla bla

nerdy 11y ago

My inspiration from massive science projects is more like: "With that in mind, debugging this 1500-line function is nothing!"

balabaster 11y ago
Dude... refactor that shit. There is no place in today's development world that a 1500 line function is okay :P
- Practicality 11y ago
  Indeed. It will save you from needing inspiration to debug it as well. It's much less cognitive load when you break those crazy things into understandable parts.
  - joelberman 11y ago
    The potential speedup on those old F2C routines is amazing. The ability to use much more memory, understand cache levels, etc. have a huge impact.
- TeMPOraL 11y ago
  When was the last time you've seen pure Assembly? Also, JavaScript namespacing shenanigans & stuff... :P.
  - nerdy 11y ago
    I make 3rd party/unsanctioned mods for video games in my free time, which involves plenty of Assembly :)
- fsloth 11y ago
  Not all functions are refactorable. A 'purely hypothetical' scenario: a numeric routine of several klocs on length, that takes in 20 parameters with 1-3 letter obscure variable names, was written 30 years ago in fortran, was f2c:d 20 years ago into c and has been doing it's 'stuff' correctly ever since somewhere in the bottom of mission critical code in a codebase of millions of lines. Commercial codebase. Only a handful of developers. Management expect new features and expedient, safe bugfixes that do not change end user functionality.
  - TeMPOraL 11y ago
    That's actually simple. All you need is to npm yeoman to generate a proper skeleton for grunt and gulp to work using Mockito.js, C2F.js and Fortran.js, then you can auto-generate unit tests that will be paralelly distributed over AWS. More seriously though, the kind of code you described will be what I imagine the first subject of study of the software archeology field in the future. http://akkartik.name/post/deepness http://akkartik.name/post/deepness
  - annnnd 11y ago
    The scenario you describe is a disaster waiting to happen. Refactor it, preferably yesterday - but make a "shadow deploy". For each set of input / output parameters run both functions and compare them. If they differ, use the old one and go back to figuring out where it went wrong. After some time you can be quite sure that the new clean function works as it should - then you just switch.
    - HerpDerpLerp 11y ago
      I am not sure the above idea is mentioned by Michael Feathers in his amaze book "Working Effectively with Legacy Code" but it is a great idea, and combined with the things that Michael does cover will do you a lot of good! http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-F...
- nerdy 11y ago
  It's a legacy system developed by someone who is lucky he lives 4300 miles away! I've been working at the system to free it from that subsystem with an eventual replacement. There are all kinds of single-letter variables and Russian words, refactoring wouldn't be economical or sane.

TeMPOraL 11y ago

I guess different people see different things in such projects. What I see: - *massive* success of coordination and cooperation - illustration of potential humanity has - that careful and methodical approach can make even such monsters of recursive complexity work Luck does not enter the picture. Will and determination do though.

balabaster 11y ago
You'd be surprised how often will and determination is more of a factor of success than luck. [Your level of surprise may vary]