Have you every heard a bunch of excuses at work to do the bare minimum to make something work? The first time I heard a comment along those lines was during my days at PwC. A senior Partner said to me: "there is no need to discuss things that may or may not happen". I have to say, this sounds like a great advice, and for all intent and purposes I try to abide by this rule. At work.
However, over the years I heard other interesting comments, including one that recently came from a senior executive from one of my clients: "you should only design based on what you know". At first, I assimilated this comment as similar to the first one. However at some point I realized the motivation behind this statement was very different. Indeed, the last comment, instructing me to design only with what I knew, was said with one primary objective: spend the minimum amount of time and dollars in building a system. At a minimum, this statement is pretty clear about the objective, and can actually be followed to the letter.
However that comment wasn't satisfying. In the context of complex projects, where many plates are spinning and decisions must be made based on partial information, this wasn't very helpful. In fact, it was most likely counterproductive. Designers must take into account many factors, including what is known (such as the system must be running 24x7), what is known to be missing (such as a field must be encrypted, but we don't know which one yet), experience (we only need this field once... right), and plain mind reading (I am the project manager, so if I tell you this won't happen, it won't.... if it can happen, it will). As a result, I will venture in saying that designing with only what we know is virtually impossible. It would require a machine instead of a human. And if I am totally blunt, it is a bit naive since applying a form a heuristics to system designs usually yields better results. So for complex systems, designers should account for future, or unknown needs, based on experience. In fact, even CPUs apply heuristics to improve speed; and they only deal with 1s and 0s.
Then, this reminded me about yet another catchy phrase from a few managers and directors I had heard over time: "let's not over engineer" and "we are not building a rocket to the moon". Unfortunately, these sentences provide absolutely no guidance. What does "over engineering" mean? And since I am not working for NASA (unfortunately) I am definitively not building rockets. So these last two sentences, unfortunately, only serve to create a sense of false security, that somehow reinforces managers' belief that they are in charge. But technically, these comments mean absolutely nothing by themselves.
But something doesn't line up correctly. All the folks that made those comments are smart. Very smart. So why would they make comments like these? Perhaps these sentences are nothing more than doublespeak. In reality, since heuristics are unavoidable in system designs, perhaps these various terms only describe the degree to which one should be predicting future needs. In fact, I would venture to say that heuristics are a form of creativity, which designers should abound; because designers without creativity are like cars without gas. So when you hear a manager say "don't build more than what's necessary", it really means "apply as little creativity as possible, but make sure it still works."
Now I know why I am working so much after hours. I need to unleash that creativity. Don't you?