In late 2007 I got frustrated, again. I was getting some work done, but it seemed like I ought to be getting more done. It ought not be so stressful. I shouldn’t have this nagging feeling that I’m not working on the most important, or urgent task at the time. In the past, I’ve described a sort of work-management-maturity model. Down that the bottom of the scale, I’ve got work to do, but I’m not getting it done. I felt like I was spending too much time there.

I found this book, “Time Management for Architects and Designers: Challenges and Remedies”, by Thorbjoern Mann, on Amazon. I always aspire to be compared with architects, industrial designers, and hard-science engineers [1]. But does this book really apply to me? Mann mentions this on p.10:  “Design” is understood here to apply to many fields besides architecture; it is “an activity aiming at the production of a plan whose implementation is expected to produce a situation with certain desirable properties and without undesirable side- and aftereffects” [2]. I do this when I’m writing software, and when I’m planning computer (and telephony) networks.

By the way, Software Design has borrowed a major concept from Architecture before: Design Patterns.[3]

Mann uses lots of examples from architecture, but many of his points on time management apply to Software Design and Network Design. There are fundamental factors in “design” that make “time management” tricky, he argues. 

A designer must focus on his work. Distractions are evil [4]. Mann mentions that even a two-second interruption can take a full minute, maybe more, to recover the level of focus to return to work.

From p.29, Many people don’t allow themselves to see the discrepancies between their work requirements and their preparations until too late. This results in delays, frustration, and mistakes. Make a regular habit of brushing up on the skills and knowledge needed for your work. For example, if you’ve never parsed XML, and you know you’ve got a project coming up that requires writing an XML parser, then you may be in trouble if you discover this in the last hour before the project is due. Or, if you know you’re likely to need to plan a network with two links to the Internet, be sure you take the time to figure out how this is done before you get into a time crunch.

A designer’s attitude can create problems too. From p.32, Many architects see projects as falling into one of two groups: “great architecture” . . . and lowly “bread-and-butter projects”. . . . The difference is your attitude. You can look at each project as an opportunity to be creative, solve problems, please the client, manage the project skillfully, and make great architecture, or you can view it as another dull bread-and-butter project full of drudgery and embarrassing compromises. Mann makes an excellent point here. For example, in network design, it’s easy to think, “Oh, this is just another customer premise network” or “yet another walled-garden VoIP-core network”. But every project has an opportunity to fail; therefore there’s an opportunity to succeed. Every project is an opportunity to explore a new technique [4] [5].

Mann suggests a neat idea to help with the attitude problem. Write a statement about the project you are working on, reflecting a positive attitude: “This project is a great opportunity to . . . “. Hang the statement on the wall . . . then act “as if” it is true. For example, “The voiptelco.com network design is a great opportunity to provide sub-second fault recovery”.

Fear of embarrassment or of failure can impede design progress. In software, fear of building the wrong thing — the thing that won’t accomplish what’s needed, or will leave out some key capability, or that will be difficult to maintain — can keep you from starting. My good friend and respected colleague Chris Vaughan [6] and I have worked together on some software projects where the list of requirements just kept growing, and all the constraints on the software design were just massive. Software can be nasty like this.

Don’t wait for the great idea or the complete, deep understanding of the problem. That will come along the way; just get going. One “baby step” is all it takes. (p. 33) This is excellent advice. I’m learning that excellent designs don’t spring fully formed from great minds; even Leonardo da Vinci practiced his drawings; Unix has evolved heavily since its inception; the original IP networks would collapse when used heavily and had to be modified to keep them running [7].

Mann also suggests an idea that seems interesting, but I don’t understand it fully yet. Another way to overcome fear of making a fool out of yourself is to deliberately set out to explore all the biggest blunders one might commit for the project.  . . . It contributes to your understanding of the problem, it helps you to think “outside the box” while clarifying just where the boundaries of the box are . . .

(p. 33)  This seems like you’re designing the “complement” of the problem, or sort-of deconstructing the possible working designs. I’ll have to think about this more, or try it.

In CS 140, my second software development class in college [8], Dr. Boyd  assigned us a really fun game project. I could definitely implement what was needed to the project, but I wanted to do something fun. We had a couple of weeks to do it. I wanted my program to support a mouse, and I wanted to represent the game board using a bitmap instead of the ordinary two-dimensional array of booleans. I thought about it for a while, and finally got started in earnest a couple of days before it was due. Then I realized how much there was to do, and I realized that the basic problem (the one I thought was so simple) actually had some complexity. It was harder to read from the mouse than I thought. While I normally finished my projects the evening before they were due, this one was far from complete by 10pm the night before. I was over-confident.  From P.34: Overconfidence can lead to procrastination: “There’s no big hurry; things are under control.” Then as deadlines approach, you retreat into a kind of arrogant defensiveness. . . . Another result of overconfidence is misguided self-reliance: the sense that the problem can be resolved without other people’s input. 



I tend to bump into this problem; over-confidence expresses itself as scheduling work at the last possible minute. This is easy to do, and even encouraged, because other tasks are available to work now. Then I end up doing the work, and realizing that I really did need input from other people.

Mann introduces the idea of a “preconceived idea” or “pet idea”. Designers quickly develop an initial, intuitive vision of hat the solution will be: a preconceived idea. This is natural and okay — you wouldn’t be a designer if that didn’t happen. But progress can get derailed if you uncritically barge ahead with such a pet idea or delay addressing it properly. Some designers use their first preconceived idea exclusively as the basis for all subsequent work. (p. 36). I know I’ve been guilty of this in the past, especially if this project looks a lot like the last project. I tend not to re-think through how I came to the last project’s conclusions — I only focus on what’s common between the two, then try to fit the last design into this new project. I see this tendency in other designers when every project becomes an opportunity to use Buzzword-compliant-new-technology-X.[9] 

Mann suggests bringing the preconceived idea out into the open as soon as possible. Just go ahead and talk about what you’re thinking. If there’s a mismatch between the preconceived idea and the design requirements, then be honest enough to deal with it. When you try to force a match between the need and your idea, then you’re not designing any more — you’re selling.

He also suggests trying to generate more than one idea initially, as soon as possible. This helps in the brainstorming, and helps to compare merits between the ideas.

Professions fall victims to trends and fads. (p.37) This is clear to anyone who’s seen 1960-genre public buildings, or the hideous Bauhaus-esque square buildings with flat roofs and square windows. Software design gets into this, as well. Is there any new data format that’s not XML lately? Does MPLS have to be used in every new network? Does every web site need a “social networking” component? Is a “MOS” score really the only way to evaluate network quality for VoIP? Mann recommends that you be especially aware of these fads, with the hope you won’t be unduly influenced.

He also mentions the “creativity imperative”, which mandates that designers should produce innovative, unprecedented, “creative” solutions for every problem or project they face (p.38). This is a pressure I put on myself, and I expect a lot of other designers do it. I always want my new design to excel above my old designs in some way. I want my new software to be the picture of perfect modularity. I want my new network to be elegant and symmetrical, or its documentation to be the finest documentation ever made for a network. But I have to be careful not to burn up a project’s time on this goal. It’s not always best to mimic an old design (“rely on precedent”), and it’s not always best to create something new and different. 

I hope to discuss some of the other interesting topics in a later post.

[1] My job title is “Systems Engineer”. But this is an immature field and the standards for being called a “system engineer” are low. When I say “hard-science engineer”, I mean things like electrical engineering, mechanical engineering, or chemical engineering.

[2] I’m quoting Mann. Mann is quoting H. Rittel, Design Methods Lectures, UC Berkeley.  I’m not sure who Rittel is quoting.

[3] I can’t remember who wrote the book, “Notes on the Synthesis of Design”. But that was the origin of “Design Patterns” popularized in software by the book “Object Oriented Design Patterns”.

[4] DeMarco and Lister in “Peopleware” talk at length about how distractions are, and how they cause us to miss key insights and overall do worse work. They also discuss the idea of making projects seem fresh by trying out something new each time. I’m very attracted to this practice.

[5] What’s great about consulting work is that projects are pretty well packaged. Usually, they’re defined by a Statement of Work agreement. What’s bad about work as an employee within a company is that projects are often not well defined. It’s just a long list of unimportant tasks. I think interdepartmental billing is very important. People need to pay something to get your services; they’ll thus appreciate your services more, and take your product more seriously.

[6] http://www.grump.org/

[7] Apparently Van Jacobson designed the congestion-control system into TCP sometime in the mid-1980’s. Before that, the largest IP network, the ARPANET, would basically screech to a halt every afternoon.

[8] http://www.valdosta.edu/

[9] Are you as tired as I am of hearing how MPLS is the answer to every woe? Oh, and by the way, it’s almost always the hardware vendor. Oh, and by the way, you’ll need new hardware to get the full MPLS feature set.