5 ms·

I started programming a long time ago (more than 35 years) and if I could go back then I would've told myself that my code will live far far longer than I thoug

I started programming a long time ago (more than 35 years) and if I could go back then I would've told myself that my code will live far far longer than I thought and was told then. This still applies. Most juniors I meet think their code will be tossed out in months or maybe years. It doesn't; it stays for decades. I still make the same mistake now when I write stuff; I was trying to fix some bugs in a system I wrote in 2 days and then hacked on for 2-3 weeks over time. It is a real (objective) mess as it was a hurry-hackjob and was supposed to be replaced within 3 months (I was doing someone a favor; that's how bad things start :); I realised looking in git that it is from february 2012... And used by millions/month since then.

user5994461 6y ago
If it were 35 years ago, this was probably some logistics or finance systems? These were the first things adopting computers. Nowadays I'd say it's 50/50 whether a new project there will last a while. More than half the work is pet projects that won't ever be used for real, if at all. While the other small half can live for many years. It's possible to get a pretty good idea of where it's heading from the start, with experience.
- wott 6y ago
  > If it were 35 years ago, this was probably some logistics or finance systems? 35 years ago was also the time when 8-bit personal computers were becoming popular (well, not as 'popular' as 10 years later, of course) in homes, and hobbyists and kids could start dabbling in programming.
  - rjsw 6y ago
    The start of 8-bit personal computers was around 45 years ago.
    - wott 6y ago
      I thought I had insisted enough on popular.
      - rjsw 6y ago
        I would have said that 35 years ago was the end of the 8-bit era. I had an Atari ST with a 20MB hard disk in 1985.
- tluyben2 6y ago
  For me it was educational software for my first successful projects ; beginning on 8-bit micros but soon for MS-DOS, win3.1 and then win95 and onward. The 'business logic' code (written in Pascal by me) lived for decades inside the 40-something software packages being sold to most schools in my country.
- KineticLensman 6y ago
  > If it were 35 years ago, this was probably some logistics or finance systems? These were the first things adopting computers Early adopters of computers were doing so in the '60s and '70s. By 1985 mainframes were widespread and PCs were becoming common. Check out [0] 1981: MS-DOS 1983: C++, ARPANET 1984: Common Lisp 1985: Excel 1987: Photoshop [0] https://en.wikipedia.org/wiki/History_of_software https://en.wikipedia.org/wiki/History_of_software
protonimitate 6y ago
"Temp code" is the biggest lie anyone will ever tell you as a programmer. Everyone will have perfectly good intentions, from PMs to directors to ICs, but "this is only temporary" almost never is.
- dgb23 6y ago
  I agree in some sense. But I have found that every code base needs some kind of way to write "temporary" code AKA code that needs to be refactored at least. If you don't define a place (and time) for this then it will happen anyway. Just all over your code base: patches, fixes, workarounds, todos. The clearer it is to distinguish temporary code the better: "Start just writing what works here and then gradually move pieces of it over there, while testing and refactoring it." When your code and communication is setup like this, then you will naturally incorporate this process because it is both pragmatic and very visible to everyone.
- lmkg 6y ago
  It's not specific to programming, though. For example, even after completing new buildings, I've never seen a school reduce the number of "temporary" portable classrooms they use to teach classes.
- WrtCdEvrydy 6y ago
  Right up there with "We'll come back and fix it", "We'll refactor it later" and "We can add the tests later" It won't happen, and it has never happened unless those sections end up failing catastrophically. We don't have enough money to do it right once, but we have enough money to it wrong twice - Me, 3 years ago.
  - WalterBright 6y ago
    I'm still regularly refactoring code I initially wrote 35 years ago. https://github.com/dlang/dmd/pull/11301 https://github.com/dlang/dmd/pull/11301
    - tluyben2 6y ago
drdeadringer 6y ago
There's a book or two by Vernor Vinge where a character is a hobbyist "software archaeologist"; the character traces back one of the most basic programs -- I think it was the time//clock program -- and [re?]discovers the Unix Epoch of 1-Jan-1970. Because space-faring humanity in the far future runs on some flavor of Unix. The character concludes that that specific date was chosen because that was when humanity first walked on the moon. The point being to reiterate yours -- there's a decent chance the code you write will survive in some form far longer than initially told or intended.
- jodrellblank 6y ago
  Pretty sure it’s the A Fire Upon the Deep / A Deepness in the Sky series by Vinge https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep
- kabdib 6y ago
  It's from _A Deepness in the Sky_. The actual epoch chosen was the time of the first moon landing, a little prior to 1-Jan-1970 (I like this touch, something with actual historical significance and likely documentable to a fraction of a second, rather than an arbitrary date).
Polskanite 6y ago
It depends on a variety of factors. Availability* Is the code easily accessible to a wider audience? Legacy system cycle* Was the code written in a system that is expected to have a long cycle? (20 years+) Attribution* Can it be easily attributed to the owner? Access* Do you have access to enough source codes to confirm it to be true? Quality* Does the code have an appropriate level of quality? Company* Did the company survive the peaks and through of capitalism even if it means being bought out?
- tluyben2 6y ago
  > It depends on a variety of factors. What depends?
drbojingle 6y ago
the issue is that if you tried to write it to last 10 years it would be a different code base and wouldn't necessarily have gotten used like the one you actually did write. The real take away here is that real (objective) mess hurry-hackjob code bases are good enough to last many years so you probably did the right thing.
abhgh 6y ago
My learning too, "stop-gap" code isn't always short-lived.
wonderwonder 6y ago
Many of the baselines I have worked on are littered with comments that begin with 'Todo: ...'. Developers facing a deadline or trying to close a ticket add the todo as a reminder and years later have not gotten back to it.
el_benhameen 6y ago
We just moved our main repo from a local mercurial server to Github. The Github UI does a better job of exposing the time since last commit, and man, it's fascinating realizing that some of the deepest core components were last touched 8, 10, 12 years ago. It really does live longer than you expect.

user5994461 6y ago

If it were 35 years ago, this was probably some logistics or finance systems? These were the first things adopting computers. Nowadays I'd say it's 50/50 whether a new project there will last a while. More than half the work is pet projects that won't ever be used for real, if at all. While the other small half can live for many years. It's possible to get a pretty good idea of where it's heading from the start, with experience.

wott 6y ago
> If it were 35 years ago, this was probably some logistics or finance systems? 35 years ago was also the time when 8-bit personal computers were becoming popular (well, not as 'popular' as 10 years later, of course) in homes, and hobbyists and kids could start dabbling in programming.
- rjsw 6y ago
  The start of 8-bit personal computers was around 45 years ago.
  - wott 6y ago
    I thought I had insisted enough on popular.
    - rjsw 6y ago
      I would have said that 35 years ago was the end of the 8-bit era. I had an Atari ST with a 20MB hard disk in 1985.
tluyben2 6y ago
For me it was educational software for my first successful projects ; beginning on 8-bit micros but soon for MS-DOS, win3.1 and then win95 and onward. The 'business logic' code (written in Pascal by me) lived for decades inside the 40-something software packages being sold to most schools in my country.
KineticLensman 6y ago
> If it were 35 years ago, this was probably some logistics or finance systems? These were the first things adopting computers Early adopters of computers were doing so in the '60s and '70s. By 1985 mainframes were widespread and PCs were becoming common. Check out [0] 1981: MS-DOS 1983: C++, ARPANET 1984: Common Lisp 1985: Excel 1987: Photoshop [0] https://en.wikipedia.org/wiki/History_of_software https://en.wikipedia.org/wiki/History_of_software

protonimitate 6y ago

"Temp code" is the biggest lie anyone will ever tell you as a programmer. Everyone will have perfectly good intentions, from PMs to directors to ICs, but "this is only temporary" almost never is.

dgb23 6y ago
I agree in some sense. But I have found that every code base needs some kind of way to write "temporary" code AKA code that needs to be refactored at least. If you don't define a place (and time) for this then it will happen anyway. Just all over your code base: patches, fixes, workarounds, todos. The clearer it is to distinguish temporary code the better: "Start just writing what works here and then gradually move pieces of it over there, while testing and refactoring it." When your code and communication is setup like this, then you will naturally incorporate this process because it is both pragmatic and very visible to everyone.
lmkg 6y ago
It's not specific to programming, though. For example, even after completing new buildings, I've never seen a school reduce the number of "temporary" portable classrooms they use to teach classes.
WrtCdEvrydy 6y ago
Right up there with "We'll come back and fix it", "We'll refactor it later" and "We can add the tests later" It won't happen, and it has never happened unless those sections end up failing catastrophically. We don't have enough money to do it right once, but we have enough money to it wrong twice - Me, 3 years ago.
- WalterBright 6y ago
  I'm still regularly refactoring code I initially wrote 35 years ago. https://github.com/dlang/dmd/pull/11301 https://github.com/dlang/dmd/pull/11301
  - tluyben2 6y ago

drdeadringer 6y ago

There's a book or two by Vernor Vinge where a character is a hobbyist "software archaeologist"; the character traces back one of the most basic programs -- I think it was the time//clock program -- and [re?]discovers the Unix Epoch of 1-Jan-1970. Because space-faring humanity in the far future runs on some flavor of Unix. The character concludes that that specific date was chosen because that was when humanity first walked on the moon. The point being to reiterate yours -- there's a decent chance the code you write will survive in some form far longer than initially told or intended.

jodrellblank 6y ago
Pretty sure it’s the A Fire Upon the Deep / A Deepness in the Sky series by Vinge https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep
kabdib 6y ago
It's from _A Deepness in the Sky_. The actual epoch chosen was the time of the first moon landing, a little prior to 1-Jan-1970 (I like this touch, something with actual historical significance and likely documentable to a fraction of a second, rather than an arbitrary date).

Polskanite 6y ago

It depends on a variety of factors. Availability* Is the code easily accessible to a wider audience? Legacy system cycle* Was the code written in a system that is expected to have a long cycle? (20 years+) Attribution* Can it be easily attributed to the owner? Access* Do you have access to enough source codes to confirm it to be true? Quality* Does the code have an appropriate level of quality? Company* Did the company survive the peaks and through of capitalism even if it means being bought out?

tluyben2 6y ago
> It depends on a variety of factors. What depends?

drbojingle 6y ago

the issue is that if you tried to write it to last 10 years it would be a different code base and wouldn't necessarily have gotten used like the one you actually did write. The real take away here is that real (objective) mess hurry-hackjob code bases are good enough to last many years so you probably did the right thing.

abhgh 6y ago

My learning too, "stop-gap" code isn't always short-lived.

wonderwonder 6y ago

Many of the baselines I have worked on are littered with comments that begin with 'Todo: ...'. Developers facing a deadline or trying to close a ticket add the todo as a reminder and years later have not gotten back to it.

el_benhameen 6y ago

We just moved our main repo from a local mercurial server to Github. The Github UI does a better job of exposing the time since last commit, and man, it's fascinating realizing that some of the deepest core components were last touched 8, 10, 12 years ago. It really does live longer than you expect.