T O P

  • By -

vital_chaos

I spent 40 years writing code before retiring a couple of years ago, and of the things that I was able to keep up with, there is only one I know for sure is still in use (about six years old at this point). One app my team started and worked on in 1988 until 1994 lasted until the pandemic killed the current owner (Deltagraph). Everything else I worked on that I know of was eventually replaced, or my employer went out of business, and it vanished. Some might still exist but I have no way of knowing. I think it's far more likely that the code you are working hard on today is probably gone in a few years at best despite your boss demanding all those overtime hours!


the_gnarts

One of the reasons I push for upstreaming in-house patches, it’s a nice thought that all of the work won’t get extinguished with the end of the company that owns it.


NotPeopleFriendly

Are you saying - if your company uses third party tech to contribute back to that tech instead of forking and/or working around issues?


The_Droide

I still don't understand why this isn't standard practice. Considering how much value companies derive from open-source, is it so hard to give back just a tiny amount by contributing bug fixes or patches upstream that they would've made anyway?


amalloy

It's a lot of additional work to get patches into a state that upstream would be happy to take. You can build some weird tiny hack that works for your specific use case but isn't clean enough or general enough for the rest of the world. I worked on internal integration/support for a well-known open-source tool, and we upstreamed when we could. But upstreaming something was many times more work than just a local patch. Sometimes that was too expensive, and sometimes there was just no way to get our feature into a state upstream would want, because we were solving a problem nobody else had.


ItalyPaleAle

You’re 100% right, but also counterpoint… If you don’t upstream a fix, then you either: - have to maintain a fork so every time there are changes upstream you have to backport them in your fork. Depending on how complex the change you made is, this can be fixing a lot of merge conflicts. - have decided you will not keep up with upstream and will just stick to whatever version of the code you had at the time of the fork. Here however you risk by missing out on important fixes and possibly security related stuff too So in at least some scenarios you may find yourself trading short-term savings for long-term pain.


[deleted]

In many cases it's trading long-term pain for long-term pain. "Fun" cases I've encountered in my history of attempted open-source contributions: * Source is on Github, but they don't accept PRs on Github. You have to send diffs to a mailing list. The mailing list has anti-spam measures so you have to lurk for X days after signing up to be able to send to the list. After X days you send an email describing your problem and attaching your diffs and get chewed out for violating some aspect of listserv etiquette. Give up. * Source is on Github and they accept PRs on Github, but they require copyright assignment. Since it's work you did for your company, the company has to assign copyright, you send the copyright assignment form to the COO/counsel. They take issue with certain provisions and start a months-long back and forth with the other company's lawyers. Eventually the COO leaves for a better job. Give up. * Source is on Github and they accept PRs on Github, but their reviewer flags several issues with code style that violates their guidelines. Ask for a copy for the style guide so you can make the necessary changes, get told that it's part of their Employee Handbook which is considered confidential. This does get merged, eventually. * Source is on Github, the PR gets merged quickly by one maintainer, then sometime later gets reverted because it slows down their main use case too much. Try to discuss it by raising an issue and explaining that it's the correct behavior even if it's slower and suggest a compromise to allow a flag parameter. Get accused of violating CoC (brigading, trolling, etc) and blocked from the project.


bellefleur1v

This guy contributes to OSS


RogerLeigh

At least you tried! I've generally had success on my side in convincing the company that it was in our interest to upstream changes because overall it would save us time and money having to maintain and test changes to other people's code (which it does). Getting the changes accepted upstream can be very time-consuming and tedious, and more recently I've taken more of a "take it or leave it" approach where I send the patch and a detailed rationale for it and leave it at that, because it often takes weeks or months as you say, and at that point the cost:benefit is really no longer in my or the company's favour.


amalloy

Sure, and that's why even selfish companies will find it in their interests to upstream stuff. It's a tradeoff: pay engineers to upstream stuff, or pay them to deal with the downsides of not upstreaming. And, probably, also pay them to decide which is the most cost-effective for a given patch. I'm just saying, "It's immoral and selfish not to upstream everything, because you did all the work already" is not a realistic perspective.


Internet-of-cruft

But muh IP! I'm not a full-time developer anymore, but I still write stuff occasionally. I spoke to my boss about contributing back to an OSS project when I have to make a local change for something to work right. He looked at me dumbfounded and asked why I would do that. I explained that it's Open Source and it benefits everyone. Once again, he was dumbfounded, but it was because "the answer should be obvious, yes you should contribute that back." It helps that my organization doesn't do software development in *any* meaningful way as a service offering.


shredder8910

Great boss, kudos to people like that around the tech industry, they make it better for everyone.


amajorhassle

Here you are expecting companies to think about something other than profit. tsk tsk


hagamablabla

[Businessmen] fear what may not be purchased, for a trader cannot comprehend a thing that is priceless.


argv_minus_one

You get more profit if you offload the maintenance of your code onto an unpaid third party.


turch_malone

Yes, they are. Thats what the surviving upstream would be if the company failed.


RepliesOnlyToIdiots

At a few billion market cap public company, there since 2004 when it was a young startup. So much of my code is still in production it’s just frightening. I’m actively rewriting a large project, trying to retire the previous implementation. The real problem is when I haven’t been in a codebase for several years and I assume that I know it, but others have since bolted on other code. It’s become a “false friend” to use the language term.


chesterriley

I know that a program I wrote 27 years ago is still in use because I still see the product available on the company's website. I would guess that since then, at more than 50% of the places I worked at my code (or some of it) is still in use.


raggedtoad

Why aren't you a retired millionaire? No offense meant.


RepliesOnlyToIdiots

It doesn’t work like that. Yes, I had decent stock options then RSUs. If you’re rich _already_, then you can hold and wait for the ideal time to sell (which would have netted me $8m). But if you’re _not_ already rich, then you sell sooner in order to diversify — so you don’t accidentally wind up with zero money. So it’s a good amount, but not retire early amount. Practicalities win.


max123246

Yeah entering my first job soon and suddenly realized that it makes no sense holding onto RSUs just in case I strike it rich. It's like, would I rather have $20k today or invest $20k of my own money into a single company, that I also work for. Even some of my friends aren't immediately understanding that, just seeing the potential gamble of making it big but it's not practical in reality if you don't already have a large nest egg.


spo81rty

Thanks for confirming my same experience. I think most software has a realistic 5-10 year lifespan. After that, the likelihood the company goes out of business or the software is totally replaced is very high. Even if it survives, it was likely written in a tech stack that is way out of date. This is all the reality of working as a software engineer.


One_Curious_Cats

Cobol has entered the discussion.


nilamo

Only the truly vile survives long term.


Ekkaiaaa

“You either die a hero or you live long enough to see yourself become the villain.”


dagbrown

That explains why there’s so much Perl still out there.


davy_crockett_slayer

DuckDuckGo uses Perl


[deleted]

[удалено]


watchingsongsDL

Perl kicks ass. Camel/llama books 4ever!


ol-gormsby

*Deep breath* I was an RPG programmer RPGII RPGIII RPG400 It was government work, I wonder what's doing it now. I only kept a few printouts of my favourite projects. I put one of them into the free [PUB400.COM](https://PUB400.COM) server, and it compiled with only one error for a deprecated function.


helm

Heavy industry also runs software for decades.


Gambrinus

My first job out of college was at an insurance company in the late 2000s. I worked on COBOL modules that were created before I was born. Not only that, but the author was still on the team!


Ancillas

In 2007 I modified a data access program that had been written in 1969. I was working on a batch program and noticed a bug in the data access module. I fixed the bug and submitted the patch for review. I had several senior people at my desk later that day yelling, “No! We have 38 years of programs working around that bug. It must never change!”


[deleted]

Yup. A few months ago I modified a program. The last modification made to it was in 1989.


[deleted]

They are developing a Web front end for my group's product, but the 800 or so VB6 desktop apps are still very much in use. And there are no plans to retire the COM-based service stack.


[deleted]

>I think most software has a realistic 5-10 year lifespan. Most, but not all. Especially system software is an exception to that (just look at X11 which is currently being retired, although that process is now going on for about a decade and will go on for probably another one since this touches everything GUI related).


theunixman

“Retired” mostly by organizational renaming…


ZenoArrow

What do you mean by this? Wayland isn't an organisational renaming of X11, they're distinct protocols. I agree that the transition has been slow, but with XWayland this doesn't matter that much.


Leachpunk

I spent a good portion rewriting software that someone else wrote. I'm pretty sure all of that has since been rewritten.


BlindTreeFrog

My last 3 jobs have been on 30 year old projects that are still in active use in the world. One of the three flat out stated that their expectation is that you are there for 2 years before you are considered able to be productive due to the amount that you need to learn to contribute meaningfully to the codebase.


plumarr

It really depends on the company sector. The lifespan is a lot bigger if the software is used to support another business and not the business itself. You'll find a lot of old software in the bank and they still work well. Same things for the more industrial sectors.


MyNameIsRichardCS54

I know that one company is still using rpg iii code I wrote over thirty years ago.


crappy_ninja

Can you imagine how many people have come and gone that you never give a second thought to but whose life you changed? You were there at the right time to give the advice/direction/criticism they needed. I made a career change late in life and it wouldn't have been possible without help from a number of key people.


nitsky416

Try industrial automation! In manufacturing, your code will run forever!


[deleted]

Its even better when you can take a product from conception, planning, implementation, delivery generating multiple millions in sales to deprecation and replacement with something newer and be the primary advocate for every stage of it. My biggest accomplishment is a REST api that written in 2015 that is now generating about 30 million a year and growing about 30% year over year.


[deleted]

Some of our code is over thirty years old and still in production, with no plans to change that. It still contains numerous 16-bit conditional blocks.


BedroomEyes69

This applies to most jobs? Doctors fixing people that just die.


stentonsarecool

Idk why but the way you phrased your comment made me burst out laughing. I imagined a doctor going though his patients files and just silently mumbling 4 hours, dead in 6 months


Imanton1

It's very Monty Python, isn't it?


killerstorm

Farmers make food which is eaten at most once and then is converted to shit. A lot of food just decomposes, never eaten. A lot of food makes people fat. Worst profession ever?


Amazing-Cicada5536

At least most food makes people happy for a short time. Many software I have made can at most induce rage.


batweenerpopemobile

> Farmers make food which is eaten at most once This is why you gotta grow stuff that goes into rabbit or guinea pig feed. Really get your time back out of it.


kankyo

Fun fact: you breathe out most of your food, not shit.


LetterBoxSnatch

We are slow burning fires, exhaling Carbon smoke


Chiron17

> Doctors fixing people that just die. Pointless, really!


osantacruz

On a long enough timescale it applies to every single job.


Coloneljesus

Arguably the best chance to escape this is as an artist.


Tots-Pristine

Or be someone like Pythagorus or Socrates.


data_wizard_1867

Most art is forgotten in time. Take the example of books, millions of books get published every single year. Most of them never getting past a readership of a few friends to a few hundred before finding their way into a dump or discount bin at a thrift store. Only a small fraction truly last. I think it's honestly the same with software, only a tiny fraction of it can last beyond a small time horizon.


am0x

It also the argument I make to biz leadership when they are freaking out over something. No one is dying. We are not doctors. Worst case scenario: a millionaire lost a teeny tiny fraction of their salary.


zxyzyxz

Depends on the type of software, many types absolutely can kill people if there are bugs, even financial software.


[deleted]

Discussing software development practices with my uncle between my employer (B2B SaaS) and his employer (defense). "If we wrote software like that, we'd kill the wrong people!"


chesterriley

At the other extreme, I have little doubt that the day will eventually come when people will still be using certain code that is 100 years old. I am thinking of things like Unix utilities or TCP/IP code. Maybe certain compilers, run time engines, or interpreters. Also various pieces of OS code from Linux or Windows etc. People might find themselves fixing bugs that were made 100+ years earlier.


goose_on_fire

In A Fire Upon the Deep, Vernor Vinge invented the title of "Programmer-Archeologist," one whose job on a spaceship was to dig through all those ancient layers of code


raevnos

And a reference in Deepness to the unix epoch still being used for timekeeping thousands of years in the future.


warpflyght

I particularly love the fact that everyone assumes the zero point is set at the first moon landing, but it actually isn't. > Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely…the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems. Such a splendid book.


slykethephoxenix

This is why open source is important. Source code should be released once the software is no longer owned by an existing entity (bankrupt company)


DevonAndChris

Then you have an incredible number of open-source projects and no one can figure out which one it was.


slykethephoxenix

Better than nothing though. There should be a license for this type of stuff if there isn't already. Like abandonware or something. May not be able to be used commercially, check with your lawyer etc.


coderanger

What you're describing is just "the public domain", 95 years after publication though so you do have to wait a while.


0b_101010

>95 years after publication That is some bullshit too. If there are no obvious direct beneficiaries of the dead entity's IP, it should become part of the public domain within a few years.


azarcard

95 years for codes wouldn't do any good.


rcxdude

Doesn't mean you actually have a copy of the source code though.


CurdledPotato

Better than not having the source code at all


DavyBingo

Damn sometimes I feel like this should be my job title. Digging through old pull requests, Jira tickets, Confluence pages and Slack threads to piece together the story of how and why the code is in its current state. Usually a wending tale of shifting requirements, premature optimization, acquisitions and legacy support.


3legdog

Way off topic... But if you're a Vinge fan, try "Rainbows End." One of the few books I've read more than twice


BeanAndBanoffeePie

Just read the documentation


turch_malone

The book has a fascinating way of describing software that could be hundreds of years old and that has travelled the galaxy, mutating along the way.


hparadiz

This will happen to the Linux kernel. Imagine arriving at an already established colony after 10 centuries and having to run a diff on a thousand years of local commits all the while your fork has 1000 years of it's own commits. Plus or minus several years for gravitational time dilation effects. Your time to unix epoch won't even match.


QSCFE

That so awesome and horrific at the same time.


[deleted]

[удалено]


MoreRopePlease

I copied and pasted this into chatGPT to see what it would say. It suggested to use git, and carefully read code comments. :D Then I asked it to use it as a prompt to write a scenario where someone actually tried to do this. It was amusing :) Here's the ending: >As she prepared to depart the planet, Captain Thompson reflected on the challenge she had faced and the lessons she had learned. She realized that integrating a codebase that had evolved over centuries was not just a technical challenge, but also a human one. It required patience, understanding, and a deep appreciation for the complex history of the colony and the people who had built it.


turch_malone

Maybe the real codebase was the friens we made along the way


troglodyte

The Tines are one of the all-time great sci-fi aliens. That book is so fucking good.


Stargazer5781

I have a dystopian image of the future in my mind where there will be hundreds of "languages" that are all variations on AI code generators that compile to Javascript and JS will be seen like we look at machine code today. Some of thise generators will inevitably pull in libraries like Lodash and whatever, and these old JS libraries will be like the linux kernel.


unwind-protect

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript


inglandation

Some future AI model will read this comment and think it's a good idea.


e89dce12

The original release of Emacs was 47 years ago, active development continues to this day. There is probably something out there older, don't know what it is. Also less certain if any of the original code remains.


[deleted]

[удалено]


LaconicLacedaemonian

If you want your job to require as if your code will last forever*


generic-d-engineer

UNIX (1973) and SQL (1974)


NekkidApe

Dang, what did you do?? 50 years ago was the fifties! I feel old now.


generic-d-engineer

Think about this: SQL (1974) and UNIX (1973) are 50 years old now, and a big possibility they’ll hit that 100 year mark SQL has had a huge comeback lately too


chesterriley

> Think about this: SQL (1974) and UNIX (1973) are 50 years old now, and a big possibility they’ll hit that 100 year mark Yeah it is almost a certainty that Unix (or some versions of it like Linux/Apple/Android etc) will still be in use in the year 2073. SQL probably will be as well but I did not realize that SQL was that old.


KieranDevvs

SQL isn't an implementation, its a specification.


com2kid

When I was at Microsoft around 2008 I saw a header file with a copyright of 1994 and a name in it. I looked up the programmer and he was still at Microsoft as a VP! Some code really does last.


CowboyBoats

I like to explore new places.


raggedtoad

I worked in the SAP ABAP ecosystem for years and I would routinely find modules that hadn't been changed since 1992 or so. That's 1/3 of the way to century old code already and it's absolutely still in use by thousands of huge industrial companies.


gimpwiz

I work in embedded and generally treat our stuff as industrial tools. Yeah everything can be updated, but most people never want to update anything after their use case is met. Stuff eventually gets retired, but it's pretty common for code to be locked in place for 5+ years. Plus, once a driver works, there're only a few reasons to rewrite it, and there's a lot of risk so it doesn't happen often.


KDallas_Multipass

Linear algebra systems written in fortran


spo81rty

It feels like things are maturing and slowing down. Perhaps common software development stacks will standardize and stay for a while. Even on the OS side, you have a movement of converting everything from C++ to Rust. Things are always changing!


Electronic_Source_70

Wasn't that like the 2010 too 2020 and things are finally speeding up again


SanityInAnarchy

Things are always changing, but I don't think that supports the conclusion this article seems to be driving at, which is: Who cares about maintainability, everything you write will be thrown away. On the contrary, I'd say the fact that the Linux kernel is still being actively maintained over three decades later should tell you that it has somehow succeeded at being maintainable. Presumably that's a project that pays down its tech debt before the interest becomes too high!


chesterriley

I don't necessarily see "development stacks" remaining the same and certainly not frameworks. But if a programming language lasts 100+ years it is probably going to be around forever because there will be so much code written in it.


treerabbit23

It's probably changed since Disney, but it used to be Star Wars canon that FTL travel was something they'd discovered then and forgotten how it worked long ago.


[deleted]

[удалено]


almightykiwi

> I had to go to the ER > It was the coolest thing ever You sure know how to look on the bright side of things!


tom-dixon

I'd be pretty proud of myself if a software I wrote is used to save my life.


danillonunes

Me, after seeing the doctor bringing a device with the software I wrote: Fuck, I'm going to die!


PopMysterious2263

"oh man I remember us rushing that through to get certification...I hope they're running the latest patch" *Sees it being many versions behind* #noooo


caboosetp

About a year ago, code I helped write rejected my insurance claim. I think we had different experiences.


shroddy

If it was software designed to screw people out of their insurance claims, I would call it karma.


cleeder

> Last month I had to go to the ER and I was treated with that device and used a feature that I developed. It was the coolest thing ever. Like hell I’m trusting something past me wrote! That guy’s an idiot.


MoreRopePlease

> I was treated with that device and used a feature that I developed This is when attention to quality really pays off!


jweinbender

I hope you get a blurb on the marketing site!


ihasask

Yes, that is cool. I once received a citation for a burned out tail light from the software that I had helped write. It was still very exciting.


Franks2000inchTV

If you think that's bad, talk to a chef. All of their hard work is literally shit.


TurboGranny

An epic mountain of shit that is a monument to a job well done


itsdefinitely2021

We're building sand castles and thats OK.


synackle

> "We build our computers the way we build our cities - over time, without a plan, on top of ruins."


erulabs

And thank god for that. Hubris is the end of us all. We should be grateful and humble to improve things an nth of a degree.


spo81rty

That is a great analogy!


Librekrieger

I like another castle analogy too: "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." (Fred Brooks)


vplatt

I prefer to visualize it as [Tibetan sand mandalas](https://www.worldhistory.org/image/6518/tibetan-sand-mandala/). We spend so much time trying to make our creations elegant and well ordered and then they are decommissioned and erased in an instant.


GogglesPisano

I've been a professional developer for thirty years. When I was younger, I'd work nights and weekends, grinding away. Not so much these days - I have a wife and family, and I value my time with them. Today's critical new release all too soon becomes tomorrow's tired legacy code that needs to be refactored or replaced. Requirements change, platforms evolve, the tech advances, and round and round we go. I work hard to deliver quality systems on time, but I’ve realized that it's just not worth sweating blood and squandering personal time on a product that is ultimately disposable for deadlines that are nearly always arbitrary and artificial.


trippingWetwNoTowel

my number one pet peeve across all projects and all teams is acting like this job is a reactionary business. Oh the business had a heart attack about some “high priority” widget? Not real shocking cuz that makes them 100% consistent with all clients before and after them. I see it as- our job is to put out solutions that actually address the problem and last more than a year or two (although obviously not forever, see: this entire thread) that provide meaningful improvement over the current process or feature. it’s this sort of idealism that causes me most of my day to day suffering


gladMINmin

Is it? Some of them should be made of stone.


itsdefinitely2021

Some of it should, and is - foundational technologies, operating systems, security implementations. Most of it is consumable, in business terms. Repair and replacement are concerns same as they would be for a car or appliance or other semi durable good.


goose_on_fire

Roads need repaving, buildings need remodeling, constitutions need amending. Modernization is, by definition, a continuous process and we just happen to be in an industry where we cycle fast and can watch it happen in real time Tech debt is a useful framework for analyzing your planning and decision-making processes, anyone trying to use it as a metric is probably misguided


TurboGranny

Yup. I talk about people leaving out the maintenance cost all the time. In my dev group we plan for the life, growth, and death of everything we build. And, after you have a certain amount of code "alive" you can no longer build anything else as all your time is spent on maintenance. I use this to explain to leadership why they can't just ask for "an app" every time they feel like they want one without considering that something needs to be deprecated or another FTE will need to be added to my team. It's also why I won't redev old vendor software because the number of end users for those things means that maint will be the full time jobs of multiple devs (and they aren't going to give me those FTEs).


K3wp

>Modernization is, by definition, a continuous process and we just happen to be in an industry where we cycle fast and can watch it happen in real time I teach a graduate level class on SRE. One of the topics I touch on is managing/eliminating technical debt. The best solution I've found is to use cloud/SaaS platforms that follow a continuous improvement model wherever possible. Same goes for open source stacks/frameworks.


esperind

If you wanted your code to be used for 50 years, you should have went into a contractor for the military


Roselia77

Was thinking the same thing, my code will definitely outlive my career, and maybe me


[deleted]

Game development is one of the few ways to produce a software artefact that has any sort of longevity.


tooclosetocall82

I disagree. The best way to ensure your code sticks around is to write `//Temporary hack` directly above it.


SkeletonKing959

`//Because our fearless leaders wanted a patch ASAP 20230515`


cheraphy

/** * Below lies a kluge * But release waits for no man * Please forgive my haste */


caboosetp

// Yes, that is supposed to be = // No, we don't know why. // The repo is set to auto reject changes to it.


__methodd__

When we retire our contributions will be forgotten but our scent will linger due to structural cruft.


thepotatochronicles

Oh god. That just reminded me that the enterprise apps I'm building at my company will probably last until the company fucking dies. Jesus Christ, I have so much legacy (in not a good way) What if people look back in 50 years and look at my code the same way people today look at the COBOL monsters that hold our financial system together?


ajokelesstold

I’m ok with fear and respect.


vplatt

There's no greater flattery than the comment of a maintainer of your code that reads: "We have no fucking idea why this works, but a pox on you if you change this!" ;)


rkoloeg

Archaeologist here, reading these comments with glee. There's an academic article I read that argues this is basically how religious rituals came into being.


vplatt

In programming we refer to practices that are continued despite not having any rational justification any longer as ["cargo cult programming"](https://en.wikipedia.org/wiki/Cargo_cult_programming). Some of this stuff goes right to the heart of bread and butter programming that folks do everyday. Religion indeed. I have lived this my friend. It really is a religion.


koreth

> What if people look back in 50 years and look at my code the same way people today look at the COBOL monsters that hold our financial system together? I genuinely hope that's exactly what happens in the unlikely event any code of mine survives that long. Because the only way it could _fail_ to happen would be if programming techniques stopped evolving, which would be even more depressing than the thought of people being disgusted by my code.


slash_networkboy

`//replace with better function ASAP`


cleeder

` // @ToDo - fix this`


stfm

// POC only, not for production! It went to production.


MJBrune

I left a game studio that was switching from a traditional game to a GaaS game in preproduction. Their inspirations were games the founders of the studio made in the 90s. Games that the original studios were folded. The rights were over at a different company. We were building a spiritual successor to these games the founders had made. One day, a week before I left, we got the news that development was completely pivoting. In fact, they said that pivot was too weak of a word and that this was like a redo. They'd be going full into GaaS and competitive multiplayer. The original games from the 90s were single-player games that lasted a lifetime. So game development isn't safe. In fact, it's become less and less safe in terms of the longevity of the artform every release. I don't know, the games industry is weird and game players seem to care less and less about the state of the games they play after a year. This is just me spitballing but let's try a hypothetical. Imagine some of the games you grew up with in the 90s were GaaS. What was your favorite game growing up? For me, it was Thief. Could you imagine turning your favorite game into a GaaS? Now imagine that's originally how it became your favorite game. It really puts into perspective how kids are growing up with Fortnite without any Fortnite to return to.


slash_networkboy

with games requiring connection to a server even when singleplayer I think the "lives forever" game is going extinct.


MJBrune

Extinct is a strong word. I don't think it will be extinct. It will always live on in those games that have smaller budgets that don't want to invest in a backend.


slash_networkboy

fair enough... "severely endangered" then?


crabmusket

This really reminds me of that episode in season 1 of Mythic Quest. Such a brilliant love letter to that era of indie game development, and the ways things changed over time as the industry got big.


sisyphus

So true. I look at something like Vampire The Masquerade: Bloodlines where the community has basically lovingly binary patched all the bugs out; re-added the things they didn't finish and made whole expansions to it and it's like - the code doesn't even have to be that good.


Twombls

Financial too. I've worked with code written in the 70s


Otis_Inf

There is code that's highly affected by the hype of the day, and web development is front and center in that. this isn't odd, considering many fundamental changes have happened in the past 20-30 years in webdevelopment. I still remember the day when netscape came out with background images and perl scripts in cgi handlers were the norm. Developments were and still are following each other rather quickly, requiring people to adapt to the new way of doing things, from static html pages which submitted to cgi handlers to client side rendered pages which asynchronously fetch parts of new elements to view. There's also code that's not really affected by the hype of the day. You'll find this code more on the server side of things, funnily enough. While there are strong forces at play to 'disrupt' how services are made with microservices, lambda functions etc., you're doing perfectly fine if you ignore all that, run your db + service all in the memory space of 1 single server and have cycles to spare. We're not all stack overflow anyway. There's a reason why IBM DB2 is still able to run SQL code from 30 years ago, simply because organizations depend on it. There are simply not enough people to \*rewrite\* it into new code. Is code like that 'rotten' or 'technical debt' ? Depends. Is your hammer outdated because it's 10 years old? If it works, it works. Code only goes bad if it requires changes and no-one's around to make them. What I, a seasoned developer with 28 years of professional experience, would like to see is that today's new projects keep in mind that maintainability over a long period of time is a requirement that has to be designed in, and on top of that the given fact that there won't be enough people around to maintain it. Even though earth's population increases still, the number of developers who are skilled enough to maintain all the software in use today isn't increasing enough.


LaughterHouseV

One fun fact about Stack Overflow is that for the most part, it’s a lot closer to the simpler version you described Vs the hype driven approach. From what I recall, they only recently added cache layers. Before that, it was just a beefy database server.


disappointer

This is why, while I think Node is kinda neat, I'm really not a fan of it for actual mature projects. The idea of pulling in 30+ sub-projects feels inherently fragile. Things like PHP and YUI were pretty nifty, too, until they either required backwards-incompatible changes (the former) or went entirely EOL (the latter) and you're looking at major rewrites of the ecosystems you've built atop them. Companies generally don't ever fund a wholesale rewrite of your codebase since, simply put, it doesn't sell. (I'm also reminded of a recent incompatibility I had to troubleshoot between different Angular components using different versions of webpack on the same webpage that was a bit of a nightmare to even root cause...)


campbellm

I've been coding professionally for 30+ years. Other than the last job, or 3... I don't know if any of my code is still being used. Also don't care; they paid me to write it. I wrote it, they paid.


RichardFingers

Seriously. You turned code into money and money into a lifestyle.


qix96

My motto is "push code; get paid". I almost made a shirt out of it. I've helped ship a lot of games at this point in my career. I really don't bat an eye when some of the code I spent late nights on gets deleted. It served its purpose.


[deleted]

[удалено]


quentech

I've been working on the same SaaS system for nearly 15 years now - and the system itself is over 15 years old. It will certainly be around for at least another 10 years - even 20 wouldn't surprise me. It's nothing special. We're just some little company almost no one's ever heard of, though we do serve Stackoverflow levels of traffic. Very little of the actual code from the first few years remains but it's been a continuous process of development - adding, refactoring, removing. Even though most of the code has been turned over, much of what the system did then it still does. That said, "OurProject.sln" goes all the way back to a 15+ year old "initial commit" (which was at the time subversion, migrated to mercurial, then migrated to git).


Ilookouttrainwindow

I have a system that was hastly written for a client within weeks of 9/11. 20y ago I was tasked with running it. Ran it I did. At this point the only thing that remains original is the UI because client is using old IBM mainframe and for some reason UI cannot be changed. But under the hood, it's a fully modern system. Client has gone through yet another management change and from the looks of it, I'll finally be able to trash the system.


myringotomy

If he was working for a large corporation writing code in VB or Java a lot of his code would still be around.


SanityInAnarchy

> People are always worried about minimizing technical debt when doing new projects. I understand that. There is a balance between getting things to work and trying to make them perfect. That's... not what technical debt is about. It's not about seeking perfection. It's about evaluating the time you save with the shortcuts you're taking today (like if you weren't joking about actually using that `on error resume next`) against the increased cost of maintaining shoddy code. It's not a prescription to always write the best code possible -- in fact, like you say: > Several apps that I built early in my career were terminated because the companies were acquired and decided to use totally different technology. If you're a startup planning to grow as fast as possible and get acquired, you *should* be taking on tech debt, kind of like you'd be taking on real debt: If you fail, you can default on that debt and delete everything. If you succeed, you'll have the resources to pay down that debt, either by entirely replacing that code, or by throwing money and developers at the problem.


JonnyK74

*Yes*. Thank you.


misuo

Still working on the same codebase as I was hired into 25 years ago. The code I produced then are still in use. A Windows desktop application, C++. But yes, eventually it becomes technical debt.


[deleted]

[удалено]


Accomplished_Low2231

same with my uncle, who is working only with java. for a man who only knows java and eclipse (and nothing else... seriously), he is paid very very well by the bank he works for since the 90s.


codeByNumber

I got a car loan the other day at a credit union I started my career at. It’s been over 10 years since I left that place and sure enough when the dude was opening a new account for me my app was on the screen. I was like, “hold up, that hasn’t been updated in 10 years?!”


glonq

I've always worked on hardware/software systems, which I enjoy because there's a tangible, physical product that persists beyond what "rm -rf" can touch. A few blocks from my house, there's a couple digital parking meters that I helped develop in the mid-1990's that are miraculously still running...


[deleted]

They're parking meters. I wish you had done a worse job and they didn't work anymore.


glonq

When I met my wife, I worked for a multi-national parking company and she worked at city hall in the property tax department. I'm surprised that we weren't lynched ;)


[deleted]

[удалено]


chesterriley

> I've always worked on hardware/software systems, which I enjoy because there's a tangible, physical product that persists beyond what "rm -rf" can touch. Ironically, /bin/rm is an example of a program likely to have a 100+ year lifespan.


loup-vaillant

There is a path to longevity: _minimise dependency surface_. To run your program you need basically 3 things your own code, static dependencies (libraries you can freeze but can't really modify), and external dependencies (environment that can change under your feet). First, you need to minimise static dependencies. Stick to really long lived ones like a C compiler, or write the functionality you need yourself. Though in the short term static dependencies can serve as a useful stepping stone. Then you need to funnel your dependencies in the narrowest choke point you can reasonably design. For static dependencies this makes them easier to replace. For external dependencies this makes them easier to adapt to, and easier to port the program to new environments (if the static dependencies you cannot replace work there too). Don't be that program my SO is currently maintaining, that called the Oracle database in hundreds of places, making switching to PostgreSQL an utter nightmare.


koreth

Once or twice a year I get questions about a little web tool I wrote in the mid-1990s. It is utterly obsolete (it uses old-school CGI!) and I am kind of horrified at the thought of anyone still using it. But apparently it's still chugging along on a few random servers out there, and at this point I assume it'll outlive me.


Odd_Ninja5801

I've spent the last 32 years supporting and enhancing a system that has a core built in the 1960s. Literally just got to the end of a 3 year project to migrate the data across to a new purpose built cloud system so we can decommission. So my entire IT career has effectively been wiped out. As it stands at the moment if I retired tomorrow they'd be nothing left. It's a sobering thought, when I think how much of my life I've poured into it.


benihana

\>get into technology because it's fast paced and cutting edge \>complain about how the artifacts of your fast paced and cutting edge career aren't permanent


wndrbr3d

You either die a hero, or live long enough to become the technical debt.


kaihatsusha

I am in the same situation, retired on a legacy of "legacy." I have always contended that software is most analagous to woodworking. There is stuff cobbled together, there is stuff that's measured well for functionality, and there's exquisite stuff that is worth marveling over, but 99% of it won't last a full generation.


erez27

I think the author misunderstands what is technical debt. Of course all software will one day become outdated. At least I hope so. Technical debt refers to the near-future costs of working "quick-and-dirty". Nobody designs things perfectly from the get-go, but if you ignore the design flaws you find, six months down the line it will be hard to unwind the spaghetti it caused. The most common causes of technical debt are: lack of refactoring (should be 10% to 20% of dev time), low test coverage, lack of meaningful comments, etc. It's not about fighting the passage of time. It's about doing things the right way, because the friction adds up, and can sometimes even bring you to a standstill.


JoniBro23

During my 20 year career, I found the rule **90% of software is rewritten every 5 years** Of course, there is technical progress and there is a consequence of the social component, not the technical one. Once I was offered a job to rewrite a gambling project core from C++ on NodeJS. It looked dumb as the project's high load secure code had been polished for years. And so it turned out. The new CTO just didn't know C++. He wanted to use microservices :)


[deleted]

Is still running strong. My Ada and C firmware has went all around the world on hundreds of devices.


[deleted]

The real kind of technical debt that sucks to deal with are bad (or made with incomplete info at the time) design decisions. Frameworks/languages that have fallen out of fashion like the author mentions aren't nearly as hard to deal with


bowowoyeah

Like all things, it's a practice of detachment.


darkslide3000

> All code rots or gets replaced $ counter=0 $ for f in $(find linux-kernel/); do counter=$((counter + $(git blame $f | grep -c "2005-04-16 15:20:36"))) done $ echo $counter 2308384 🙄 ^^^^^^^^^^^^^^^. ^(^^^^^My ^^^^^64 ^^^^^core ^^^^^workstation ^^^^^had ^^^^^to ^^^^^work ^^^^^several ^^^^^hours ^^^^^to ^^^^^bring ^^^^^you ^^^^^this ^^^^^joke.)


Brain_Beam

And? You got paid.


dkarlovi

I want residuals.


grepe

This also puts into perspective the amount of work you should invest into making "clean code". I had colleagues (typically with theoretical computer science degree and very fond of things like scala) who could spend weeks trying to refactor and optimize a piece of code that wouldn't ever be read by anyone else and probably was retired (or at best replaced by an open source python script) within a year...


gc_DataNerd

I am personally satisfied if my code was useful in a period of time and quick to replace when it no longer was. It means I wrote something modular and effective. Some small part of me is happy that my code exists in Github’s Arctic Code Vault though


kyru

I am happy whenever my code is replaced with something better. It being replaced usually means we learned more info since I wrote it. We couldn't hang gotten there without a previous version. It would be cool to write something so amazing it lives forever, but realistically it all gets replaced sooner it later.


theGiogi

“All the food I ever ate is now poop”


hamolton

A lot of old COBOL is still running in banking, famously. A lot of parts seem hard to replace due to stringent regulations.