Absolutely agree. I work in the autonomous vehicle space, specifically in creating high-assurance resilient systems, and I've had more arguments that I care to count which went something like the following:
Them, "All that extra effort sounds great, but we don't have the time to do that. It will explode the really tight build, test, debug cycle we have now. Suddenly every cycle will be 100x as long."
Me, "First of all, you should be less concerned about the length of an individual cycle and more concerned about the sum of all the cycles up to completion."
Them, "Okay, but having short cycles also helps us course correct quickly, and keeps our 'velocity' up."
Me, "Well, second of all, what good is it to be able to iterate really quickly toward an unspecified goal? How do you know that what you're doing will get you there? Or worse, how do you know that what you're trying to do is even possible or not? Maybe you're 'engineering' your way asymptotically toward an impossibilty result."
It's sometimes crazy making to have these conversations and see how wildly distorted we've allowed our incentives and perceptions become as a group of professionals. It's become more important to produce the appearance of progress and effort than it is to actually make progress and thoughtfully apply effort.
There are two sorts of developers who don't like hackathons. There are the go-to-work-and-write-code-and-then-do-other-stuff-in-the-evening sort of developers who are the overwhelming majority of the sort of devs you meet in business. For most developers writing code is nothing more than a job. Those people see a hackathon as work, and they don't like it. That's great for those people; they get code done and go home.
The second sort of developer who doesn't love a hackathon (and I'm in this group) is the sort of person who enjoys the process of writing a great piece software rather than just concentrating on the fun bits of solving a problem and getting something on a screen. I see a hackathon as literally all the worst things about software development compressed in to a single event - practically no planning, very little testing, zero documentation, no sleep, bad food, not seeing your non-dev friends, and not stepping away from the keyboard for any substantial time. I've worked on real world actual paid projects like that and it's awful. I definitely don't want to do it for fun when someone isn't even paying me for it.
I love seeing the result of other people's hackathons, and I'm glad that people who attend them enjoy them, but seriously, if you think all developers love a hackathon you really need to expand the group of developers you hang out with.
Them, "All that extra effort sounds great, but we don't have the time to do that. It will explode the really tight build, test, debug cycle we have now. Suddenly every cycle will be 100x as long."
Me, "First of all, you should be less concerned about the length of an individual cycle and more concerned about the sum of all the cycles up to completion."
Them, "Okay, but having short cycles also helps us course correct quickly, and keeps our 'velocity' up."
Me, "Well, second of all, what good is it to be able to iterate really quickly toward an unspecified goal? How do you know that what you're doing will get you there? Or worse, how do you know that what you're trying to do is even possible or not? Maybe you're 'engineering' your way asymptotically toward an impossibilty result."
It's sometimes crazy making to have these conversations and see how wildly distorted we've allowed our incentives and perceptions become as a group of professionals. It's become more important to produce the appearance of progress and effort than it is to actually make progress and thoughtfully apply effort.