The rules don't change because of the scale or timelines. You still iterate, from the smallest poem to the largest moonshot, but on big pieces of work, you iter

The rules don't change because of the scale or timelines. You still iterate, from the smallest poem to the largest moonshot, but on big pieces of work, you iterate the most on the abstract bits of groundwork principles and process so that you can deliver good, detailed and coherent specifications when you go to delegate the work. "Man on the moon" was thousands of years of scientific iteration, followed by about a decade of focused engineering. What the article rails against the most is blind iteration, the "make it fun," or "make it pop," "just change this one thing," type of vague sentiment that critiques but doesn't really direct. Blind iteration happens because the leads(or even on a solo project, the author as lead) ran out of templates to follow, and when you run out of templates you have to begin using trial and error to get results. But it's immensely cheaper(to the point of it being required in many types of project) to focus trial and error around finding a new template with better, clearer rules, than it is to send the order to make something to finished quality and then decide that it won't work and start over. However, the latter tends to happen every day, in all sorts of scenarios, from a poorly considered dinner plan to high-profile software projects.