During my teenage years, I gifted a friend of mine a PC computer magazine from the UK, because I was a Mac enthusiast myself. The magazine came with a CD that contained a full version of Delphi. My friend took it upon himself to learn programming using this language and, to this day, continues to find employment because of it. He even regularly secures contracts with the company his father used to work for, maintaining Delphi projects, he started in his teenage years.. I feel compelled to apologize to anyone who might have been affected by this. At the time, I didn't understand what Delphi was, and honestly, I still don't. I apologize for any confusion or inconvenience this may have caused.
I almost feel bad for these companies that got screwed over by progress offshoots that never led anywhere. Almost, because they're companies so fuck 'em. They can afford the switch over.
My first job (~2011) involved converting some Fortran code to MATLAB & integrating it into a scientific data processing pipeline. The code was written to process atmospheric data gathered from rocket experiments in the 60s. Someone had already moved the code from punch cards to text files, so at least I didn't have to do that part. Eventually I had to convert it to handle the same kind of data but gathered from satellites (which mostly means doing some geometry to account for the different perspective). It was technical debt on two levels. And of course, when they hired me, the only language I knew was C++, so they plopped some Fortran and MATLAB textbooks on my desk and said "figure it out, good luck". That was how I learned the value of writing good documentation for your code... if only the people who wrote that rocket code half a century earlier had learned the same lesson.
All the atmospheric transmission models (Lowtran, Modtran, Hitran) still have the underlying 80 column card format data entry basis. Archaeology right there.
I don't touch garbage that's likely to disappear. Started with GNU/Linux and bash in 2001, still here. Started with PHP in 2006, still here. Started with HTML and CSS in 2006, still here. Started with go in 2020, still here. Started with JS in 2009, still here.
THIS. There are (mostly hobby) projects I can't afford to put much time into and using the new hot modern framework that will be dead in two years makes no sense. on the web frontend, HTML+CSS it is, sprinkled with a bit of Javascript. Also, you can do part of frontend input validation in HTML without even using Javascript.
Same, except I didn't really understand consciously what I was doing until recently. I subconsciously didn't feel inclined to putting much time or weight into certain things. I somehow developed a kind of instinct about what was good and what was likely to stick around and be useful. I liked bash (wish I'd learned it earlier) and it's still very common and useful. Didn't like Java (there are now many better languages to do things), enjoyed Windows 'batch' but always had a feeling it wasn't worth investing time in, and I realised why when I finally found bash. I didn't like Visual Basic (it's now dead), didn't like windows SQL (it's been eclipsed by mysql, postgresql etc.). Once I discovered Linux, Windows became dead to me as a solution. Didn't like SVN (and it's now mostly dead and everyone uses git). I like Go (wish I'd started using it earlier). I didn't like XML, preferred JSON (and XML is now largely not used).
I used to believe this but now I think the mainframe COBOL programmers secretly get together at the clubhouse and laugh at the rest of us trying to keep up on the tech hamster wheel. "Look at those kids run!"
It may be a cozy clubhouse, but on the other hand, the number of people in that clubhouse is much *much* smaller than there were COBOL programmers back when I started (1980).
I think core applications written in C++ have a pretty long lifetime as well - there are some languages that are good to a point where they don't get superseeded by the new shiny thing every year or 2. I honestly don't understand the whole javascript "front end / backend" nonsense, and how it's an ever changing shifting realm
Corporate America has twisted the term MVP into something unrecognizable. It has nothing to do with the MVP in the startup world, which is where the term comes from. If you’re working on something that takes 50 engineers and six months to deliver, in no world is that an “MVP”. Edit: Voice to speech typos
I hate how people have added numbers. "mvp1, then on mvp2 we'll..." Like, no. There is only one MVP. The M means 'minimum' everything else is an iteration.
Fun fact: the Brits at my job pronounce “deprecated” as “depreciated” and I’ve had multiple, agonizing conversations with them about how this is not a difference of accent
My colleague at work does this and I don't want to be the guy that points out he's been using a financial term all this time. And we have the same accent so he's saying the wrong word for sure.
For a very long time I thought “deprecated” was pronounced as “depreciated” until I heard someone from youtube pronounces it in other way and checked the dictionary
Now that I think about it academic books usually treat change in software engineering as change in requirements but none of them to my knowledge treat change in terms of change in design, change in architecture which would be valuable insight into technical debt. Like most of them will say if you want to deal with change go agile.
See, 90% of these technologies are Web based tools, libraries, and Frameworks. If you learn Java, C, C++, Rust and you don't really give a f*ck, then you don't have to deal with this shit.
I have read Reddit articles where c++ code written by the old team could not be read by the new team so they tried to rewrite it then said eff it and wrote it in Java.
@@ea_naseer sure, but that's just a shitty programmers making mess. It's still the same technology. This article was mostly focused on web-based stuff that changes every 5-7 years or so.
Yeah... no. Java 8 is *nothing* like java < 8. Nobody mutates in place anymore, even in the core APIs. How's that corba package doing? Have you tried the `Flow` api i.e. reactive programming? You can't write a meaningful app without 100+ annotations. Hell, we aren't even WORA/JIT these days! Java is *nothing* like it was 20 years ago.
Part of this guy's problem is that he's clearly been using Microsoft (and other proprietary) stacks which have basically all been wiped out over time. They never last longer than the org that generated them, and even where orgs last they change direction, abandon their old initiatives and they die... This is why open source runs everything now.
When you said that IE6 and Netscape dev on a resume still meant something to you, you melted my heart a bit. Thank you for handing me a walker, and bless your heart deary~ Most of the time people DGAF about us, but some folks still do I guess.
Interesting article. Management in the company I work for should read that.. i had the most horrible developer experience and i am glad i switched into architecture consulting within that company. It's amazing how much product owners cling to old stacks because they don't want to fund refactoring and you as developer have to build skyscrapers on a swamp without draining it first.
Ive found this the further I get in my career the less I care about the code and thats not a bad thing. I still care that its readable. I still care if its maintainable. But I don't care about it being perfect. Perfect really is the enemy of good and sometimes you just need to get some shit on the page and call it a day.
@ThePrimeTime, this may blow your mind ... I've been working in a tech space that has been 'grandfathered' by Microsoft and has not changed in 23 years. I'm talking about Axapta's language 'X++' which was leading ERP tech in 2000 (the days of ColdFusion) and it has not changed since (speaking of the core language). MS has updated the compiler to basically be a pre-parser to #CIL byte code but the language itself has not (and I expect never will) be updated as the customer base has all its tech and processes invested in it. This platform is the #1 selling of ERP platforms. (SAP is still the biggest but not in terms of new deployments)
Once (in 2018), I applied for a programming position at a company. After the interview, they assigned me a task that needed to be completed using FoxPro and mentioned that their entire system was built on it. I believe they are still struggling with that mess...
I think the problem is this agile way of working. I sometimes go 6 mi this without writing a line of code. I used to be an awesome C# developer, now I've forgotten most of it. We're just always jumping from one tho to the next. You can only hope on keeping your knowledge of the basics, loops, data structures, control flow. If you know those three things you'll get by.
I'm currently 19. I had IT classes in high school... The government said we had to learn programming with Delphi, so I suppose I'm already in technical debt
I worked for a railroad company 25 years ago. Mainframes and Cobol. I’m pretty sure some of my code is still alive. Luckily for me, it’s someone elses technical debt now 😂.
What was that like? How quickly did you consider your own code tech debt? At release? At merge? At push? At commit? At stage? First run? When first typed? Before it even left your brain?
@@codeman99-dev 80% of the job was writing simple batch programs. Pretty boring stuff. 'Technical debt' wasn't a thing, at least not in my country, so I didn't consider it at all.
I know a company that still uses the same ms-dos inventory system. It was created by the owner, and it's rock solid. Employees that are familiar with it can operate it faster than most UI's today can render and no user has ever found any bugs in it (at least in the last 20 years that I know of).
This is only one part of what technical debt is. Most often, technical debt is what you get when you take shortcuts to meet business deadlines. Technical debt is often when you are writing bad code in the current context, this is a tradeoff for speed to market, for laziness, for lack of manpower and yeah sometimes for lack of updates. Technical debt is also often just shit code you are stuck with.
There are tech stacks that last however. Large established tech stacks last for decades using programming languages that have been around for even longer. There are companies that are still using google's old GWT toolkit to code web apps in pure java and transpile javascript front ends out of it. You just hire developers and train them on the tools you use. A decent developer can pick up the basics of a framework or language very very quickly certainly within a 6 month probationary period. The thing is when you do this your company needs to dedicate the resources to keeping the tools you need alive by contributing to open source projects and picking things that aren't short lived and driven by hype.
My first job as a software dev was 2 years ago doing crawlers with Perl in a 10 yo company, and I learned a loooot. The last month I even did son CI and deployment stuff too on their custom servers, no AWS, all in housework. Now I am working in a bigger company using Typescript and Ruby for the BE, and a lot of the knowledge that I got from my first job is valuable for my colleagues. Really thankful for that year working with some real software wizards haha
We've got some VB as well. It's one of those things that still does what it's supposed to and we haven't had to really touch it in the recent decade. As soon as more serious change requests come up it's gonna 1. become someone's life for a couple weeks or 2. get replaced.
man I started really programming with flash, specifically actionscript 3. Before that it was BASIC on a calculator. It was pretty sad to see flash die like it did, I spent a lot of time making games for it
It's true that so many projects which we expect to live forever will actually die within 5-7 years. And yet at the same time there are other projects which will last *much* longer than ever envisioned. In the last month I've had three different projects rear their head, each of which: (1) was first written 18-25 years ago, (2) was meant as a short-term solution, (3) has worked fine multiple times per month without any incident for at least 10 years, (4) had small bugs which suddenly demanded at least four hours of debugging to track down right now, because those bugs were a critical roadblock to some currently-urgent project.
I can't seem to get a nice terse way to say point #3. Let me re-word it to say that these programs have worked fine for their entire life (even though they have run multiple times per month), including the fact that the most recent problem for any of these three projects was more than 10 years ago. They have been very reliable for many years -- until they failed in a major way. One of them it took me over an hour just to remember how it was built because it has been so long since the last time any changes were made to it.
Feels so much like all those classic tradespeople feeling the burn for all those home make overs and house remodellings that rip out the old plumbing / heating / wiring / decor etc to be replace this this year's latest and greatest fashion trends while still having to cope with 'old standard' fitments that aren't the new modern speed fittings! Oh to be another level up the contractor food chain to ride the wave (and then wipe out..). Being your grandfather's axe!
11:20 this hurts my soul... considering we have apps written in this that we still have to maintain until the business gets a clue we need to trash them and prioritize.
Eventually we'll all be dead. Recently I came to a project, which had huge monolithic components, absolutely no reusable components, no tests, to testable functions.... Everything was technical debts, and the project was just 4 months old.
6:37 as an ex system administrator I will never forget the nightmare of not only troubleshooting disgusting java version and IE plugin issues but also just the general nightmare of trying to install the right java version and updating it across a fleet of computers. I actually banned Java completely eventually and also dropped Adobe Flash as soon as I could. It was really a nightmare to support.
I remember spending a summer parallelizing some old Fortran code to run on a multi machine cluster using OpenMPI in like 2005 or 2006 type timeframe. The year later, I did the same for a Matlab codebase, but all of the cluster part was written in C++ using mex to interface with matlab, so only one matlab licenses was needed, and not a license for every node in the cluster. They were amazed that you could do such a thing!
This is long way to explain the importance of internals being made into technical documentation , codifying specifications , edge cases, the domain knowledge and underlying standards.
Your accomplishments become your technical debt. The longer you stay at a company the more debt you accumulate. A good engineer makes decisions that reduce their future maintenance costs and therefore enables them to continue to make progress on new work without being hindered by having to maintain old work. If you’ve made a lot of mistake and your technical debt is too high there is a big incentive to abandoned ship and switch companies. I think an engineer who stays at a company for a long time and stays productive is a champion.
If you move to the fashion industrial, you would be surprised that the clothes you design today, nobody wants to wear it 6 months later. We also call it Design Debt.
My father used to write apps in FoxPro for his business but then migrated to c#. I, by complete coincidence, not only learned c#, but it also became my favorite language, so I work for him now.
I have one of my dad's old asp textbooks. It's more than 1000 pages long. And it's only of of 9 in the series. Imagine reading a 1000 page book on a Javascript framework. By the time you're done noone would even remember that the framework still exists there will have been so many replacements. Nuts.
Most code becomes obsolete in a matter of years. It's one of the reasons why I'm using C++ as my main langage. Everything decays slower in C++. I've got Qt code that's 10-15 years old and that's still relevant today.
Pretty much everything the article states is not something I'd consider tech debt. Tech debt is the stuff that ought to be fixed or replaced as soon as it is made. It's a tradeoff for time now vs later. Writing code in the latest version of your language isn't tech debt because eventually the version gets superseded. That's upkeep.
SOAP and XML was what stopped me getting into software development. I had to learn that in Uni and hated it so much I was like, if this is programming, I don't want to do it.
I started programming at IBM with Assembler doing memory paging in mainframes. And after C, Fortran, Pascal, Prolog, C++, Java, C#, now I'm on Go and Rust. Started the year after the school took the punch cards away... 🙂 Some of that Assembler code still running.
You laugh, but asp web forms and server side controls is same aritecture and approach as react server components and server actions. What is old is new. We even had update panels that interacted with server controls to give us async components, and this was in 2005.
If your engineering career doesn't increase entropy in the universe, than your contributions in that industry were a moot point and you should think about doing something else like basket weaving.
I have code I started in PHP 5.3. It upgraded to PHP 8 just fine. If your PHP code is greatly impacted by major code revisions, it's because you wrote code badly because you did what you were allowed to do rather than use good coding practices because you're supposed to. Bootstrap is an example of when if you do things the correct way, you're screwed when it comes to the new version because they completely changed things.
Agreed. Every time I had to refactor something where I was working to upgrade the PHP version it was always because that code was rotten to begin with.
I come up on 25 years as a dev this year. I think he’s wrong. The stuff he’s used and learned isn’t wasted. It’s context. He has a breadth of experience and confidence in his skills that comes from it. He’s also IMO wrongly equating the terms “technical debt” and “legacy”. I can see the connection, but I don’t see them as synonyms. A legacy app can stay forever as a legacy app. Maybe it gets a rewrite, maybe it doesn’t.
14:50 deserves to be cut out of context and published as a short. "NEVER HAVE I TOUCHED SOAP IN MY LIFETIME" is the most hilarious think to have to explain to a lay person.
I know Delphi but hide it on my resume otherwise I never get a decent job ever in my life. I once made the mistake to go back to Delphi after C#, but took me hell of a time to get a chance to go to C# again.
By that metric anything that is obsolete is tech debt. I differentiate tech debt from obsolescence. Something can be obsolete without having tech debt and being well built. Also, doesn't the tech debt go away when something gets discontinued and replaced by something new?
Basically the guy invested all his time and energy in the latest webdev fad and cant accept that things die. Learnt C 20years ago, still using it today, still relevant, looking forward to the next language that can work in baremetal apps
Why do you think, he can't accept it? I see a critical reflection about his past work, but not regret. I learnt JEE in school and how to build websites with JSF and even stuff like CORBA. Was it unnecessary for today's world? yes. Do I feel bad that I had to deal with this stuff? no. Currently I develop stuff with Java, Spring Boot and Angular and I know for a fact, that these applications will be deprecated at some point and that I will be working with completely different technologies. Every language and framework tackles problems in their own way. It's the concepts you learn on the way, which make this work rewarding in the long term.
@@chri5toph_k Agree with you, but I do think this article is just lamentation and being salty. Every code is deprecated one day, doesn't mean it was bad code or wasn't fun to make
My entire job right now is ripping apart and modernising a webforms monstrosity with a team of 8 Devs while the rest of the company keeps adding features to it...
When picking books to read, I prefer learning something that still might be applicable in 15 years. Soft skills, CS topics, Linux/Unix, how parsers work, etc.
Even in gamedev, your game might get lost to time. Engines might come and go, but the bugs in the games you made, they're there to stay. Or you keep on patching. But it's completely different to corporate code. It's not a tool, it's a piece of interactive art. It feels cool.
As Linus will tell you: It's the data structures that you need to worry about; instead of the code. The data structures persisted to disk will last forever. The code changes continually.
1. Companies/Corporate deprecates platforms and technologies. 2. People want to adopt widely felt standard than niche implementation. 3. Things get out of favour because of popularity and demand from the job market.
SOAP was the devil. You had to pay whatever company for their official $1_000 SOAP library because there were edge cases where SOAP with balk and need one-offs to fix. SOAP is a tech that has bugs inherently designed in it. This article is like a timeline for the last 20 years and raises the question of why are we doing so much useless and vain technology changes?
Meanwhile I'm working with 20+ year old PL/SQL code and freaking IE 5.5 compatible web applications because some of our clients are still using 300 MHz Windows CE mobile handheld computers. Windows XP, Windows Server 2003, SOAP, XML. Businesses have a lot of old shit running and if that is tied to expensive hardware and that still works they don't see any need to change. Why get 50 new mobile handheld computers for 100k and get a retrofit for the application if the old stuff is still running? Get a new pallet stacker crane for millions of bucks because the IPC is still using Windows XP? Not going to happen unless it breaks.
Why people keep saying Ocaml has traits? Modules are very different from traits, maybe even more flexible, but less convenient (it shows even when using basic "traits" like Order, Equal, Show and such). I know Haskell has a bad reputation, but if you want traits outside of Rust, you are stuck with things like Haskell and its clones (eg purescript)
Technical debt is for people that doesn't use JDSL
Tom is beyond TECHNICAL DEBT
Tom is a genius
Tom + JDSL = Pure TECH CREDIT
everything is deprecated since JDSL was introduced to the world... not only is Tom the GOAT in SE, He's a marketing PHD... even Prime fell for it
Tom is a genius
During my teenage years, I gifted a friend of mine a PC computer magazine from the UK, because I was a Mac enthusiast myself. The magazine came with a CD that contained a full version of Delphi. My friend took it upon himself to learn programming using this language and, to this day, continues to find employment because of it. He even regularly secures contracts with the company his father used to work for, maintaining Delphi projects, he started in his teenage years.. I feel compelled to apologize to anyone who might have been affected by this. At the time, I didn't understand what Delphi was, and honestly, I still don't. I apologize for any confusion or inconvenience this may have caused.
I almost feel bad for these companies that got screwed over by progress offshoots that never led anywhere. Almost, because they're companies so fuck 'em. They can afford the switch over.
Delphi is more of an environment. The language is a Pascal dialect. I believe it's Turbo Pascal but it might be Object Pascal, I can't quite remember
@@casperes0912I’m pretty sure it predates object pascal, but don’t quote me on that. I was never a fan of pascal.
Delphi is a dialect of object Pascal, per wikipedia.
I graduated High School last year, we literally learned programming on the latest version of Delhpi
Life's not about the code we write, it's about the bugs we fix along the way.
Then my life is void. I hardly ever have bugs when I release my code, it’s called proper testing 😂
@@CallousCoder sure bud
@@Hobbes9 Nobody’s perfect, “hi my name is nobody” 🤪
Good code doesn't create good stories, but weird bugs do
What matters is not the languages you've used, but the shit you've seen.
My first job (~2011) involved converting some Fortran code to MATLAB & integrating it into a scientific data processing pipeline. The code was written to process atmospheric data gathered from rocket experiments in the 60s. Someone had already moved the code from punch cards to text files, so at least I didn't have to do that part. Eventually I had to convert it to handle the same kind of data but gathered from satellites (which mostly means doing some geometry to account for the different perspective). It was technical debt on two levels. And of course, when they hired me, the only language I knew was C++, so they plopped some Fortran and MATLAB textbooks on my desk and said "figure it out, good luck". That was how I learned the value of writing good documentation for your code... if only the people who wrote that rocket code half a century earlier had learned the same lesson.
and nowadays developer. mimimi I don't know this programming language, even worse, I can only program in "React". (beating the dead horse)
Fortran is still going to be around long after React has been dead and buried with the Action script Ratatouille
And somehow "your code is your documentation" folks still exist.
All the atmospheric transmission models (Lowtran, Modtran, Hitran) still have the underlying 80 column card format data entry basis. Archaeology right there.
I don't touch garbage that's likely to disappear. Started with GNU/Linux and bash in 2001, still here. Started with PHP in 2006, still here. Started with HTML and CSS in 2006, still here. Started with go in 2020, still here. Started with JS in 2009, still here.
THIS. There are (mostly hobby) projects I can't afford to put much time into and using the new hot modern framework that will be dead in two years makes no sense. on the web frontend, HTML+CSS it is, sprinkled with a bit of Javascript. Also, you can do part of frontend input validation in HTML without even using Javascript.
Same, except I didn't really understand consciously what I was doing until recently. I subconsciously didn't feel inclined to putting much time or weight into certain things. I somehow developed a kind of instinct about what was good and what was likely to stick around and be useful. I liked bash (wish I'd learned it earlier) and it's still very common and useful. Didn't like Java (there are now many better languages to do things), enjoyed Windows 'batch' but always had a feeling it wasn't worth investing time in, and I realised why when I finally found bash. I didn't like Visual Basic (it's now dead), didn't like windows SQL (it's been eclipsed by mysql, postgresql etc.). Once I discovered Linux, Windows became dead to me as a solution. Didn't like SVN (and it's now mostly dead and everyone uses git). I like Go (wish I'd started using it earlier). I didn't like XML, preferred JSON (and XML is now largely not used).
I used to believe this but now I think the mainframe COBOL programmers secretly get together at the clubhouse and laugh at the rest of us trying to keep up on the tech hamster wheel. "Look at those kids run!"
It may be a cozy clubhouse, but on the other hand, the number of people in that clubhouse is much *much* smaller than there were COBOL programmers back when I started (1980).
After LISP was invented, nothing else is of relevance, and nothing new under the sun is worth enough.
My dad worked on the same codebase at the same company for his entire career in COBOL. That's almost unthinkable in modern tech.
I'm watching this video from the clubhouse, today.
I think core applications written in C++ have a pretty long lifetime as well - there are some languages that are good to a point where they don't get superseeded by the new shiny thing every year or 2. I honestly don't understand the whole javascript "front end / backend" nonsense, and how it's an ever changing shifting realm
Corporate America has twisted the term MVP into something unrecognizable. It has nothing to do with the MVP in the startup world, which is where the term comes from. If you’re working on something that takes 50 engineers and six months to deliver, in no world is that an “MVP”.
Edit: Voice to speech typos
So true! Minimal Viable Product is something different from Quick hacked together crap.
For me MVP will always be "It barely fucking breaths", nothing will change my mind haha
@@CallousCoder a product is usually deliverable to the client , anything else is a prototype
@@monad_tcp I only work for clients.
I hate how people have added numbers.
"mvp1, then on mvp2 we'll..."
Like, no. There is only one MVP. The M means 'minimum' everything else is an iteration.
Fun fact: the Brits at my job pronounce “deprecated” as “depreciated” and I’ve had multiple, agonizing conversations with them about how this is not a difference of accent
No one cares
@@dandogamer Don’t say that, man. Someone _does_ care about you. I promise.
My colleague at work does this and I don't want to be the guy that points out he's been using a financial term all this time. And we have the same accent so he's saying the wrong word for sure.
Those are two different words. I'm sure they mean depreciated, as in, not appreciated anymore 😂
For a very long time I thought “deprecated” was pronounced as “depreciated” until I heard someone from youtube pronounces it in other way and checked the dictionary
"Given enough time, all your code will get deleted." is another way of saying; on a long enough time scale, your survival rate approaches 0.
I regularly tell my staff "don't get too attached, eventually your baby will be thrown into the dumpster."
My Dad was at Borland and developed Delphi. He still has the box of discs from the 90s
Now that I think about it academic books usually treat change in software engineering as change in requirements but none of them to my knowledge treat change in terms of change in design, change in architecture which would be valuable insight into technical debt. Like most of them will say if you want to deal with change go agile.
See, 90% of these technologies are Web based tools, libraries, and Frameworks. If you learn Java, C, C++, Rust and you don't really give a f*ck, then you don't have to deal with this shit.
I have read Reddit articles where c++ code written by the old team could not be read by the new team so they tried to rewrite it then said eff it and wrote it in Java.
@@ea_naseer sure, but that's just a shitty programmers making mess.
It's still the same technology. This article was mostly focused on web-based stuff that changes every 5-7 years or so.
Yeah... no. Java 8 is *nothing* like java < 8. Nobody mutates in place anymore, even in the core APIs. How's that corba package doing? Have you tried the `Flow` api i.e. reactive programming? You can't write a meaningful app without 100+ annotations. Hell, we aren't even WORA/JIT these days!
Java is *nothing* like it was 20 years ago.
@@adambickford8720 wait, are you saying, java is good now? 😮
@@adambickford8720 sure, but it's still Java. Yes, it may need rewrite, but the syntax and the core of the language is the same.
Part of this guy's problem is that he's clearly been using Microsoft (and other proprietary) stacks which have basically all been wiped out over time. They never last longer than the org that generated them, and even where orgs last they change direction, abandon their old initiatives and they die... This is why open source runs everything now.
DID netflix originally use Silverlight... For some reason Im remembering that it used Silverlight.
The Visionary CTO needs to team up with Tom is a genius and create a startup named "Visionary Genius".
When you said that IE6 and Netscape dev on a resume still meant something to you, you melted my heart a bit. Thank you for handing me a walker, and bless your heart deary~ Most of the time people DGAF about us, but some folks still do I guess.
C devs are laughing at us whilst their code from the 80s remains unchanged.
Heyo!!! It's almost like coding for the "web" is pre-enshitified for your (dis)pleasure
Interesting article. Management in the company I work for should read that.. i had the most horrible developer experience and i am glad i switched into architecture consulting within that company. It's amazing how much product owners cling to old stacks because they don't want to fund refactoring and you as developer have to build skyscrapers on a swamp without draining it first.
Ive found this the further I get in my career the less I care about the code and thats not a bad thing. I still care that its readable. I still care if its maintainable. But I don't care about it being perfect. Perfect really is the enemy of good and sometimes you just need to get some shit on the page and call it a day.
Same. Solve the problem you have now. Don’t try to solve everything forever.
@ThePrimeTime, this may blow your mind ... I've been working in a tech space that has been 'grandfathered' by Microsoft and has not changed in 23 years. I'm talking about Axapta's language 'X++' which was leading ERP tech in 2000 (the days of ColdFusion) and it has not changed since (speaking of the core language). MS has updated the compiler to basically be a pre-parser to #CIL byte code but the language itself has not (and I expect never will) be updated as the customer base has all its tech and processes invested in it. This platform is the #1 selling of ERP platforms. (SAP is still the biggest but not in terms of new deployments)
Once (in 2018), I applied for a programming position at a company. After the interview, they assigned me a task that needed to be completed using FoxPro and mentioned that their entire system was built on it. I believe they are still struggling with that mess...
I think the problem is this agile way of working. I sometimes go 6 mi this without writing a line of code. I used to be an awesome C# developer, now I've forgotten most of it. We're just always jumping from one tho to the next. You can only hope on keeping your knowledge of the basics, loops, data structures, control flow. If you know those three things you'll get by.
I'm currently 19. I had IT classes in high school... The government said we had to learn programming with Delphi, so I suppose I'm already in technical debt
Delphi is not that bad.
@jazzochannel I mean, I like it. I'm doing Advent of Code with it and Python
I worked for a railroad company 25 years ago. Mainframes and Cobol. I’m pretty sure some of my code is still alive. Luckily for me, it’s someone elses technical debt now 😂.
What was that like? How quickly did you consider your own code tech debt?
At release? At merge? At push? At commit? At stage? First run? When first typed? Before it even left your brain?
@@codeman99-dev 80% of the job was writing simple batch programs. Pretty boring stuff. 'Technical debt' wasn't a thing, at least not in my country, so I didn't consider it at all.
I know a company that still uses the same ms-dos inventory system. It was created by the owner, and it's rock solid. Employees that are familiar with it can operate it faster than most UI's today can render and no user has ever found any bugs in it (at least in the last 20 years that I know of).
This is only one part of what technical debt is. Most often, technical debt is what you get when you take shortcuts to meet business deadlines. Technical debt is often when you are writing bad code in the current context, this is a tradeoff for speed to market, for laziness, for lack of manpower and yeah sometimes for lack of updates. Technical debt is also often just shit code you are stuck with.
There are tech stacks that last however. Large established tech stacks last for decades using programming languages that have been around for even longer. There are companies that are still using google's old GWT toolkit to code web apps in pure java and transpile javascript front ends out of it. You just hire developers and train them on the tools you use. A decent developer can pick up the basics of a framework or language very very quickly certainly within a 6 month probationary period. The thing is when you do this your company needs to dedicate the resources to keeping the tools you need alive by contributing to open source projects and picking things that aren't short lived and driven by hype.
React native still uses objective-C for the native layer and I can with confidence say that it is indeed tech debt. I cry everytime I need to touch it
My first job as a software dev was 2 years ago doing crawlers with Perl in a 10 yo company, and I learned a loooot. The last month I even did son CI and deployment stuff too on their custom servers, no AWS, all in housework. Now I am working in a bigger company using Typescript and Ruby for the BE, and a lot of the knowledge that I got from my first job is valuable for my colleagues. Really thankful for that year working with some real software wizards haha
We've got some VB as well. It's one of those things that still does what it's supposed to and we haven't had to really touch it in the recent decade. As soon as more serious change requests come up it's gonna 1. become someone's life for a couple weeks or 2. get replaced.
man I started really programming with flash, specifically actionscript 3. Before that it was BASIC on a calculator. It was pretty sad to see flash die like it did, I spent a lot of time making games for it
It's true that so many projects which we expect to live forever will actually die within 5-7 years. And yet at the same time there are other projects which will last *much* longer than ever envisioned. In the last month I've had three different projects rear their head, each of which: (1) was first written 18-25 years ago, (2) was meant as a short-term solution, (3) has worked fine multiple times per month without any incident for at least 10 years, (4) had small bugs which suddenly demanded at least four hours of debugging to track down right now, because those bugs were a critical roadblock to some currently-urgent project.
I can't seem to get a nice terse way to say point #3. Let me re-word it to say that these programs have worked fine for their entire life (even though they have run multiple times per month), including the fact that the most recent problem for any of these three projects was more than 10 years ago. They have been very reliable for many years -- until they failed in a major way. One of them it took me over an hour just to remember how it was built because it has been so long since the last time any changes were made to it.
Technical debt is what impacts today's work. If it doesn't impact what you're doing today it's not debt.
Feels so much like all those classic tradespeople feeling the burn for all those home make overs and house remodellings that rip out the old plumbing / heating / wiring / decor etc to be replace this this year's latest and greatest fashion trends while still having to cope with 'old standard' fitments that aren't the new modern speed fittings!
Oh to be another level up the contractor food chain to ride the wave (and then wipe out..). Being your grandfather's axe!
Telling people you make sites compatible with IE6 and Netscape should be the new interview flex.
11:20 this hurts my soul... considering we have apps written in this that we still have to maintain until the business gets a clue we need to trash them and prioritize.
I feel this video in the depths of my soul lol. I spent the last 10 years designing and developing RPGLE apps... the pain is real
Eventually we'll all be dead. Recently I came to a project, which had huge monolithic components, absolutely no reusable components, no tests, to testable functions.... Everything was technical debts, and the project was just 4 months old.
6:37 as an ex system administrator I will never forget the nightmare of not only troubleshooting disgusting java version and IE plugin issues but also just the general nightmare of trying to install the right java version and updating it across a fleet of computers. I actually banned Java completely eventually and also dropped Adobe Flash as soon as I could. It was really a nightmare to support.
Oh no, 8:08 I had successfully purged silverlight from my memory.
I remember using Fortran for nuclear physics research in 2015.
I remember spending a summer parallelizing some old Fortran code to run on a multi machine cluster using OpenMPI in like 2005 or 2006 type timeframe. The year later, I did the same for a Matlab codebase, but all of the cluster part was written in C++ using mex to interface with matlab, so only one matlab licenses was needed, and not a license for every node in the cluster. They were amazed that you could do such a thing!
This is long way to explain the importance of internals being made into technical documentation , codifying specifications , edge cases, the domain knowledge and underlying standards.
The first time I encountered client certificates was with a soap wcf project. This project produced my most up-voted stackoverflow question. Lol
Your accomplishments become your technical debt. The longer you stay at a company the more debt you accumulate.
A good engineer makes decisions that reduce their future maintenance costs and therefore enables them to continue to make progress on new work without being hindered by having to maintain old work.
If you’ve made a lot of mistake and your technical debt is too high there is a big incentive to abandoned ship and switch companies. I think an engineer who stays at a company for a long time and stays productive is a champion.
Awesome.... I love how you make dry topics so exciting!
If you move to the fashion industrial, you would be surprised that the clothes you design today, nobody wants to wear it 6 months later. We also call it Design Debt.
14:45 "I'm just like every good Arch user: I've never used SOAP."
Brilliant.
My father used to write apps in FoxPro for his business but then migrated to c#. I, by complete coincidence, not only learned c#, but it also became my favorite language, so I work for him now.
I have one of my dad's old asp textbooks. It's more than 1000 pages long. And it's only of of 9 in the series. Imagine reading a 1000 page book on a Javascript framework. By the time you're done noone would even remember that the framework still exists there will have been so many replacements. Nuts.
Most code becomes obsolete in a matter of years. It's one of the reasons why I'm using C++ as my main langage. Everything decays slower in C++. I've got Qt code that's 10-15 years old and that's still relevant today.
Pretty much everything the article states is not something I'd consider tech debt. Tech debt is the stuff that ought to be fixed or replaced as soon as it is made. It's a tradeoff for time now vs later. Writing code in the latest version of your language isn't tech debt because eventually the version gets superseded. That's upkeep.
SOAP and XML was what stopped me getting into software development. I had to learn that in Uni and hated it so much I was like, if this is programming, I don't want to do it.
I set up ASP Nuke using ASP and MS Access for the database on my Windows 98 system.
I started programming at IBM with Assembler doing memory paging in mainframes. And after C, Fortran, Pascal, Prolog, C++, Java, C#, now I'm on Go and Rust. Started the year after the school took the punch cards away... 🙂 Some of that Assembler code still running.
19:57 Unless it has some "temporary change" comments in it - then it stays forever.
I suspect that the Flash thing you were thinking of is Ruffle. It's a pretty cool project :>
You laugh, but asp web forms and server side controls is same aritecture and approach as react server components and server actions. What is old is new. We even had update panels that interacted with server controls to give us async components, and this was in 2005.
If your engineering career doesn't increase entropy in the universe, than your contributions in that industry were a moot point and you should think about doing something else like basket weaving.
I had to use SOAP in uni, the setup alone was a chore and so many things used to go wrong.
14:50 At my work we use Salesforce. For some reason Salesforce loves SOAP. I hate SOAP.
I have code I started in PHP 5.3. It upgraded to PHP 8 just fine.
If your PHP code is greatly impacted by major code revisions, it's because you wrote code badly because you did what you were allowed to do rather than use good coding practices because you're supposed to.
Bootstrap is an example of when if you do things the correct way, you're screwed when it comes to the new version because they completely changed things.
Agreed. Every time I had to refactor something where I was working to upgrade the PHP version it was always because that code was rotten to begin with.
That’s easy to say in hindsight, but it isn’t always apparent what will be the correct way looking forward. Sometimes changes are just breaking.
@@TehKarmalizer best practices haven't changed in decades
@@bkucenski I can’t speak for PHP, but C# and C++ have both evolved best practices as better language features have developed.
@@TehKarmalizer they still use classes and don't promote spaghetti code
I come up on 25 years as a dev this year. I think he’s wrong. The stuff he’s used and learned isn’t wasted. It’s context. He has a breadth of experience and confidence in his skills that comes from it.
He’s also IMO wrongly equating the terms “technical debt” and “legacy”.
I can see the connection, but I don’t see them as synonyms. A legacy app can stay forever as a legacy app. Maybe it gets a rewrite, maybe it doesn’t.
14:50 deserves to be cut out of context and published as a short. "NEVER HAVE I TOUCHED SOAP IN MY LIFETIME" is the most hilarious think to have to explain to a lay person.
Me, working in JS in ServiceNow 😅- the platform is a new level of circus hoops to jump thru with OOB vs custom scripting
missed opportunity at the end: "The name - not a quiet-quitter-agen"
I know Delphi but hide it on my resume otherwise I never get a decent job ever in my life.
I once made the mistake to go back to Delphi after C#, but took me hell of a time to get a chance to go to C# again.
Perfect! Everything eventually is technically debt. Every move you make is a result of which trade off you can accept
"I though the ColdFusion was a RUclips channel" Jesus, that's too good...
I am sure you would agree that quiet quitting is fine as long as you use the extra time to crush it at something else, like looking for the next gig
Silverlight is called WASM now :) Why it failed? Becasue it was made by Microsoft. Why WASM is good? Because it wasn't made by Microsoft :)
By that metric anything that is obsolete is tech debt.
I differentiate tech debt from obsolescence. Something can be obsolete without having tech debt and being well built.
Also, doesn't the tech debt go away when something gets discontinued and replaced by something new?
Basically the guy invested all his time and energy in the latest webdev fad and cant accept that things die. Learnt C 20years ago, still using it today, still relevant, looking forward to the next language that can work in baremetal apps
hard to argue against C in this context
Why do you think, he can't accept it?
I see a critical reflection about his past work, but not regret.
I learnt JEE in school and how to build websites with JSF and even stuff like CORBA. Was it unnecessary for today's world? yes. Do I feel bad that I had to deal with this stuff? no.
Currently I develop stuff with Java, Spring Boot and Angular and I know for a fact, that these applications will be deprecated at some point and that I will be working with completely different technologies.
Every language and framework tackles problems in their own way. It's the concepts you learn on the way, which make this work rewarding in the long term.
ah yes, still relevant for accidentally making malware
@@chri5toph_k Agree with you, but I do think this article is just lamentation and being salty. Every code is deprecated one day, doesn't mean it was bad code or wasn't fun to make
@@JorgetePanete K
The name is the Tomagen
Tomagenius
Joke's on you, my company is too under-staffed to deprecate any of my out-dated janky software.
My entire job right now is ripping apart and modernising a webforms monstrosity with a team of 8 Devs while the rest of the company keeps adding features to it...
When picking books to read, I prefer learning something that still might be applicable in 15 years. Soft skills, CS topics, Linux/Unix, how parsers work, etc.
Even in gamedev, your game might get lost to time. Engines might come and go, but the bugs in the games you made, they're there to stay.
Or you keep on patching. But it's completely different to corporate code. It's not a tool, it's a piece of interactive art.
It feels cool.
As Linus will tell you: It's the data structures that you need to worry about; instead of the code. The data structures persisted to disk will last forever. The code changes continually.
1. Companies/Corporate deprecates platforms and technologies.
2. People want to adopt widely felt standard than niche implementation.
3. Things get out of favour because of popularity and demand from the job market.
So people think their code will run forever?
I did web apps with VB6, ASP, IE6. I also used SOAP with web services written in java
i believe it was The Buddha who said, "There is no enduring software"
The T in CTO stands for Tom
The Harmon browser is still available for those who still want to use Flash. For all those 'enterprise' apps that no one can be bothered to port.
My entire company is technical debt...
Thanks a lot for the video.
I wanna know who at Netflix thought Spinnaker was a good idea. 9000x tech debt.
Anything in versions past 2 years might just go from technical debt to security vulnerability.
why dont you show the article link in the description?
Can someone explain the joke with JDSL and Tom, i don't quite get it ?
My current and first development job is in visual basic. Ugh.
I have seen some sh*t. Approaching 30 year full stack career anniversary.
Still using Web Forms, WCF and SOAP at work for many systems 🗿
SOAP was the devil. You had to pay whatever company for their official $1_000 SOAP library because there were edge cases where SOAP with balk and need one-offs to fix. SOAP is a tech that has bugs inherently designed in it.
This article is like a timeline for the last 20 years and raises the question of why are we doing so much useless and vain technology changes?
Needed that advice for beginner programmers. Just make more things, don’t make it perfect, make small iterative improvements over time. Got it chief
Meanwhile I'm working with 20+ year old PL/SQL code and freaking IE 5.5 compatible web applications because some of our clients are still using 300 MHz Windows CE mobile handheld computers. Windows XP, Windows Server 2003, SOAP, XML. Businesses have a lot of old shit running and if that is tied to expensive hardware and that still works they don't see any need to change. Why get 50 new mobile handheld computers for 100k and get a retrofit for the application if the old stuff is still running? Get a new pallet stacker crane for millions of bucks because the IPC is still using Windows XP? Not going to happen unless it breaks.
All your code will be lost to time, like tears in rain
Why people keep saying Ocaml has traits? Modules are very different from traits, maybe even more flexible, but less convenient (it shows even when using basic "traits" like Order, Equal, Show and such).
I know Haskell has a bad reputation, but if you want traits outside of Rust, you are stuck with things like Haskell and its clones (eg purescript)
I recently worked for a company that built new software that used SOAP in 2022
OK now we should look at the people who write legacy code in real-time.