我在房子周围一直是我做圣诞大餐的悠久传统。我喜欢做饭，但不要有时间做我想要的经常做。我的妻子每天都在做大多数烹饪，因此她喜欢不必应付圣诞节盛宴。
I approach the preparations like I would an engineering project. Recipes are selected, ingredients and quantities go into an Excel spreadsheet, and a categorized shopping list is developed. When the ingredients are brought home I sort them into groups on a table with a printout for the recipe under each group. Cooking schedules are worked out to optimize stovetop and oven availability, temperatures, and pot sizes.
像大多数业余厨师一样，我仔细测量了我的食材。我经常对食谱进行修改，从一次到下一次（将山核桃派的烘烤时间增加15分钟，在Waldorf沙拉中加一点橙汁，在前一天晚上煮奶酪砂浆，以便他们牢固一点），但是当动作开始时，我严格遵守指定的测量和温度。
Have you ever watched a master chef work? There’s surprisingly little measuring going on. He or she knows the ingredients intimately, how their flavors interact, how temperature affects them. For the master chef, cooking is an art. For me, it’s an exercise in accurately quantifying components to get an expected outcome.
My Christmas dinner is predictable and consistent. It’s not art, but it tastes good.
Unlike cooking, when we design or operate a network we don’t want a “master chef” that is striving for something creative and exciting. Excitement is seldom a good thing in networking. We want predictability and consistency. We want quantification, not art.
Yet all too often we encounter people who claim that certain aspects of network design are “more art than science。” What those people are really saying is, “I have no idea how to quantify what I’m doing.”
The inability to put numbers around a networking project makes life difficult for us in a number of ways. How can we do a useful cost/benefit analysis of the project if we cannot quantify the benefits? How can we do a risk analysis if we can’t quantify the risks? How do we “sell” the project to upper management as an improvement in reliability, security, or performance if we cannot explain reliability, security, or performance with numbers? Even cost is not always quantified as accurately as it should be.
以简单的更改请求表为例。其中大多数都有标题为“风险评估”或其他效果的部分，在大多数情况下，所有这些都包含的是您必须以1至5的规模评估风险。也许还有一个区域可以简要介绍您认为风险可能是什么。这种主观评估几乎从来都不是有用的，通常在那里，以便负责变更管理的人可以说他们至少询问了风险。
The vagueness and hand-waving that accompanies so many network project proposals can cause the CFO to view IT with a great deal of mistrust. Here’s a guy whose life revolves around numbers. If you go to him asking for a few million dollars for a new network project but cannot make a case – backed up by believable data in the language the CFO understands – for why those millions of dollars are a promising investment rather than just a cost, you are less likely to get your project funded.
For that matter, do you yourself know that the project will be worth the cost, even before you go to the CFO and swamp him with technical jargon and fuzzy claims that the project will improve network reliability/security/performance?
In the next few posts I’m going to write about how you can quantify things you might have thought were not measurable, how to better assess risks and benefits, and how to put numbers around your project proposals that will get the attention and support of the boardroom. I’m not going to torture you with Bayesian probability or stochastic simulations; I’m going to write about the sorts of questions you should be asking yourself in order to make a concept quantifiable, define a means of measuring it, and reducing the uncertainty around the concept.
But for now, I’ve got to go brine my turkey.
Merry Christmas!