Design Only Based On What You Know?

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?


Print | posted @ Thursday, August 26, 2010 8:58 PM

Comments on this entry:

Gravatar # re: Design Only Based On What You Know?
by Ray Almonte at 8/27/2010 6:31 AM

Interesting debate. Agile proponents insist the you only build what you need. If later requests require refactoring or redesign, you do it then as part of the new request or project. The argument against this is that architecture should be robust & be designed to make future expansion & maintenance easier.
I think that as far as features go, build only what you need. For system/database architecture, spend a little time designing a robust architecture.
Along with all of that, remember that you always bring your own knowledge & experience to whatever you do, & that you'll never be able to predict every future situation or request, & that for the most part , you don't know what you don't know.
Gravatar # re: Design Only Based On What You Know?
by Herve Roggero at 8/27/2010 1:44 PM

Thanks Ray for your feedback. Meanwhile I thought of other interesting comments, along the same line:

-> We don't want a Lexus
-> We just want a Yugo
-> Keep it Simple (KISS)
-> I just want a working prototype

And on and on... :)
Gravatar # re: Design Only Based On What You Know?
by Phil Cutajar at 9/25/2010 6:33 PM

Great discussion. I have been subjected to these comments, and I must admit I have used some similar ones myself. The urge to design based on heuristics and general experience is what separates an good experienced architect from a junior engineer. In fact, this is something I actually look for when I interview candidates. However, there are situations where cost is a higher priority than being robust, adaptable and future proof. This is where I think some of these expressions come in, because sometimes we need to override our natural tendencies. I have found over the years that good architects bring their wealth of knowledge and experience to every job they do. These good architects are also ones that have seen their solutions taken well beyond what they designed them for, and they all know that someone years from now will look at their work and wonder why they did or didn't do this or that.

So, while I am a proponent of designing in a way that makes the solution robust, adaptable, maintainable, and suitable for extensibility, I also know that imperfect solutions are often more successful than more elegant, robust and superior designs. We see examples of this all around us, and we see these market forces often reject the superior product, such was the case in Beta vs. VHS, PC vs. Mac / PowerPC, and so on. Sometimes, timing, cost and other forces that have nothing to do with the solution design are more important than the quality and elegance of the design.
Comments have been closed on this topic.