Can’t you just fax it to me?

Essential communications in engineering often are broken because of mismatches of various kinds. CAD system formats don't match, the occasional Mac shows up in a world of PCs, someone sends a Word 2007 file to someone who uses Word 2003. It's natural that everyone uses what they own. It is considered unnecessary to change software just for the sake of change.

By Joel Orr, PhD, Chief Visionary, Cyon Research Corp., Bethesda, Md. August 29, 2008

Essential communications in engineering often are broken because of mismatches of various kinds. CAD system formats don’t match, the occasional Mac shows up in a world of PCs, someone sends a Word 2007 file to someone who uses Word 2003. It’s natural that everyone uses what they own. It is considered unnecessary to change software just for the sake of change.

But there is another mismatch that is affecting engineering communication at all levels: The generation gap.

Young engineers grew up with computers at home and in school. Computers are part and parcel of their world and their infrastructures. They text with their cell phones, their fingers do CTRL-C for “copy” and CTRL-V for “paste” without thinking about it.

Computers were central to their engineering education. Some of their textbooks were available only on their computers. Except for math courses, they probably handed in papers prepared only in word-processing or spreadsheet software.

Meanwhile, many senior engineers and managers, both in their firms and in those of their clients, arrived at the company before the computer was ubiquitous. And while all have become computer users, not all are comfortable with them.

Picture this conversation:

Young engineer: “I have that report for you, sir. I pulled the standard figures off a website I found, and lined them up with what we found for energy model in a spreadsheet. I’m e-mailing it to you as we speak.”

Client: “Thanks. But I may have some difficulty with that. Can’t you just fax it to me?”

Young engineer: “Oh, I guess you’re concerned because you have the older version of Excel? No worries—I’ll make a PDF. You’ll have it in just a minute.”

Client: “I appreciate that. But can’t you just fax it to me?”

Young engineer: “Well, OK. I’ll print it out and fax it. But—may I ask why? Isn’t it more convenient in electronic form?”

Client: “Maybe it is for you. But all I want is a piece of paper in my hand. I know what to do with that.”

Computers in an engineer’s life

Common to almost every activity in the life of the engineer is the helpful presence of the computer. Never before in history has there been a tool that is so empowering as to be integral to virtually every pursuit—research, design, correspondence, client communications, accounting, analysis, calculations, documentation, archiving, etc. The list goes on.

Computers are not merely special-purpose tools, like electronic calculators. They are the medium by which everything happens. Engineering notebook, calendar, address book, handbook, library—everything is in the Internet-connected computer.

Years ago, I tabulated a number of studies that measured what portion of an engineering professional’s day actually was spent engaged in design or drafting. All of the studies estimated that the figure was around 19%. In a 40-hour week, that is 7 hours, 36 minutes.

That raised a question in my mind: What about the rest of their time? The answer is meetings, site visits, measurements, research, and writing reports. The computer, it turns out, has a lot to offer in the way of productivity increases for those activities, too.

For one thing, how about computations? The electronic spreadsheet is a tool that brought about the personal computer revolution. The tipping point for PC sales occurred when the majority of computer buyers bought computers as an infrastructure to enable tools like VisiCalc, not to satisfy a hobby or a technical curiosity.

Today, spreadsheets can do so much more that it is hard to imagine engineering without them.

Presentations? Grade-school children learn to use PowerPoint and other tools today. It’s unthinkable for many people to have a meeting without a large-screen projector and nicely designed bullet points, as well as short movies and other presentation capabilities.

How has e-mail changed the life of the engineer? All communications are now instantaneous. About 10 years ago I visited a large architectural firm in Melbourne, Australia. “How has technology affected your practice?” I asked one of the partners. “Well, while we’re excited about computers for design and mapping, the big change began with the fax machine,” he said. “Really?” I responded, a bit surprised. “Yes,” said the partner. “Before the fax, a client would call and say, ‘Send me that change I requested!’ We would assure the client it would be on the next FedEx truck; that usually gave us a few hours to work on it.

“But when fax machines came in, the clients’ expectations changed accordingly. ‘I want it now!’ became their mantra—and we had to comply. E-mail was just a streamlining of this process.”

Research and education

Years ago, when my wife and I would debate the meaning of a word, we’d both rush to the big fat dictionaries to see who was right. Today, it would never occur to us to do that; we go to Google, Wikipedia, , and other web-based sources for our answers.

Are the answers better? Sometimes yes, sometimes no. We are much more aware of the varying levels of trustworthiness of what we find on the Web than we ever were about the dictionary entries.

But we are getting the benefits of pluralism and timeliness. New information is posted to the Web continually—and by different parties, interested and disinterested. Now our skills must be applied to verification and validation, to sorting the wheat from the chaff.

Young engineers often cannot fathom what it was like to do research before the Web. Senior engineers, on the other hand, often distrust information coming from what they perceive as unproven sources. That is a conflict that needs to be resolved in every organization.


Building information modeling is finally becoming a reality on many projects. What is it? Simply the natural outcome of doing everything in the computer. Designs are created and modeled in CAD, material take-off occurs semi-automatically, communication with and among all the project participants—owner, design firm, contractor, subs—takes place within systems that can track all the details.

BIM, in short, is not itself a new technology—it is the synergistic combination of all of the automation technologies that have appeared in the world of architecture, construction, civil engineering, and mapping automation in recent years.

But as Niccolo Machiavelli pointed out, anyone wanting to introduce a change into the way things are done has a tough row to hoe: The person will have the lukewarm support of those who stand to gain most from the change, and the fierce resistance of those who think they stand to lose by it. This is what hopeful BIM launchers are finding, and it is the essence of the resistance they must overcome.

The promise of BIM is enormous. It will, ultimately, totally characterize the way construction and building engineering happens in the world. But we are still in a period of transition, from old ways to new ways. The new is resisted because it doesn’t always answer the all-important ”What’s in it for me?” question at all levels.


The duty of an engineer—the obligations of the professional that are independent of the specific person or circumstances—is weighty. Lives depend on the quality of an engineer’s work. Even beyond the legal and regulatory ramifications, the moral implications of this fact are enormous.

So even though analysis software first saw commercial light in structural applications, its industry adoption has been slow and deliberate. The reluctance is simple: How does the engineer know how the software is performing? How can the results be trusted?

When the Empire State Building in New York City was being designed, hundreds of “computers”—people, with pencil and paper—were engaged to perform and check the structural calculations. But the chief project engineer was worried, and rightfully so: “How can I know that all the calculations are being done correctly?”

Even today, experienced engineers perform back-of-envelope, order-of-magnitude manual checks, to at least determine that the answer has the right number of decimal places. And many older engineers decry the fact that manual approximation is not being sufficiently emphasized in engineering schools, where the students implicitly trust the computer.

The power of the tools can be heady, almost overwhelming. Yet the tools are no more effective than the person applying them to the problem. Underlying assumptions, and choices as to how to frame the problem, are crucial. The tool can be ever so powerful, ever so precise, ever so friendly. But if the loads and constraints are chosen improperly, the results are meaningless. As the cliche goes, “garbage in, garbage out.”

Communication and collaboration

While e-mail is truly wonderful, and its offshoots, such as cell-phone texting, give us an immediacy undreamed of by earlier generations, it is only the beginning of powerful collaboration tools.

The Web has given us the ability to create hubs and bulletin boards that cannot only be accessed from anywhere there is an Internet connection, but can keep track of who saw what and when. This quality alone, if properly applied, could greatly reduce the litigation activities attendant upon almost all engineering projects of any size.

Let’s consider some of the simpler forms of communication now used so widely, even in the world of engineering: blogs, wikis, and portals. A blog is a trimming of the term, “weblog”—nothing more than a diary, usually date-and-time-stamped. It is an incredibly powerful way to share information. You can create a blog for free at or at , as well as in many other places. You can, in fact, create a blog for every project you’re working on, and one for your family. And you can restrict who can access them and comment on them—all without knowing anything about web programming.

Those who are permitted to do so can come to the blog and add entries or comments. The blog can be a contemporaneous record of events and communications.

Many engineers and their employers are reluctant to use blogs because of the fear of putting down in writing things that could possibly be used against them in subsequent litigation. That is a well-founded fear. Blogs should be used prudently. For example, see this blog: . It reports on the progress of the construction of a Rhode Island library.

A wiki is a website that can be edited and commented upon by anyone who can access the site. Modern wikis, such as , have free versions, as well as premium versions that allow for more memory, more bandwidth, and so on.

Wikis—the most famous one is —are most useful for brainstorming, for sharing information that does not necessarily have a chronological component. They are more subtle than blogs; we’re not used to communicating non-sequentially. But they can be very powerful. Here’s one that the University of California-Davis uses to communicate and discuss details of its construction projects: .

Portals are web pages created by a firm or company for providing access to a wide variety of information, to different audiences. An intranet is a kind of portal for sharing information within an organization or project; an extranet is similar, but has additional security features that limit access to information by people outside the confines of the firm that established it. Examples include services and products offered by Autodesk ( ) and Bentley Systems ( ).

The power of the portal is that it can be a “project switchboard,” for one or more projects. Looking for approved suppliers on this project? There’s a link right on the front of the portal. Lists of requests for information? If you are approved to access them, just click here. Need to communicate with someone on the project who is not in your direct chain of command? Here’s where you can track down an e-mail address and direct a person to the files relevant to your issue.

Why don’t all projects use blogs, wikis, and portals? After years of studying this question, I’ve come to the conclusion that it’s because the individuals and firms whose cooperation is essential to making it all work do not necessarily see the benefit of them. They understand how it’s better for the project; but they have concerns, often justified, that they will lose something by the creation of the new facilities. These concerns need to be alleviated if the facilities are to provide their full benefit to all participants.

A major construction firm in Dallas retained me to explore project collaboration automation alternatives. I started with a presentation of available technologies, and was surprised to receive a lot of negative feedback within the meeting from project managers—most of which could be summarized as, “We’re far too busy to introduce new technologies; all our projects have deadlines, and we can’t take the time to disrupt work and train people on new tools.” When I met with each project manager individually, I learned that the real issue was that they were senior people who fundamentally distrusted computers.

What’s a young engineer to do?

If you are a young engineering professional, someone who grew up with computers, you probably understand—and are justly excited about—the potential of computers’ applications for your profession. You are likely aware that that potential is essentially unlimited, whether for the personal tools in your kit, PC, PDA, phone, tablet, or for the systems in your projects, with their embedded systems, control panels, locating electronics, and growing range of sensors.

More power to you. The future of engineering belongs to you.

But it is in the nature of things that youth may not fully respect the wisdom and knowledge that come only with experience. Rates of failure, back-of-the-envelope calculations, knowing when and how to exercise intuition—these things come only with time, with observing successful projects—and especially, with observing failures.

The challenge is to read about, listen to, and learn from the failures of others, so that you can make it your goal to make only new mistakes, and not repeat old ones.

You might start by talking to your boss and expressing your desire to learn more about what he or she considers to be the essentials of engineering success. And pay attention when your boss recounts war stories; there’s a lot of useful information there. Use your curiosity to ask good questions. Read trade publications; they are ideal resources.

For the rest of us

For you experienced engineers: Your gray hairs were acquired honorably, and you have a great deal more to contribute. If you’re struggling to get your arms around all that the new world of computational engineering has to offer, that is understandable.

But don’t stop. The engineering you know and practice is the real stuff. The computer can and will amplify the benefit of your experience in undreamt-of ways.

Will it require learning? Absolutely. Discarding of some old and trusted tools in favor of some new, more powerful ones? Unquestionably.

Don’t hesitate or draw back. Embrace the new-fangled stuff—even if you’re still not sure what a wiki is. It is not beyond you. It’s just new stuff, and you have dedicated your professional life to understanding and using new stuff. This is a whole bunch of new stuff, but you’re up to it.

Author Information
Orr has been working with engineers since 1973. He designed one of the first municipal geographic information systems (for Metro Nashville), founded Computer Graphics World magazine, helped found and served as president of the National Computer Graphics Assn., and served as Autodesk Distinguished Fellow (1990-1993) and Bentley Engineering Laureate (1997-2001).