Tag Archives: details

Episode 95 — Details

detailsBrian, Carmen and Jeff discuss the role of details in engineering projects, and how one goes about evaluating, managing, sharing, and documenting critical minutia.

  • In the introduction, Jeff misses the detail that this podcast is published in November, not October.
  • Carmen doesn’t mind sweating the details, but reviewing documentation for typographical errors is not his favorite task.
  • It is often said that “the devil is in the details.”
  • We continue to look for guest and topic suggestions from our listeners, so feel free to send us a note with your ideas.
  • A previous guest, James Trevelyan, has written about the value of engineers, and how uncertainty reduction is an important contribution of the engineering profession.
  • Uncertainty is frequently treated as a statistical issue.
  • Brian relates a recent situation in which he burned through many hours trying to uncover a programming detail buried in the documentation.
  • Electronic circuits can behave badly in “high EMI” environments, where EMI stands for “electromagnetic interference.”
  • Jeff justifies his “pi multiplier” concept (see this podcast’s first episode) with the “cone of uncertainty” used by software developers.
  • It’s Brian’s opinion that engineers often fail to utilize the formal methods found in other professions when managing a multitude of critical details.
  • Jeff claims that engineering standards ease the burden of dealing with frequently encountered details.
  • Of course, as Carmen observes, the problem sometimes lies in choosing the “right” standard.
  • Searching a large solution space for potential design details can be a frustratingly slow process, says Jeff.
  • Brian always tries to have a backup plan, so he is not “checkmated” by a single detail.
  • The amount of documentation appropriate for each detail seems related to the detail’s expected and potential costs.
  • Creating a documentation hierarchy can provide needed information without overwhelming customers, notes Carmen.
  • Humans quickly become inured to a surplus of details (or warnings).
  • Brian has found modularization (it’s really a word!) to be a good means for keeping details from interfering with one another during the development process.
  • Software packages are available for companies wishing to implement enterprise resource planning (ERP).
  • Git has become very popular as a version control system.
  • Hardware changes can be tracked in Git using visual diffs.

Thanks to Frédéric Bisson for the photo titled “Détail de la machine à vapeur Merlin.” Podcast theme music by Paul Stevenson.

Episode 57 — What Engineers Do

DraftingIn this episode of The Engineering Commons, we discuss engineering skills and duties learned in the workplace, rather than from a textbook.

  • Brian tells young engineers that an engineering degree is a “learner’s permit.” Once in the workplace, engineers have to teach themselves to solve an entirely new class of problems.
  • A gold-fish shaped retention pond, first mentioned by Adam in our episode on engineering pranks, is referenced once again, although your dutiful scribe is still looking for hard evidence of such a structure.
  • An extended discussion related to beer production and consumption breaks out amongst the discussion panel.
  • Jeff describes how the bricks that once covered the entire racing surface at the Indianapolis Motor Speedway are now found only at the start/finish line, in what is known as the Yard of Bricks.
  • Lateral loading on racing surfaces, due to the massive grip exerted by race car tires, requires the use of specialized asphalt mixtures.
  • Drivers in the Indianapolis 500 automobile race pull more than 3 lateral g’s while going through the turns.
  • Quotes about the engineering profession:

    “Engineering is the art of organizing and directing men, and of controlling the forces and materials of nature for the benefit of the human race.” — Henry Gordon Stott (1907)

    “”The ideal engineer is a composite … He is not a scientist, he is not a mathematician, he is not a sociologist or a writer; but he may use the knowledge and techniques of any or all of these disciplines in solving engineering problems.” — N. W. Dougherty (1955)

    “Engineering is not merely knowing and being knowledgeable, like a walking encyclopedia; engineering is not merely analysis; engineering is not merely the possession of the capacity to get elegant solutions to non-existent engineering problems; engineering is practicing the art of the organized forcing of technological change… Engineers operate at the interface between science and society…” — Gordon Stanley Brown (1962)

    “Scientists study the world as it is, engineers create the world that never has been.” — Theodore von Kármán

  • Engineers break complex problems into smaller solvable pieces. The “art” of engineering is knowing how big those pieces can be.
  • Whereas textbook problems usually have a definite answer, problems from the workplace are often ill-defined, and may sometimes offer no practicable solution.
  • Problem constraints in industry may seem at times arbitrary, being controlled by economic, political, and organizational powers beyond the engineer’s realm of influence. Additionally, these constraints are not fixed, but vary with time.
  • We reveal our high-tech method of aligning audio tracks in Audacity, the audio editing software used to create this podcast.
  • Obsolescence issues are increasingly important for design engineers as commercially-available components are being manufactured for shorter periods of time.
  • Engineers must avoid the natural urge to over-design products, even when dealing with complex constraints.
  • Making a prototype work once in the lab is far different than making thousands of mass-produced products work reliably in the field.
  • An important part of an engineer’s job is prioritizing where one’s time should be spent.
  • Many times it’s more important to be on the “proper” side of the equation than to be right; that is, one has to make certain assumptions that may be incorrect, but those assumptions need to be made such that the product or service will not fail, even if the assumptions are not perfectly accurate.
  • Jeff’s example of a 500 ksi stress load would have been more realistic at 50 ksi or 500 MPa, at least for steel parts.
  • In examining the meltdown of nuclear reactors at Japan’s Fukushima Nuclear Power Plant, recent reports have suggested that a contributing factor was the lowering of a seawall back in 1967.
  • Jeff references a scene from The Big Bang Theory television show where Stuart and Sheldon argue about gradations of being wrong.
  • It’s important for engineers to keep track of the small details, even though the process of doing so may be quite tedious.
  • In his autobiography, test pilot Chuck Yeager recalls the tragic outcome of a line worker’s decision to install bolts “right side up” while assembling a jet plane aileron, even thought the blueprints indicated otherwise.
  • Engineering designs need to account for human factors, as well as technical constraints and specifications.
  • Jeff makes selective use of geometric dimensioning and tolerancing standards, as sometimes a simple callout works better in the prototype machine shop.
  • As an engineer, skepticism is prudent in evaluating information and methods. However, too much skepticism can lead to one being labeled “not a team player.”
  • Engineers are often asked to be “fortune tellers,” predicting future outcomes for processes and designs that have never before been realized.
  • Adam emphasizes the importance of understanding safety factors, and their proper application in the design process.
  • Production and maintenance costs are crucial factors in industry, while such cost issues are often overlooked in textbook problems.

Thanks to Seattle Municipal Archives for the photograph titled “Drafter working in Engineering Department, 1959.” Podcast theme music by Paul Stevenson.