You’ve missed the point completely. If they are relying on quick turnarounds, they are likely just TRYING THINGS instead of THINKING about what to try. And, likely don’t ask themselves why a particular change fixed a problem – they just move on to the next with the same approach.
If they don’t understand the particular problem they are facing in sufficient detail to be able to formulate a REASONED solution, then what faith do you have in that solution? How do you know they didn’t just stumble on something that APPEARED to work?
When “trying things” takes a long period of time (consumes a lot of resources), you are really careful about what you are willing to try – without substantiation – as it will limit the other “trials” you will be able to make.
I worked on a project for IBM many years ago. We (they!) used a minicomputer to exercise a piece of equipment that we were building (not designing!) for them. There was a problem with the communication hardware between the two systems. I opined that it could be a timing issue as there were a lot of cascaded timing elements in the chain.
The IBM engineer who had designed the interface assured me that couldn’t be the case. And, spent much of his time (which is also MY time as I can’t get any work done until he is out of the way) looking for another problem source.
Eventually, I goosed the timing by a few thousand percent (so a millisecond event took a full second… big deal!). And, voila – everything started working!
“What did you do?”
“I tweeked the timing – as I had suggested”
“To what?”
“Two orders of magnitude.”
“What??? That’s way too much!”
“Of course. But I didn’t want to wonder if 5-10% would be sufficient and knew that there was no downside to going WAY overboard…”
He wanted to bury his head in documents with the expectation that reality agreed with theory. I saw that it clearly did NOT and devised a simple, harmless test to validate my theory. Then, when proven, went looking for the detail that explained why this had been necessary.
A “modern programmer” would have goosed the timing and moved on to the next problem without ever going back to figure out why that solution APPEARED to work.