Code is not literature. It's not poetry. It does not express the human spirit. Code is a machine made of symbols. Engineers do care about the beauty of their machine designs, but in the end what matters is whether the machine performs its function correctly, efficiently, affordably. What's wonderful about software is that the function of software is to take input data and produce output data. Every aspect of it is measurable, if we build it to be measurable, because it's data all the way down. The future of software development is not reading code. It's specifying an outcome, success and failure conditions, and iterating until that outcome is reached. Throw out your software engineering "code quality" manuals, your SOLID and your Clean Code. It doesn't matter now.

▲

krupan 6 hours ago | parent | next [-]

This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages

▲

efficax 6 hours ago | parent [-]

You build your outcome conditions and specifications in code as well. And you iterate on them too. I'm not talking about waterfall development. It's something else. You can spend a day just prototyping, spiking, experimenting, and then use that to refine what the outcome can be, doing more work that way than you could in a week before. I think it's crazy to think that software development processes aren't going to change.

▲

skydhash 6 hours ago | parent [-]

Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome.

That’s why we read code. Because only there the correct and incorrect cases are clearly separated.

▲

efficax 4 hours ago | parent [-]

But that's just more data. Create the error conditions in your test harness and exercise them. The machine will tell you what happened. Then correct the machine.

	▲	krupan 2 hours ago \| parent [-]
		You make it sound so easy. Have you ever worked in QA?

▲

tauroid 5 hours ago | parent | prev | next [-]

> if we build it to be measurable

I.e. if by its structure we can conclude that our test cases are sufficient. Because if we don't know its structure then we don't know there aren't undisclosed sub-partitions of (combinatorially exploded) test space where it breaks.

How do we know its structure? By specifying it. How do we do that in enough detail? Code. Or we use static analysis I guess. Which is harder.

▲

prmph 3 hours ago | parent | prev [-]

I could not disagree more.

I can't even fathom how someone can say this with a straight face. Judging by the absolute garbage (architecture-wise) that the frontier models put out, I pity anyone taken in by this sort of thinking. They regularly tie themselves in knots and dig deeper holes for themselves without my intervention.

Software is exact; its maths. We would not tolerate a machine that operates on the basis proving/applying theorems right like 60% of the time. How we think this is suddenly acceptable in software engineering baffles me. CVEs can kill people, bad software can cause severe harms

But maybe I should not be on here arguing about this. I should be out there working on how to profit off such fundamental misunderstandings.

	▲	efficax an hour ago \| parent [-]
		the model does not make the architecture decisions, you make the architecture decisions. you define what success is, including performance characteristics. fuzzing and property based testing ensure correctness. what does it matter what the code looks like if it the machine you've created fulfills the criteria you define?