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.
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.
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.
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.
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.
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).
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.
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.
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.