http://rcm.amazon.com/e/cm?t=marklindseyna-20&o=1&p=8&l=as1&asins=0393731332&md=10FE9736YVPPT7A0FBG2&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr
In a previous post, I discussed some thinks I learned from Dr. Mann’s book, Time Management for Architects and Designers. In this post, I discuss a few other things I learned.

The Avant-Garde Trap

Mann mentions that some designers can tend toward using cutting-edge designs, or that clients want these avant-garde designs. But sometimes, a designer might do something and a customer perceives it to be avant-garde, and the customer may protest. Reading this really helped me understand why I got so much resistance to a particular design I often apply: public IP addresses on Internet servers.

I often advocate for using real, genuine public IP addresses on servers that will be accessed from the Internet. Some of my clients think this is wasteful and possibly dangerous, but they eventually build static-NAT mappings through their firewall to accomplish a similar purpose. Some people confuse using NAT with using firewalls.

For me, using public IP addresses for Internet servers is as old-fashioned as FTP. But for my clients, it’s crazytalk fancy. I realized that I needed to approach this differently; I shouldn’t assume that clients would bow to my old-fashioned design as “traditional”, because it’s not the common design they know.

Sometimes the popular, cutting-edge designs don’t fit. For example, to be considered a competent network designer in 2008, you have to use MPLS.[1]

Self-Inflicted Distractions

On p.53, Mann reminded me of something I keep re-learning:

[B]ackground noise should be so unobtrusive that you actually forget it’s there when you are focusing fully on the work, and only become aware of it when you are taking a break.

Other people, or machines, are one source of noise. But music is one that I sometimes do to myself. I keep learning that I may like music, but it actually works against me when I need to focus.

Work Time Chunks

Mann makes a good point about work time chunks (p.58): you need to plan to work chunks of time that match your preferences, and your attention span. Dr. Brooks at UNC-CH also discusses this in his seminar Professional Practice in Computer Science.

For example, if you like to work on one task for at least two hours, then don’t schedule a new task to start every 90 minutes. Or if you prefer to work on one task for only 15 minutes at a time, then don’t schedule two hours of work on it.

Wicked Problems Abound

“Most nontrivial design problems are ‘wicked’ to some extent . . . no solution can be claimed to be the ‘right’ answer or the ‘correct’ solution for . . . any design problem.” (pp.66-67). Truly wicked problems “have no definitive problem formulation”; the more you work on them, the more likely you are to have a good solution; “have answers that are ‘more appropriate’ or ‘less appropriate’ rather than ‘true’ or ‘false’; and among other things “do not allow for trial and error”.

This has really helped me in the past year; I’ve had a number of interesting network and software design problems. My old tendency was to attempt to give the “right” answer, but then I chafed knowing there were downsides to that “right” answer. I have learned that there are always pros and cons in design problems. No decision is without gains and costs.

Ought Questions: Should we install a new Call Agent Cluster, or not?

From page 73:

A question such as “Should the building be located on a part of the site that has pipe clay in the soil?” relates to what the world “ought” to be like. This kind of quetsion is really the quintessential design issue. . . .”We settle such questions by discussing the merits and drawbacks of design proposals — a process that involves debate, getting information and opinions from peple affected by similar problems, weighing the pros and cons, evaluating procedures, and using “political” decision-making methods such as voting. The position we decide upon may be a “yes” or “no,” but this does not mean that one is right or true and the other is wrong or false.

Learning this has helped me immensely, because I used to labor under the assumption that I needed to make the right recommendation, and that other ideas were wrong. I believe in right and wrong — Universal Truth, and a personal God who makes the rules. But I’ve decided that there’s no Universally Right answer to the question of whether to use the Active Copper Pass-Through Module or the Passive Copper Pass-Through Module.

I wish some of my colleagues could learn this. We tend to make a recommendation, then get committed to it as if it’s a personal matter. Then if a client decides not to follow our recommendation, we conclude they really don’t want to make smart decisions.

Parallel Processing

Mann recommends keeping separate files for separate components of the project. For example, you have one file on the Problem Statement; another on the Information Search, and another file for Developing Solutions, and another on the Recommendation. Then you work on all the parts at the same time, rather than assuming they have to be done in any specific order. I think this says that Design is really a knowledge-gathering activity. You put your best, latest information in each file, then work on the problem until you run out of time.

Take Charge of Time Estimates

Because design problems are somewhat wicked, and you can continue working on them forever without ever arriving at a “final” answer, you have to “adopt the habit of [taking] “charge and replace guesswork [time estimates] with decisions about how much time you are able or willing to devote to a task.” For example, if you just want my recommendation about the best software to use as a carrier email server, I can give you an answer in 30 seconds. But if you give me an hour and tell me you’re planning to service 40,000 subscribers, I can give you some better analysis and information on the requirements. If you give me a few hours and tell me that thousands of recipients will be receiving copies of the same attachment, and that attachment is several hundred megabytes large, then my recommendation would change.

On the other hand, there is a minimum quality I’m willing to produce. If you want me to produce a network design diagram in 5 minutes, I may be able to throw together something, but it likely won’t have much detail. It may be OK for a whiteboard discussion, but it’s probably too poor to distribute as a deliverable.

[1] One VRF per residential client, anyone? Maybe if we work hard, we can make provisioning even more messy! I’ve seen telecom networks implement MPLS VRFs when all they really needed were subnets. In another case of MPLS planning, a telco paid extra for MPLS, but it turns out MPLS can’t be used with other features they needed on their chosen hardware platform.