Software runs the world, and there are two kinds: disposable code and durable code.

[usonian]

Posted in GD for general education of non-computer junkies.
https://www.honeycomb.io/blog/disposable-code-is-here-to-stay

Background:
Lately, AI is being used to write code quickly, but you sometimes get different code each time you ask, and commonly used functions are basically reinvented each time, whereas "old" coding puts those functions into known and well-tested libraries that anyone can call up and be sure of the same accurate result.

We used to do "rapid prototyping". Cooking up short programs on the spot to do a job and say goodbye to them,
One job I had was to create a variety of plots of experiment data. Once the experimenter was done plotting data for the device under test, it was never used again. Neat thing for me was that once I delivered it, he never asked for any fixes. It just worked. Sometimes, you win.

Disposable code vs. durable code

The uses for disposable code have exploded since ChatGPT was released: design mocks, experiments, data processing scripts, exploration, prototypes, hobby apps, and more. You generate some code to do a thing, you do the thing, you throw it away. Generate ten thousand variants and let them fight it out, if you feel like it. It’s so cheap and easy, it feels like magic.

And then there’s the code that we rely on for bank transactions, package deliveries, medical results, satellite launches, airline flight paths, self-driving cars, mortgage payments, and nuclear power plants. This is durable code, and it’s going to stay that way.

Durable code is used when the stakes are high, the losses are material, the ripple effects of failure or performance changes throughout the system are complex and unpredictable. Highly regulated industries require durable software. From a risk management perspective, people need to be able to read the code and understand the system, so they can follow the money or respond to customer complaints, hundreds or thousands of times a day.

Here’s one (unscientific) rule of thumb: the lower on the stack you go, the closer you get to laying bits down on disk, the more dependable and predictable our software has to be. Databases and operating systems will be durable code til the stars die out.

And a big point: The cost of software is defined by its maintenance

Durable code runs important, critical stuff that needs to be validated, updated and maintained. And maintained by people who are new and didn't write it, so the code has to be documented, so that new people can understand it before changing anything.

Disposable code is basically run once or a few times, and never need it again. It can be sloppy, and in the real world,m it can choke on unexpected data, because you never run into it.

I hope this helps explain some of the "magic" you hear about software.
Only an irresponsible jerk would play fast and loose with software that lives depend on..

[LearnedHand]

1. What makes durable code "durable"?

I mean, what are the standards and/or certifications that say this right here qualifies as durable code and can be used in critical systems?

[Bernardo de La Paz]

3. There are many certifications but they apply to only a small part of software.

Usually things like transfer protocols, the seven layer stack the Internet runs on, storage protocols, language conformity, etc.

A big program like Photoshop will not be "certified" as a whole, but pieces will meet certified standards. Like it will use international standards for colour spaces, JPEG/PNG/WEBP image standards.

But properly, professionally written code will have a large test suite to pound the shit out of low level routines, and large test programs to test integration.

I'm getting the feeling that AI as used for coding these days is neglecting somewhat the testing side of things. I don't read much about that. I will have to get me a brick computer just to run AI on and check some things out, a computer separate from my own use, one just for AI work. I don't trust AIs on computers; who knows what they might get up to, like analyzing the entire drive.

[LearnedHand]

5. Got it, thx!

I figured it was something more formal than just “hey this is durable code” but didn’t know enough about it. I’m not a coder but work with people who do scientific coding, and they have a principle called “sustainable software.” I wonder if that is related to durable code?

[Bernardo de La Paz]

9. I think "sustainable software" is unrelated to durable code.

It is more about climate and nature sustainability, particularly focusing on reducing energy consumption. So like maybe using a much smaller neural net inside the device than jumping into the cloud for a data center run.

Maintainable code is more a part of durable code. Programs that live, that are used frequently over years, are modified frequently. Bugs are fixed, new features are added, code is modified to conform with local regulations in some country or other.

[Bernardo de La Paz]

7. Critical systems, like airliner avionics, have much higher standards and support but I don't know about certifications.

I think major airlines (to pursue the example a bit) would have programmers embedded at certain stages as extra eyes for everyone's benefit from architecting on up. Airlines would develop software certifications of their own (and might have industry standards) just like the hardware (wings, engines, etc) would have complex and thorough inspection and testing all the way through fabrication, manufacturing, and assembly.

There are many critical applications and security needs to be better addressed for things like utilities, school systems, and medical networks.

[Tetrachloride]

2. the other day, i heard that legacy code cannot be converted to modern code by AI

because the documentation for the legacy languages is incomplete.

[Bernardo de La Paz]

4. I don't think that is true, and even so there are several ways it could do it or be used in the process. . . . nt

[Bernardo de La Paz]

8. More detail (my speculation)

The really important old languages would be back-documented and old hardware simulated. I'm sure you could run multiple whole IBM 360 computers (from the 60s, and 370s from the 70s) on your laptop.

What generative AI (the current level) does is make things that would generate the prompt if kinda run in reverse. So prompt engineering is important. You don't just specify "build me a Java program that does what this 50 year old program does". You have to specify certain example inputs and outputs (test cases), specify that it use and interact with particular versions of libraries of code and database formats / query languages, etc. You can't really do that on a grand scale, but the more granular the pieces the easier they become. Pieces have interfaces with other pieces of code and those can all be specified in the "prompt".

Also, converting large old important programs is more than just running a stream of code through a magic translator. This is because interfaces, libraries, databases, and files have changed. As has programming knowledge. The Java libraries overlap the COBOL libraries only partially. Modern libraries and databases can be much more efficient but that requires refactoring code to take advantage of it. Data may have to be presented in novel arrangements.

Whereas an old DMV program might have wanted input such as for names in all CAPITAL letters with no punctuation and dead simple roman letter symbol codings, modern software can and should accommodate multi-lingual names and data with accents and cedillas and diacritical marks and dingbats. That has ramifications through the depth and breadth of the code.

[Bernardo de La Paz]

6. Your insight about the distinction between durable and disposable code is a good one.

I'm familiar with both kinds but hadn't really thought much about that aspect.

One place they interact is in agile coding shops. In agile mode, one writes a lot of code and rewrites it and throws parts away that end up not needed and throws important parts away so they can be written again from scratch. Code should not be thought of as precious per se, but code that has survived multiple revisions and extensive testing has to be respected.

Disposable code is also applicable as a concept to bootstrapping a program (different from bootstrapping a computer, which is essentially one long run of the operating system program). Bootstrapping code is where you get bare-bones functionality working on grossly simplified versions of files and tasks. This gives you a few big things: 1) A working version that does something, however pitiful. 2) Greater understand of the task and the plan, 3) Basic scars and wounds from the first bugs encountered. Then you modify pieces of the code the make it do more things, deal with more events, and break less often.

The more code I write the more agile I find myself tending. Countering that, as the program grows, the more careful and tentative I become with making changes. There's a lot to be said to modifying a program bit by bit to keep it cohesive. But sometimes redesigns are needed to straighten out kinks in the code, reduce code smell, make it less brittle, and make it more understandable (and hence maintainable).