The comments about Ballard's code is very subjective. But if we take their comments at face value:

> which would not be well-factored and would impede someone less talented from comprehending it or being able to change it effectively.

Except the community did comprehend it and changed it effectively. Ballard hasn't maintained ffmpeg nor qemu for 20+ years.

> I guess I'm saying there are code quality concerns which do affect velocity/maintainability and then there are superficial and stylistic issues. The former aren't just about some kind of beauty standard, they're part of executing.

Which is why I'm saying we're basically arguing the same things. For a POC you get more velocity when focusing on proving that idea. I'm not saying zero effort should be spent on architecting the code. Just that you don't always know how best to organize it until you've had several revisions so developers shouldn't get too caught up trying to intellectualize the best internal layout. That can grow once the problem is better understood.

And I made this point because I felt the comparisons of one engineers POC to another engineers commercial release was unfair. They're completely different ends of the factory.