In my opinion, the problem is not technical debt by itself, or technical issues. These are fixable if you know how.
However: Organizations which heap technical debt have likely a culture that encouraged it. It is unlikely you can change that without management buy-in. Especially if old developers don’t have the desire to change their ways. Many believe that producing bad quality gets results faster (which isn’t true once you look further than about 6-9 months - it is an erroneous belief system).
I think these incidents like a calculator leaking 32GB are not the problem in the industry. These are isolated issues, and fixable as you say. The bigger problem are many “smol” programs are written without performance in mind at all, with crazy languages like JavaScript, its bloated environment and runtimes and frameworks like React and a huge browser to run it. While they do not leak memory like crazy, they hog a lot and people accept it. If all programs are like this, then you end up doing 16GB for simple tasks (random number chosen for likes), while the 32 GB leaked app is corrected and now just uses 200 MB at max (just random number again, to illustrate my point).
While they do not leak memory like crazy, they hog a lot and people accept it.
They do not leak memory at all. Using a lot of memory is not the same as leaking memory. And from a practical perspective, it doesn’t really matter if a calculator app on iOS uses a gigabyte or three of RAM, as the amount of multi-tasking a user can do on a phone is severely limited, and the operating system kills background apps when it needs to reclaim memory for the foreground.
The bigger problem are many “smol” programs are written without performance in mind at all
Do you have specific examples of this? The iOS calculator sucks, but it does not have performance problems. People who think every piece of software needs to be hyper-optimized are either unemployed (or should be) as they don’t get any work done, or they just don’t practice what they preach. IME, it’s usually beginners/novices who discovered what a “native” language is, like C++ or Rust, and are going through a phase. None of those people know how to actually optimize a program, haven’t even heard of Compiler Explorer, think “MESI” is a soccer player, and probably know more about TUI frameworks than profiling ones.
Yes, the concept “release early, release often” is the most practical, especially if you’re doing something new and therefore cannot fully predict how the things should be.
Yes, the concept “release early, release often” is the most practical, especially if you’re doing something new and therefore cannot fully predict how the things should be.
That is not the same. The Linux kernel project. releases early and often, but it is high quality.
Iterating in small steps is a consequence of that you usually can’t lay out all requirements beforehand. But you still need to plan architecture, determine requirements, write down design, document APIs and pre-conditions, run tests and so on. And change and adapt all that, again and again , when requirements change. (Which means that, in larger or long-running projects, requirements which are missing merely due to laziness do have a high cost.)
John Ousterhout talks about this at length in his book “A Philosophy of Software Design” (right now discussed here)… He calls that “strategic” vs. “tactical” programming.
In my opinion, the problem is not technical debt by itself, or technical issues. These are fixable if you know how.
However: Organizations which heap technical debt have likely a culture that encouraged it. It is unlikely you can change that without management buy-in. Especially if old developers don’t have the desire to change their ways. Many believe that producing bad quality gets results faster (which isn’t true once you look further than about 6-9 months - it is an erroneous belief system).
I think these incidents like a calculator leaking 32GB are not the problem in the industry. These are isolated issues, and fixable as you say. The bigger problem are many “smol” programs are written without performance in mind at all, with crazy languages like JavaScript, its bloated environment and runtimes and frameworks like React and a huge browser to run it. While they do not leak memory like crazy, they hog a lot and people accept it. If all programs are like this, then you end up doing 16GB for simple tasks (random number chosen for likes), while the 32 GB leaked app is corrected and now just uses 200 MB at max (just random number again, to illustrate my point).
They do not leak memory at all. Using a lot of memory is not the same as leaking memory. And from a practical perspective, it doesn’t really matter if a calculator app on iOS uses a gigabyte or three of RAM, as the amount of multi-tasking a user can do on a phone is severely limited, and the operating system kills background apps when it needs to reclaim memory for the foreground.
Do you have specific examples of this? The iOS calculator sucks, but it does not have performance problems. People who think every piece of software needs to be hyper-optimized are either unemployed (or should be) as they don’t get any work done, or they just don’t practice what they preach. IME, it’s usually beginners/novices who discovered what a “native” language is, like C++ or Rust, and are going through a phase. None of those people know how to actually optimize a program, haven’t even heard of Compiler Explorer, think “MESI” is a soccer player, and probably know more about TUI frameworks than profiling ones.
Yes, the concept “release early, release often” is the most practical, especially if you’re doing something new and therefore cannot fully predict how the things should be.
That is not the same. The Linux kernel project. releases early and often, but it is high quality.
Iterating in small steps is a consequence of that you usually can’t lay out all requirements beforehand. But you still need to plan architecture, determine requirements, write down design, document APIs and pre-conditions, run tests and so on. And change and adapt all that, again and again , when requirements change. (Which means that, in larger or long-running projects, requirements which are missing merely due to laziness do have a high cost.)
John Ousterhout talks about this at length in his book “A Philosophy of Software Design” (right now discussed here)… He calls that “strategic” vs. “tactical” programming.