I own a company that has major parts of their system in Perl too. They are desperately trying to rewrite it and get off it, but it is a never ending battle. So many companies get stuck trying to continually modernize old systems that nobody wants to support anymore.
Yeah, also know a couple of such companies. Some of them though are facing the fact that almost ALL of their Cobol devs are going to retire in the next 5 years and they are trying to train youngsters, but they are either not really interested or, once they're trained try to grab some big $$ at some other Cobol-company.
The idea is to rewrite most of that Cobol code to something more up to date, even though these are huge projects, but having unmaintainable code running your entire business is...Well...a pretty big risk to say the least.
Exactly. For a long time one of those companies were clearly going for the status quo: everything is going fine, no issues here.
Then all of a sudden they noticed that soon all of their Cobol-devs would be on retirement, so they started the training stuff, like a way to buy some time and push forward the conversion they'd be facing.
But now they don't have that conversion yet, and not really skilled Cobol-devs soon. So they'll start to plan for that overdue conversion, and I'm sure they'll be taking some shortcuts there, which will result in lesser quality code. (and then they can blame that new 'immature' technolgy ;-) )
I’m sure the “hall of epic technologies” carousel viewer you wrote in Macromedia Shockwave and Visual Foxpro is truly something to behold, but, the rest of us have moved on.
What is your definition of technical debt? You may have replaced the carousel viewer with the new hotness, but good luck rewriting the commercial system with hundreds of integrations I wrote in 1998. It is still in use, actively marketed, and supported.
What you're really saying is how utterly immature software development is compared to literally every other field.
Why do we have such tremendous bloody ADD at constantly making new ways of doing the same thing? New languages and frameworks as a rule do not add any real value, they just create the problems you discuss, that we all see over and over again.
Some languages do provide something useful, like Rust memory safe C-speed code, or scientific languages that aid in all kinds of fancy math. Is Go really better than Java? I would say no, it isn't. I am quite proficient in both. The problem with Java isn't the language, but how it is used - contrary to what the Java community seems to think, every problem does not have to be solved with huge libraries and tons of reflection.
There is nothing wrong with MVC, it is still a good paradigm. Angular is not a real improvement, it is just more complicated and makes it harder to understand the code because you have to examine so many things at once (filters, routes, generated typescript code, a bunch of separate scss files that get compiled, etc).
Often we do stuff with no explanation. Why did we decide to move business logic into the front end? I cannot find any explanation of why this is better or what problem it solves. I don't see it solving any problem, it just shoves all the problems of backend rendering into the front end.
This is what we love to do - shove problems from here to there for no apparent reason. We're basically allowing ourselves to be pulled around by the nose by every new thing that comes out. We worship popularity above all else - every "new" tool that we "just have to obviously switch to" is just whatever is popular, with no regard for why, what problem it solves, or how it solves it better.
Virtually every promise of how much better the "new way" is, only applied to a small code base. As the code base becomes larger and larger, problems ensue that are really pretty much the same problems as before.
Everything we do is just progress for the sake of progress, which winds up being no real progress at all. We seem to be endlessly searching for better ways of doing things, but never finding them. At the end of the day, I seem the same problems occurring over and over with every "new" thing that comes along.
Ehhhh yes, but “<handwave>... Moore’s Law!” is a little bit lazy.
The issue is also that innovation is fractal, and so as feedback loops in software engineering get tighter and tighter (due to Moore’s Law), it becomes less and less practical to stay aware and familiar with “everything.”
And a constant wave of new people with “new” ideas practically guarantees that we will reinvent MVC-ish, OOP-ish, GoF-ish, etc etc patterns, in the small, all over the surface area of innovation. Because it’s the right “meta pattern”, just badly implemented by someone new with slightly different constraints and objectives and a lack of depth in perspective.
It is *extremely* hard to bet well on new tech. If you picked .NET in the early 2000s (and survived to 2.0 (maybe 3.0)) - congrats! If you picked Perl in the early 2000s, based on then-clout and the awaited v6 - my apologies.
(If you bet on Python 3 in the early 2000s the n I hope you didn’t get totally destroyed for 10-15 years and that you kept your skills somewhat unrusty)
The innovation cycle is speeding up, too. C# is a vastly more powerful language today than it used to be. There are a gabillion JS frameworks and if you blink the one you are betting your web app on is already falling behind (and/or you have a Slack channel of FE engineers conspiring to replace it).
One of the biggest factors in long run success is community support, because critical mass is what’s going to drive future engineer generation interest and hireability. If you insist on staying at the bleeding edge, you are primarily rolling the dice on whether the language community evolves and grows or not.
Good points. Like you, I've lived through multiple decades of reinvention (*-ish)., so let me try again.
We are living through accelerated cycles of chaos-to-order, each cycle with a new promise to justify more chaos. I think the engine, even as much as the Moore's Law phenomenon, is the inherent symmetry in the universe and the reduction of complexity once unlocked. And it's beginning again! A new compute model built around a new type of instruction set composed of "deconvolution" prompts that operate on stored language neural networks.
Maybe we need to look at the definition of technical debt. Real technical debt is when systems break and typically in a way that is dangerous / Insecure. Technical debt has been narrowed here to inefficient technologies but real technical debt is Insecure code that makes your data or application vulnerable. With this kind of technical debt (often occurring when you acquire a company) the migration or resolution needs to sudden and efficient. Whereas the updating of a old language or library can take place at a much more sedate pace in most situations.
"Good luck hiring people for old tech stacks." As someone with 40 years playing this game, this is going to be what I do for fun (and money) when I retire :)
There are many fields where the problem space is static, the existing code has been running for a very long time and so is battle tested and trusted, and the cost of potentially creating a new problem massively exceeds any possible benefit from making any changes. Think banking, finance, military, industrial control, and emergency services.
In these fields, some code seemingly lives forever- or at least outlives its creators. I know a company built on a single program that had not modified their code in many decades, but instead had migrated from a room full of PDP-11s to a bunch of VMs on a Linux box to increase performance.
Also note that IBM sells many billions of dollars of mainframe iron every year with the primary value preposition that it will allow you to run your unmodified System/360 code from 1964 (with 99.99999% availability).
I worked with ASP.NET MVC for a while. What a complex mess and the new ASP.NET Core isnot really much better considering that it still uses the MVC paradigm.
Infragistics and Telerik have kept refining their ASP.NET WebForms Components. I wonder why...
I did web development for many years; a lot with WebForms. I am still developing after having retired in 2014 after 43+ years in the profession. I will not use anything but WebForms if I work on another web development project.
Screw the new technologies! They are just more complex, and as a result, less efficient, while also requiring more time to learn. Why would anyone bother? Probably because its just the cool thing to do.
Interesting read. Though I'm not sure what I'm supposed to take away from the article. You use the terms technical debt, deprecate and sunset interchangeably. I see technical debt as something that applies to software that is still being used and in active development. Deprecating or sunsetting software is very different. I don't think you are making a statement about technical debt or how to deal with it in software development. You seem to be making a statement about deriving value and reward from software development based on how long your code survives.
Perhaps the last sentence best states the thesis of your article. "Given enough time, all your code will get deleted." In my opinion, this statement as well as the overall tone of the article presents a negative view or outlook of software development. I might come away thinking, "if all my code is going to get deleted, what's the point? Why am I'm expending effort, working hard, etc.?"
I think measuring that value, reward or purpose of software and the software development process by whether code is eventually deleted or not is misguided. If that is the measuring stick for the worth of your work, then you are in the wrong field.
After 35 years in the industry, I've concluded that the two main ways I derive value and reward from software development are:
1) It is a creative process. I love the iterative process of coming up with a design and then crafting code based on that design. As this process plays out, I see better ways to organize the code. To make it more understandable, more beautiful in a sense. I enjoy CREATING and BUILDING software, just like I enjoy woodworking. It is an interesting combination of math, science and art.
2) I have worked on many products that are no longer in use, but for me that does not take away from the value that they once provided to the customer. Generally the products I've worked on made people lives better and were stepping stones to the next generation of software. One quick example: My first job out of college was with Apple Computer. I worked on MacApp, one of the first object-oriented application frameworks. MacApp has not been used to build applications for many, many years. None the less, its legacy lives on in at least two ways. First, it was the predecessor to the Next application framework, which is the predecessor to the current MacOS/iOS development framework. Second, many useful applications were built on MacApp. Applications that made peoples lives better. Industrial Light & Magic (https://www.ilm.com/) were one of the early adopters of MacApp. They built software that controlled their animation sets on MacApp. Many of the movies from the 80's and 90's were better because of MapApp and the work which me and my team did. Yes MacApp is dead now, but I still love watching the old Star War movies! And that software was the stepping stone to the technology that Industrial Light and Magic employs today.
So there are more positive ways to measure the reward and worth of the software development process than whether your code is eventually deprecated. We all agree it will be.
I agree we all love creating and building software. It is our own Legos to play with. The point of the article was that most software eventually gets sunset for various reasons or it becomes major work for someone to upgrade and modernize. Most software has some form of shelf life and we shouldn't beat ourself up about it being perfect. What seems like perfect code today will likely not be perfect in a few years because things change.
Cause you need to use crossplatform C. Write all your code like it is intended to be embedded in Android,Linux,Windows,MacOS and *BSD app simultaneously. It actually may be, if you or your company will want right now or in the future to contribute your code into something like crossplatform video player (mpv/vlc). You simply cannot achieve such crossplatformness with some shit like nodejs. Why you need crossplatformness? Well, the more code ported, the more code lives. If you wrote code for you company, and it can’t be ported on mipsel, well, your company will be in a big trouble in not so distant RISC-V future. If your code can’t be ported on armv5, you’re in a big trouble now.
The Homestarrunner reference kind of blew my mind. Not only does it make sense from a context point of view, and "nerds of a certain age" will inevitably get the reference, but...the cartoonists themselves fell victim to technical debt! For what seemed like a decade you couldn't watch the cartoons on many mobile devices because it was all written in Adobe Flash. It looks like they recently came up with an...ahem...workaround...
I was a mechanical engineer before becoming a programmer around 1995. Started with VB4 and went through REST and MVC before I retired. It is very depressing to realize that, like you, everything I did is now deprecated or deleted. I did do a lot of back-end work with relational databases and enjoyed the fact that the old techniques still worked even after newer techniques were introduced. But I digress. My main point is that in "harder" engineering disciplines like civil and mechanical engineering, your work does not depreciate so rapidly. It's almost enough of a benefit to overcome the difference in pay.
Things have definitely changed a ton of our careers. I feel like it will slow down now and the separation of front end frameworks from the back end has been needed and awesome. However, I feel like WebAssembly could ultimately upend everything again and the cycle repeats!
I tried to express it in a bit of article I wrote recently.
I think tech endeavors need to consider tech debt as a part of the process of building anything, and not like some avoidable thing that we allow to go fast. The metaphor of debt is not working out for me here, I think this is more similar to an inevitable misalignment between a piece of software and its environment. This is not only true technically, but as well as in terms of problem-solving, or of product design.
This misalignment needs addressing all the time, and maybe we need to learn to be more attentive to those, and build software in a way that makes them easier to evolve from the ground up.
Rapid advancements in tech do not go hand in hand with Stability and consistency. Choose one or the other.
... except SQL and email. They will never die.
People are still building systems in Delphi and PERL. Delphi actually had a new release just a couple of months ago.
I own a company that has major parts of their system in Perl too. They are desperately trying to rewrite it and get off it, but it is a never ending battle. So many companies get stuck trying to continually modernize old systems that nobody wants to support anymore.
There are still plenty of COBOL systems hanging around and I've come across one or two 30 yo TCL solutions I've had to maintain/port in my time too.
There's good money in it for some - as no one else wants to do it.
Upgrading old software is a never-ending business!
Yeah, also know a couple of such companies. Some of them though are facing the fact that almost ALL of their Cobol devs are going to retire in the next 5 years and they are trying to train youngsters, but they are either not really interested or, once they're trained try to grab some big $$ at some other Cobol-company.
The idea is to rewrite most of that Cobol code to something more up to date, even though these are huge projects, but having unmaintainable code running your entire business is...Well...a pretty big risk to say the least.
Seems like there a simple choice here:
1. pay the cost to rewrite
2. pay enough to keep the newly trained cobol developers.
3. get into a worse position by taking no clear action.
3 is the status quo.
Exactly. For a long time one of those companies were clearly going for the status quo: everything is going fine, no issues here.
Then all of a sudden they noticed that soon all of their Cobol-devs would be on retirement, so they started the training stuff, like a way to buy some time and push forward the conversion they'd be facing.
But now they don't have that conversion yet, and not really skilled Cobol-devs soon. So they'll start to plan for that overdue conversion, and I'm sure they'll be taking some shortcuts there, which will result in lesser quality code. (and then they can blame that new 'immature' technolgy ;-) )
Yeah this post is heavy on fud and light on realism
I’m sure the “hall of epic technologies” carousel viewer you wrote in Macromedia Shockwave and Visual Foxpro is truly something to behold, but, the rest of us have moved on.
What is your definition of technical debt? You may have replaced the carousel viewer with the new hotness, but good luck rewriting the commercial system with hundreds of integrations I wrote in 1998. It is still in use, actively marketed, and supported.
What you're really saying is how utterly immature software development is compared to literally every other field.
Why do we have such tremendous bloody ADD at constantly making new ways of doing the same thing? New languages and frameworks as a rule do not add any real value, they just create the problems you discuss, that we all see over and over again.
Some languages do provide something useful, like Rust memory safe C-speed code, or scientific languages that aid in all kinds of fancy math. Is Go really better than Java? I would say no, it isn't. I am quite proficient in both. The problem with Java isn't the language, but how it is used - contrary to what the Java community seems to think, every problem does not have to be solved with huge libraries and tons of reflection.
There is nothing wrong with MVC, it is still a good paradigm. Angular is not a real improvement, it is just more complicated and makes it harder to understand the code because you have to examine so many things at once (filters, routes, generated typescript code, a bunch of separate scss files that get compiled, etc).
Often we do stuff with no explanation. Why did we decide to move business logic into the front end? I cannot find any explanation of why this is better or what problem it solves. I don't see it solving any problem, it just shoves all the problems of backend rendering into the front end.
This is what we love to do - shove problems from here to there for no apparent reason. We're basically allowing ourselves to be pulled around by the nose by every new thing that comes out. We worship popularity above all else - every "new" tool that we "just have to obviously switch to" is just whatever is popular, with no regard for why, what problem it solves, or how it solves it better.
Virtually every promise of how much better the "new way" is, only applied to a small code base. As the code base becomes larger and larger, problems ensue that are really pretty much the same problems as before.
Everything we do is just progress for the sake of progress, which winds up being no real progress at all. We seem to be endlessly searching for better ways of doing things, but never finding them. At the end of the day, I seem the same problems occurring over and over with every "new" thing that comes along.
Nope. It has nothing to do with ADD or coolness, or wanting to work on the next hot, exciting trend. Those are all secondary.
Simply stated in two words: Moore's Law. Full stop.
Ehhhh yes, but “<handwave>... Moore’s Law!” is a little bit lazy.
The issue is also that innovation is fractal, and so as feedback loops in software engineering get tighter and tighter (due to Moore’s Law), it becomes less and less practical to stay aware and familiar with “everything.”
And a constant wave of new people with “new” ideas practically guarantees that we will reinvent MVC-ish, OOP-ish, GoF-ish, etc etc patterns, in the small, all over the surface area of innovation. Because it’s the right “meta pattern”, just badly implemented by someone new with slightly different constraints and objectives and a lack of depth in perspective.
It is *extremely* hard to bet well on new tech. If you picked .NET in the early 2000s (and survived to 2.0 (maybe 3.0)) - congrats! If you picked Perl in the early 2000s, based on then-clout and the awaited v6 - my apologies.
(If you bet on Python 3 in the early 2000s the n I hope you didn’t get totally destroyed for 10-15 years and that you kept your skills somewhat unrusty)
The innovation cycle is speeding up, too. C# is a vastly more powerful language today than it used to be. There are a gabillion JS frameworks and if you blink the one you are betting your web app on is already falling behind (and/or you have a Slack channel of FE engineers conspiring to replace it).
One of the biggest factors in long run success is community support, because critical mass is what’s going to drive future engineer generation interest and hireability. If you insist on staying at the bleeding edge, you are primarily rolling the dice on whether the language community evolves and grows or not.
Good points. Like you, I've lived through multiple decades of reinvention (*-ish)., so let me try again.
We are living through accelerated cycles of chaos-to-order, each cycle with a new promise to justify more chaos. I think the engine, even as much as the Moore's Law phenomenon, is the inherent symmetry in the universe and the reduction of complexity once unlocked. And it's beginning again! A new compute model built around a new type of instruction set composed of "deconvolution" prompts that operate on stored language neural networks.
Perfect:
"Given enough time, all your code will get deleted."
Maybe we need to look at the definition of technical debt. Real technical debt is when systems break and typically in a way that is dangerous / Insecure. Technical debt has been narrowed here to inefficient technologies but real technical debt is Insecure code that makes your data or application vulnerable. With this kind of technical debt (often occurring when you acquire a company) the migration or resolution needs to sudden and efficient. Whereas the updating of a old language or library can take place at a much more sedate pace in most situations.
"Good luck hiring people for old tech stacks." As someone with 40 years playing this game, this is going to be what I do for fun (and money) when I retire :)
Isn't it a good thing? I would hate to be still stuck on VB 6.0, ActiveX and ASP. Delphi was fun though.
"All code rots or gets replaced"
There are many fields where the problem space is static, the existing code has been running for a very long time and so is battle tested and trusted, and the cost of potentially creating a new problem massively exceeds any possible benefit from making any changes. Think banking, finance, military, industrial control, and emergency services.
In these fields, some code seemingly lives forever- or at least outlives its creators. I know a company built on a single program that had not modified their code in many decades, but instead had migrated from a room full of PDP-11s to a bunch of VMs on a Linux box to increase performance.
Also note that IBM sells many billions of dollars of mainframe iron every year with the primary value preposition that it will allow you to run your unmodified System/360 code from 1964 (with 99.99999% availability).
Long live FoxPro.
So true! Thanks.
I worked with ASP.NET MVC for a while. What a complex mess and the new ASP.NET Core isnot really much better considering that it still uses the MVC paradigm.
Infragistics and Telerik have kept refining their ASP.NET WebForms Components. I wonder why...
I did web development for many years; a lot with WebForms. I am still developing after having retired in 2014 after 43+ years in the profession. I will not use anything but WebForms if I work on another web development project.
Screw the new technologies! They are just more complex, and as a result, less efficient, while also requiring more time to learn. Why would anyone bother? Probably because its just the cool thing to do.
Interesting read. Though I'm not sure what I'm supposed to take away from the article. You use the terms technical debt, deprecate and sunset interchangeably. I see technical debt as something that applies to software that is still being used and in active development. Deprecating or sunsetting software is very different. I don't think you are making a statement about technical debt or how to deal with it in software development. You seem to be making a statement about deriving value and reward from software development based on how long your code survives.
Perhaps the last sentence best states the thesis of your article. "Given enough time, all your code will get deleted." In my opinion, this statement as well as the overall tone of the article presents a negative view or outlook of software development. I might come away thinking, "if all my code is going to get deleted, what's the point? Why am I'm expending effort, working hard, etc.?"
I think measuring that value, reward or purpose of software and the software development process by whether code is eventually deleted or not is misguided. If that is the measuring stick for the worth of your work, then you are in the wrong field.
After 35 years in the industry, I've concluded that the two main ways I derive value and reward from software development are:
1) It is a creative process. I love the iterative process of coming up with a design and then crafting code based on that design. As this process plays out, I see better ways to organize the code. To make it more understandable, more beautiful in a sense. I enjoy CREATING and BUILDING software, just like I enjoy woodworking. It is an interesting combination of math, science and art.
2) I have worked on many products that are no longer in use, but for me that does not take away from the value that they once provided to the customer. Generally the products I've worked on made people lives better and were stepping stones to the next generation of software. One quick example: My first job out of college was with Apple Computer. I worked on MacApp, one of the first object-oriented application frameworks. MacApp has not been used to build applications for many, many years. None the less, its legacy lives on in at least two ways. First, it was the predecessor to the Next application framework, which is the predecessor to the current MacOS/iOS development framework. Second, many useful applications were built on MacApp. Applications that made peoples lives better. Industrial Light & Magic (https://www.ilm.com/) were one of the early adopters of MacApp. They built software that controlled their animation sets on MacApp. Many of the movies from the 80's and 90's were better because of MapApp and the work which me and my team did. Yes MacApp is dead now, but I still love watching the old Star War movies! And that software was the stepping stone to the technology that Industrial Light and Magic employs today.
So there are more positive ways to measure the reward and worth of the software development process than whether your code is eventually deprecated. We all agree it will be.
I agree we all love creating and building software. It is our own Legos to play with. The point of the article was that most software eventually gets sunset for various reasons or it becomes major work for someone to upgrade and modernize. Most software has some form of shelf life and we shouldn't beat ourself up about it being perfect. What seems like perfect code today will likely not be perfect in a few years because things change.
Cause you need to use crossplatform C. Write all your code like it is intended to be embedded in Android,Linux,Windows,MacOS and *BSD app simultaneously. It actually may be, if you or your company will want right now or in the future to contribute your code into something like crossplatform video player (mpv/vlc). You simply cannot achieve such crossplatformness with some shit like nodejs. Why you need crossplatformness? Well, the more code ported, the more code lives. If you wrote code for you company, and it can’t be ported on mipsel, well, your company will be in a big trouble in not so distant RISC-V future. If your code can’t be ported on armv5, you’re in a big trouble now.
I achieve the same thing by using C#.
The Homestarrunner reference kind of blew my mind. Not only does it make sense from a context point of view, and "nerds of a certain age" will inevitably get the reference, but...the cartoonists themselves fell victim to technical debt! For what seemed like a decade you couldn't watch the cartoons on many mobile devices because it was all written in Adobe Flash. It looks like they recently came up with an...ahem...workaround...
I'm glad some of you got the reference if you had been doing this as long as me :-)
I was a mechanical engineer before becoming a programmer around 1995. Started with VB4 and went through REST and MVC before I retired. It is very depressing to realize that, like you, everything I did is now deprecated or deleted. I did do a lot of back-end work with relational databases and enjoyed the fact that the old techniques still worked even after newer techniques were introduced. But I digress. My main point is that in "harder" engineering disciplines like civil and mechanical engineering, your work does not depreciate so rapidly. It's almost enough of a benefit to overcome the difference in pay.
Things have definitely changed a ton of our careers. I feel like it will slow down now and the separation of front end frameworks from the back end has been needed and awesome. However, I feel like WebAssembly could ultimately upend everything again and the cycle repeats!
This resonates a lot with me.
I tried to express it in a bit of article I wrote recently.
I think tech endeavors need to consider tech debt as a part of the process of building anything, and not like some avoidable thing that we allow to go fast. The metaphor of debt is not working out for me here, I think this is more similar to an inevitable misalignment between a piece of software and its environment. This is not only true technically, but as well as in terms of problem-solving, or of product design.
This misalignment needs addressing all the time, and maybe we need to learn to be more attentive to those, and build software in a way that makes them easier to evolve from the ground up.