Civil Engineering: A Changing Profession

Since starting in the engineering profession, many of us have experienced a significant change in how we perform our jobs. Thirty years ago, there were not computers on every desk, each engineer did not have a drafting table; there were no faxes, no copiers and, certainly, no phones with speed dial or voicemail.

Think back to who performed what tasks. When a memo or letter had to be written, the engineer roughed it out in long hand, gave it to a secretary or secretarial pool, and then got the memo back—edited, complete, and error free. You made sure the draft of the memo or letter was well written because if it wasn’t, your secretary put the revised document at the bottom of the pile and made you wait to get it back or gave you a severe tongue-lashing. When you wanted a copy of a document, you made sure the typist knew ahead of time so carbon paper could be used. Preparing a simple letter took thought and planning.

Remember when you gave the draftsman a preliminary sketch and how beautiful the final drawing looked? You made sure that the changes were minimal because the older, more experienced draftsman would make you pay with either a tongue-lashing or delays in getting the drawing completed.

How we have changed.

No longer do engineers necessarily have secretaries to do their typing, filing, and copying. These days, the supervisor does his/her own word processing or e-mailing and acts as a document formatter and proofreader. Through the downsizing of America, we gave up good support staff and, at the time, we all thought we could do it better anyway.

Soon though, we looked around the office: the staff, who used to be one engineer and a lot of support staff, had become one engineer and maybe one draftsman or technician.

Have we become a profession that “does it all,” compared to other professionals? How many successful lawyers and doctors type their own memos, draw their own drawings, answer their own phones, or make their own copies?

The purpose of this article is to make each engineer and each firm ask, “Are we becoming a more professional profession or are we just becoming registered technicians?”

Some questions we need to ask are:

Over the past decade, the speed and capability of computer technology has significantly changed how engineers typically approach problem solving. Entrepreneurial enterprises and the academic community quickly recognized that computing technology had evolved to the point that automated tools could make engineering analysis, design, and drafting not only “easier” for the practitioner, but “less costly,” with the promise of increasing profitability. Such “artificial intelligence” equation-solving software has been developed and marketed for a wide range of functions and tasks to the extent that the practicing engineer could easily lose sight of a core aspect of the profession: the need to keep current by personally performing research and developing the fundamental understanding to apply state-of-the-science solutions to problem solving.

The advent of computer-aided engineering design tools can further affect the profession by inhibiting creativity in the final engineering product. The profession needs to ask the question: “Will artificial intelligence one day replace human intelligence?” Current expectations on the engineer practicing either in the private or public sectors demand that the engineer multitask in his/her daily work. Developing new customers and projects, preparing presentations, compiling project budgeting and cost accounting, and preparing reports all demand time that could or should be allocated to technical analysis and design. The pressure to produce engineering products on tight schedules and within or below the available budget, while ensuring that the next project is secured to keep you and your colleagues funded, can result in turning to another apparent intelligence source to provide your design capability. If the profession routinely turns to computerized analysis and design tools, the overall creativity of engineering products will logically diminish. Public and private clients expect and demand cost-effectiveness in engineering plans or facilities. In order to effectively compete, creativity could suffer as the profession continues to turn to computer-aided design tools to do the “thinking.”

Computer-aided engineering design tools also can affect the ability of the engineer to understand the full scope and context of the engineering problem. When faced with what may appear to be a routine problem, not unlike one faced in the past, the engineer could rely on the turnkey solution offered by design software and inappropriately place greater emphasis on how the final product looks compared to the quality and creativity of a designed solution. Desktop publishing software has evolved at a rate not unlike the evolution of the computer microprocessor. What was once the domain of the cartographer and commercial graphic artist is now at the fingertips of the engineer. The breadth of capability afforded by desktop publishing software can add a new expectation to the engineer’s overwhelming list of duties. Not only are we expected to creatively solve the engineering problem, but we must also make the report or presentation even more attractive and flashy for marketing and customer satisfaction purposes. Unless publication-related assistance is provided, the engineer could easily lose sight of the bigger, more important picture that makes appropriate time available to focus on the technical aspects of the problem and applying creativity in developing the recommended solution.

Professional engineers are responsible to the public and their clients—to protect the public health, safety, and welfare in the course of performing engineering services. Professional engineers are educated and trained to be creative in developing effective solutions to complex engineering problems, while maintaining the public’s trust and respect. In the course of problem solving, the engineer must make an informed evaluation and selection of the most appropriate methods to analyze the complexities of an engineering problem. Selection of the appropriate method involves research by the engineer in order to develop an understanding of state-of-the-science applications of mathematics, physics, chemistry, earth, and biological sciences.

The reduction in the number of engineering graduates will require reconsideration of how staff with special technical skills should be utilized. Managers of engineering organizations, both private and public, should be asking themselves, “Is the highest and best use of our highly skilled, technically trained engineering professionals to have them perform hands-on computer-aided drafting, do their own word processing, and expect them to be responsible for a variety of administrative tasks? Or would it be best for our organization’s effectiveness and financial well-being to have our professional engineering staff focus on performing engineering, planning, analysis, and design?” The pertinent considerations in answering these questions must be cost-effectiveness, efficiency, productivity, and quality of the engineered product, as well as the professional and technical development of engineering staff.

When engineering software for the personal computer first came into being, it was heralded as a tool that would allow engineers to design more precisely and evaluate alternatives more quickly, all at lower cost. The profession embraced the advent of the computer and promoted its power to transform the industry. Such a good job of promoting the computer was done that clients now think that the computer alone resolves design issues associated with a project. This has served to commoditize the industry. Since all engineers use computers and software to “design” a project, all engineers must be the same. Therefore, why should a client pay more than the lowest cost that engineering services can be purchased for?

One of the reasons that engineering services are perceived as a commodity is that, in general, people do not understand what engineers do. The computational aspect of engineering has been oversold such that there is a loss of appreciation for the engineering thought process. Lay people believe that computers design projects and that engineers simply input given data.

Our clients and the populace in general need to be educated to the fact that civil engineers interface between social infrastructure and the vagaries and power of nature; that we visualize the entire project in three dimensions and figure out all the components that are required for the project and fit it to the site that is intended to receive it. We transfer that three-dimensional visualization onto paper in the form of drawings and specifications, or contract documents. These documents allow the entire project to be built and put into service. It is the engineer that creates these documents—not the computer.

No matter how much education or experience we have, until we educate the general public on the intellectual capability required of our profession, we are doomed to less-than-professional status.

Programs versus calculations. Many of us have embraced the development of software programs to derive solutions to engineering equations. The software calculates solutions to equations based on input and does so to ten significant places. Part of personally calculating a solution was going through the thought process of setting up and defining the problem. It made us think about the problem and evaluate it from several perspectives.

Now we have “canned” software programs that prompt us for parameters and run the calculations in an incredibly short amount of time. It is the same program arriving at the same solution every time, albeit with different values for the variables. The inaccuracy of the parameters being input relative to the accuracy of the calculated answer can often be overlooked.

Clients and engineers can be lured into believing that what is being calculated, and ultimately built, is in fact that accurate. Tolerance is being lost, and accuracy is being misapplied. One example of this is storm drain hydraulics. If the rational method is used to establish flow it is, at best, accurate to plus-or-minus 10 percent. However, if the software does not prompt consideration of a bulking factor for watershed and channel characteristics, which could add up to 50 percent or more to the required flow capacity, pipes then sized by the software calculating the hydraulic and energy grade lines to two places past the decimal point are actually undersized due to localized conditions that the software does not prompt for an input. To protect themselves from improper use of the software, software manufacturers often use conservative coefficients. This will have a tendency to oversize a “typical” installation and may not be able to accommodate a low available head condition. The software usually has the flexibility to accommodate a wide range of conditions but this requires the user to be well versed in hydraulics. If the user is not well versed in hydraulics, but understands the site constraints and has a thorough understanding of the software, the result, then, is probably a poorly designed drainage conveyance system. The difference between the hand calculations and a computer-generated report is that calculations show the equations and the assumptions made, and the computer-generated report is a professional-looking output that is difficult to check and assumed by lay people to be correct.

Personal experience dictates that, in many cases, it can be less time consuming and more accurate to run longhand calculations to obtain the answer, rather than using the computer. However, many now believe that the only way to do it is to use the software program. If this is followed to the extreme, all solutions will converge on being the same with little independent unique thought applied to a problem. In fact, using this approach does render engineering a commodity. (See the discussion in the previous section.)

There is a tendency for young engineers to completely rely on computer results, not even taking the time to drop a scale on a drawing to see if it is actually to scale. A field crew may survey a site, deliver the E-file to a CAD drafter in the office, and never see the actual topographic map. The map, compiled by the CAD drafter who never saw the site, is then delivered to the engineer or architect who will rely on the survey for design of improvements. The engineer or architect never sees the site, relying on the accuracy of the survey. What kind of a final product will result from this approach? The sad part is that it’s not even cheap to produce.

Numerous software programs can calculate anything from storm runoff, to flows in a pipe, to loads on a beam. Engineers used to rely on “rules of thumb” that were guidelines for design. Many of the people who use software programs have no understanding of the equations from which solutions are being calculated. Although rules of thumb may not solve the problem, they are typically well within an order of magnitude. Knowledge of rules of thumb, and approximately what the answer should be, needs to be a requirement of designers before the computer is employed.

This brings up the concern as to whether new engineers are being taught to understand how to dissect and solve a problem or whether they only learning how to use software. There is a substantial difference between the cognitive ability to problem solve, which requires one to understand the problem, sort out what is required to solve the problem, sort essential and nonessential information, and develop the information and parameters necessary to derive a solution to not only the correct equations but the overall problem being worked on. Using software requires that the user respond to the information request prompts that the computer program flashes on the monitor. There is little to no cognitive learning value to responding to computer program request prompts. Calculating solutions to equations is not problem solving.

Many companies have extensive “standard detail” libraries that are often liberally applied to projects. They are there to reduce “reinventing the wheel” and duplication of effort. How often are these standard details applied to a project without thought, when actually significant modification should be made to apply it to the project at hand?

Old projects are often used as a model for a new project because it is “close” to what is required for the new project. Many elements can be taken from a previous project and dropped into a new drawing. A CAD-drafted drawing can look complete when in fact it is far from being complete. This strategy is often employed to make a project appear more complete to the client than it is, when submitting the project for an interim milestone. Sometimes in the rush to get a project completed and delivered to the client, proper oversight and checking are overlooked.

The “black box” nature of many software programs, including CAD, makes detailed checking difficult, if not impossible, on an after-the-fact basis. If proper checking and oversight cannot occur using these software packages, use of these programs by other than a registered professional may be considered a breach of the fiduciary responsibility engineers have to the public at large. (See the discussions “Engineer or Registered Technician?” and “Civil Engineering—A Profession or a Commodity?”)

Increasing the minimum level of education has been touted as a method to increase respect and therefore pay in the engineering industry. The problem is not the level of education young engineers receive, it is the perception of the engineer by the public at large. Although more education is desirable, it is the fact that the general public perceives that computers do the engineering and engineers have gone out of their way to impress the importance of computers to the industry, which supports that perception.

The problem is computers do not develop solutions to problems; they calculate solutions to equations. Computers do not think analytically, or evaluate alternatives, assess impacts, or apply judgment to a problem—all things that engineers should do. Computers are simply super calculators and only one of many tools available to engineers.

If engineers are to regain the prestige of the profession, we need to inform the public as to what we actually do. Education alone does not equate to understanding complex issues, and more education will not transform the layperson’s perception of what engineers do. Attorneys are respected because they understand laws that the layperson does not. Doctors are respected because they understand medicine in a way the layperson does not. The layperson thinks computers solve engineering problems, which has relegated engineers to technician status in the layperson’s mind. In fact, engineers have told them as much. If we are to regain our prestige as a profession we must educate the public to the aspect of solution visualization and transformation to constructible product. This ability, like the understanding of law and medicine, demands respect because of its complexity and the fact that few people have the training and ability to do it. (See the discussions “Engineer or Registered Technician?” and “Civil Engineering—A Profession or a Commodity?”)

CAD was designed to improve the engineers’ ability to generate documents. In fact, it may have produced more problems than it has solved. The truth is that we cannot go back, but let’s look at where CAD has taken us.

Drafters used to be industry interchangeable. Someone who could do mechanical or, say, automotive drafting could typically readily adapt to civil engineering drafting. An individual who could draw clean, uniform lines and letter well could be a drafter. If the drafter stayed in an industry and was sufficiently motivated, he or she could move up to designer and, eventually for some, to engineer.

With the advent of CAD, drafters are now highly trained individuals who control a significant portion of design. Many engineers are not versed in CAD. The engineer may design it correctly but if the CAD drafter doesn’t input the design correctly it may be constructed incorrectly.

CAD drafters are not interchangeable with other industries because the software required to produce the drawing is so specialized. Because of the training commitment, fewer people are capable of doing the work or take the time to pursue the career path. This pigeonholes the CAD drafter and limits the available talent in any one industry.

Unless the engineer is versed in and uses CAD software, the final product is dependent on the ability of the CAD drafter. If the engineer is versed in CAD to the extent that he or she is designing and drafting the project, then one needs to look at whether this is the best use of the engineer’s time. (See the discussion “Engineer or Registered Technician?”)

A recent visit to a software university resulted in an uncomfortable realization that those developing the software not only do not understand how it all fits together, but few have actually used the software to deliver the desired product. Our organization finds that we are continually trying to manipulate the software to have the drawing prepared as we feel it should be and not how the software automatically displays the information. In the end the software generally wins out because it costs too much in time and money to customize it to change the output. Even if we did change the program, the next version would require we start all over again.

Software, then, is controlling how the industry prepares and inputs information and presents its finished design product; implementation of new ideas and approaches is tempered by what the current software allows. This approach stifles uniqueness and diversity in design and presentation. What this has done is place another information transfer filter between design and construction. The cycle time between changing software and learning it to implement industry change is significantly longer and more costly than when the engineer was the only one required to adapt the design approach and presentation to respond to the change.

It used to be that an engineering plan would have a control drawing that would show where everything was to go. There were plans and profiles and there were standards used between disciplines that each relied on. A surveyor would establish a baseline and a project would be laid out from that. This approach had several checks and balances.

When drawings were manually produced, the drawing would continually evolve. It would start with nothing, the plan would be added, then the dimensions would be added, then the notes would be added. Yes, there were revisions along the way, but when a line went down it stayed there until it was erased. The engineer had total control over the entire design development process.

With today’s CAD, drawings are a model prepared in three-dimensional space at a one-to-one scale. Chunks of previous project drawings can be cut and pasted into new drawings very quickly. All lines are drawn perfectly, and in a short period of time a drawing can be thrown together that looks relatively complete. Someone has to keep track of what is real in a drawing and what has been imported and still needs to be “cleaned up.” Since the drawing does not evolve in a linear fashion, we have lost the process of checks and balances on drawing development.

How many times have we looked at a “final” CAD drawing, only to find information that was there at one time missing? CAD has become so complicated: the information can put on wrong layers; layer states can be changed; an old version of the drawing can be worked on mistakenly, with the user thinking it is the most current; or two people can be doing different changes to a drawing at the same time. There are methods to prevent each of these occurrences, but the point is that these problems occur in spite of the availability of preventative measures. CAD is a complex program that takes as much or more focus and time to manage for proper output as the engineering design once took, and it comprises only a portion of the design effort.

Because the drawings are prepared in model space and are supposed to be accurate, the model is typically used for field layout instead of the plan dimensions. In fact, many dimensions are commonly left off because “the digital model contains the information.” The “engineer” prepares a drawing with a model of the finished product, and the surveyor, who will stake the project and locate the facilities in the field, identifies layout coordinates for points directly from the model. The actual dimensioned plans are not read in many cases. At this point in the process, the points that have been selected are separate entities with no real tie to the original layout except for the description attached to the point by the surveyor.

These points are then typically set by radially staking with no reference line on the ground to actually check against. This eliminates the ability to easily check between the original drawing and the model and the placement of the actual hub in the field.

It used to be that a surveyor would stake from the control drawing that would be taken into the field, and labeled with bearings and distances, so that the intent of the engineer was known and the bearings and distances could be checked as the project was laid out. We used to routinely get calls from the field asking questions about how we wanted the project adjusted relative to existing physical characteristics. We now seldom get those calls, but it is not because the drawings are better, but that an opportunity to catch an error has been lost.

The point of this discussion is not that these problems cannot be corrected—they can with rigid procedures and changes in operation. The point is, now a significant amount of professional time is diverted to the development, implementation, and maintenance of procedures to protect against problems that previously did not occur. This results in the loss of production time by the engineer or surveyor, increased cost to the client, increased risk of error, higher insurance premiums, and lower profit margins.