My 4-year-old son loves dinosaurs. He draws them, he pretends to be them, we read about them, we tell stories about them, and today we even we ate pancakes shaped like them. Many contemporary children's books on dinosaurs include types I'm sure I never saw as a child, such as carcharodontosaurus, deinonychus, and one of my favorites, therizinosaurus. My son could also tell you—since it comes up a lot—that there really is not such a thing as a brontosaurus. Turns out, what was called "brontosaurus" was really an apatosaurus, and since the latter name had historic precedent, it was the one that stuck.
Yet, in our family furor for all things dinosaur, we frequently find references to the brontosaurus. My first reaction to such occurrences is usually, "Why don't they know better?" A good follow-up question is, "How would they?" That is, why would the designer of, say, dinosaur-shaped pasta even think to investigate whether or not there really is such a thing as a brontosaurus? Second-order ignorance remains the malady of the ignorant.
My son's love of drawing recently blossomed, and it was initiated by a visit from my father—who, I should mention, is an excellent artist. My dad got my son into drawing, unlocking what must be an artistic skill and passion that skips generations. However, every time my dad drew a tyrannosaur, it was standing upright with its tail on the ground. These were fine drawings in their own right, but they also happened to be wrong. How would my father know that his archetypal dinosaur's posture is scientifically passé?
I was idly considering dinosaurs this morning when an analogy popped into my head: teaching children about brontosaurus is like teaching novice software developers to do Big Design Up Front (BDUF). For years, the status quo assumed software development was like manufacturing, and hence one can measure productivity in man-hours and lines-of-code. As long as you design it right from the beginning, all will go well. Of course, as far back as the 1970's, Fred Brooks was predicting agile methods. Despite the popularity of his essays, I have seen little evidence of their impact (q.v. the CHAOS report) until relatively recently, as "agile" is less frequently used as a profanity. From a modern perspective, we know that software development is the process of learning how to develop that software. By necessity, you know the most about a system when you have finished building it. This is why you always feel like you could do it better if you could do it again, or why you should always build one to throw away.
I look forward to a day when software engineers take a page out of modern children's dinosaur books: any time BDUF is mentioned, there's a an explanation that well-meaning people used to think it was a good idea, but now we realize that its really just a shadow of iterative and incremental design processes. The positive side is that I don't foresee BDUF-shaped pasta ever being included in Software Engineer Mac & Cheese.