What are the support costs once the software is shipped?

What is the design?

I consulted for a large manufacturing firm building an application to track the logical design of a very complex product.

They modeled the parts as objects. No problem.

I was stunned to see the following pattern throughout the code base:

  Class of the object

  Instance #1 of the class

  Instances 2,,n of the class

I tracked down the Mechanical Engineer (PhD) who designed the logical parts model. He desk was, in fact, 100 feet away from mine.

I asked him what he intended, regarding the model. He responded "Blueprint, casting mold, and manufactured parts." - which I understood immediately, having studied engineering myself.

After telling him about the misunderstanding of his model by the software team, I asked him what he was going to do about it. He responded "Nothing."

I went back to the software team to explain the misunderstanding and the solution (i.e. blueprint => metaclass, casting mold => class, and manufactured parts => instances). The uniform response was "It is too late to change it now."

The result is a broken model that was wrong for more than a decade and may still be deployed. The cost of the associated technical debt is a function of 50+ team members having to delineate instance #1 from instances 2,,n for over a decade.

N.B. Most of the software team has a BS (or higher) in computer science.

P.S. Years later, I won't go anywhere near the manufactured product.

We learned how government and justice worked.

I'll take that deal any day!

* LLMs don't understand the syntax of q (or any other programming language).

* LLMs don't understand the semantics of q (or any other programming language).

* Limited training data, as compared to kanguages like Python or javascript.

All of the above contribute to the failure modes when applying LLMs to the generation or "understanding" of source code in any programming language.

There should be no expectation of a "correct" translation to any programming language.

N.B. Formal languages for specifying requirements and specifications have been in existence for decades and are rarely used.

From what I've observed, people creating software are reluctant to or incapable of producing [natural language] requirements and specifications that are rigorous & precise enough to be translated into correctly working software.

What happened in the last 50 years to move that number down by a factor of 10 - literal decimation?

* Wood shop

* Metal shop

* Cooking

* Sewing

* Typing

I never saw an injury.

Learning to work with our hands safely was quite valuable.

The hardest part about writing software is the requirements & specifications.

Some ambiguous thoughts rendered as an LLM prompt is neither.

The output will only be as precise as the input allows.

Prior to the federal income tax (1913), all federal government expenses were covered by duties, tariffs, and levies.

A sorted array of bit locations would represent a sparse bit set well enough to start, with O(N) storage and O(log N) access. Once the sets became large and/or dense, another data structure could be considered.

First, use an array. If an array doesn't work, try something else.