Comment by saghm
13 hours ago
Producing code that does what's intended. The metric is fuzzy and based on the usage of the software, not the scale of lines of code. The extent of the importance of the code itself is that I'm practice software tends not to be "one and done", so you need to be able to go back and modify it to fix bugs, add features, etc., and it turns out that's usually hard when the code is sloppy. Those needs still should stem from the sandal actual user experience though, or else we've lost the plot by treating the mechanism as the goal itself
Would my user rather have a program that works 100% in 2 weeks, or a program that works 80% in one day?
When the user needs a change made, would they prefer I spend another two weeks extending my perfect program, or throw a few LLMs at their sloppy code and have it done in a day?
That would depend on who your users are and what they're using their program for. My point is that the context of who is using the program, how they're using it, and what they're using it for are what actually matters, because most of the time, software that no one uses is by definition useless. There are circumstances where that might not apply, like code used as part of education or training (whether in a formal course or a project someone writes specifically because they're trying to learn something from the process) or when the purpose is aesthetic or humorous, but I'd argue that whatever process makes sense for them doesn't necessarily bear any resemblance given how different the goals are.
You're really asking if a user would want a program that fails a fifth of the times?
In some cases it might be better to have some crap right away and more cheaply, but even you would probably not like a 20% failure rate in most of the software you use.