Dinner Talk

Just because something’s been done a certain way in the past doesn’t mean it should continue.


By Jon McDonald
Recently at dinner we were discussing a new video game my son wanted. My wife and I were less than thrilled with the game due to some of the adult themes I had seen in the reviews. As my son was trying to convince us that it was an acceptable game he fell back on the old standard justification: “All my friends are playing it!”

This is one of the poorest reasons for anything, as far as I am concerned. In my mind it’s an indication of cowardice or sloth. Either you’re afraid to present the real reasons or you’re too lazy to come up with defensible arguments. I tried to explain this to my son in a somewhat gentler way, but still trying to get him to understand the issues.

After dinner I was thinking about the reasons I hear for selection of a particular architectural alternative. By far the most common justification is, “That’s the way it was done on another project.” I realized that this sounds suspiciously like my son’s justification. To be fair, in the past “prior experience” was a very effective way of making the decisions. It was often too expensive or difficult to analyze alternatives in any meaningful way. Basing a decision on something that worked in the past was often the most reliable path to success.

With the current state of system-level design, I think we’ve crossed an inflection point. It’s no longer defensible or successful to continue with an approach simply because it was done on another project. The cost of failure and the margins required for a successful project require a more informed understanding of the implications of our decisions. Today I can characterize my architecture and make reasonably accurate predictions about the functional, performance and power implications of my choices before I commit to the implementation. Given these capabilities, relying on the reasoning that “they did it this way before” is getting to close to my son’s justification. The reasons behind it are driven by fear of change or lack of willingness to invest in quantitative analysis. It’s a nicer way of saying it, but it still comes back to cowardice or sloth.

Think about it on your next project, what are your preconceived notions, what are the assumptions you assume to be true because they were in the past? If something is being done just because “it was done that way before,” is it really too difficult to test that assumption? Could an investment in system-level analysis enable the project to make more informed decisions? Ultimately the better we understand the implications of our decisions the more successful our projects are likely to be.

–Jon McDonald is a technical marketing engineer for the design and creation business unit at Mentor Graphics.