Hacker News Reader

Comment by boomlinde | Hacker News Reader

The person they responded to refers specifically to "healthcare, finance, automotive, defense, power plans, aviation, manufacturing", areas where I'd at least hope that we aspire to understand what the code does.

View on HN

Also software like SQLite:

" SQLite is built using a DO-178B-inspired process. The testing standards for SQLite are among the highest for commercial software.

SQLite is open-source but it is not open-contribution. All the code in SQLite is written by a small team of experts. The project does not accept "pull requests" or patches from anonymous passers-by on the internet. "

https://sqlite.org/hirely.html

https://sqlite.org/testing.html

I worked briefly in heath care and the code is so brittle and so poorly understood that almost everyone is afraid to touch anything and instead it's just layers and layers of stuff trying to patch around existing code.

I know this is true. But I don’t think “Some parts of important codebases are black boxes. Therefore it’s fine if all of that code base becomes a far bigger black box” sounds like a good argument.

Also, there was probably some human at some point that had some understanding of what they were trying to do and why. The black boxes generally get programmed around after they long left but at the time they had bugs ironed out over decades. (Yes I know sometimes true slop is done over a short period of time and the programmer leaves. But I’ve generally seen the black box built over decades instead).

I worked briefly in aviation and the part I've seen was very understandable and easy to extend and modify in understandable way. Some parts were hard, but by necessity. We also had very good tests. But maybe that one software was just a good exception.

In many codebases when you see this happening it is because someone reported a bug and the dev fixed the narrowest instance they could. Typically if(some specific case) do_fix() else do_normal(). Over time this fragments meaning in the source and makes it harder to reason about until it is a giant pile of slop.

The thing the dev should do that often doesn't get done is to take the information about the undesired behavior back up to the design/spec level and rework the definition to account for it. This doesn't normally get done because it takes longer and it is conceptually more difficult than the patch.

This is something that LLMs can accelerate significantly and the result is a shallower gradient of technical debt over the long term.

> back up to the design/spec level and rework the definition to account for it.

> his doesn't normally get done because it takes longer and it is conceptually more difficult than the patch.

This usually isn't done, because design/spec no longer exists.

Sometimes this also happens because the design/spec never existed, but hopefully not in the industries under discussion.

Having worked in software for healthcare, defense and finance I guarantee you we don't

Do you agree that this isn't a desirable state of affairs?

I have also done those three and we definitely did!

TLA+

TLA+ ensures your model is correct, not that the code is correct

Healthcare has featured many a time on thedailywtf, because a lot is (or at least was) written in MUMPS[0]. An example: https://thedailywtf.com/articles/A_Case_of_the_MUMPS

[0] https://en.wikipedia.org/wiki/MUMPS

I worked for a reinsurance company and their main pricing tool is a huge brittle excel file full of spaghetti VBS code. And yet, they manage to underwrite billions.

When the derecho came through Iowa and many businesses were out of power for up to multiple weeks, the very large organization I was working for at the time in the insurance space got to discover just how many of their processes relied on machines sitting under people’s desks. Business critical servers and processing just chilling on a PC under someone’s desk. Also tens of billions of dollars in revenue a year.

Reply on news.ycombinator.com