In the past, I was very good at planning ahead. I often added functionality, structures, and mechanisms to my projects proactively. That part usually turned out pretty well, but I often forgot about the artifacts added on that never came to any good use. Of course, I added loads of them, too. The cost was pretty large, both in development time and in increased complexity.
Over the last few years, we've been encouraged to use another approach: "Do the simplest thing that could possibly work." To a large extent, the idea comes from the Extreme Programming (XP) movement [Beck XP]. Another fairly similar way to put it is "You Aren't Going to Need It" (YAGNI), which is a good way of helping you stay in line. I guess "Keep It Simple Stupid" (KISS) could go here, too.
Both approaches are kind of the two extremes (add all you can think of up front versus do the simplest thing), but I think they both miss something in that they don't address the tradeoffs they make. Just about every question regarding "is this or that best" can be answered with "it depends." It's about tradeoffs. I tend to prefer an approach that is somewhere in the middle, moving in one or the other direction depending upon the situation. The word "lagom" is a Swedish word meaning something like "just right" or "not too much, not too little." Lagom or "to balance" together with being context sensitive are the overall values I'd like to value, as well as continuous learning.
Let's have a closer look at a couple of more specific areas of values (architecture and process ingredients), starting with some aimed at architecture to get us into the right mood.