August 2018 - Edition 02, An Engineering Method


This being the second edition, I haven’t gotten much feedback on the format yet, so I plan on going the course and assuming that at least I’m giving myself an outlet. In that vein, I have selected a topic that builds off of the last one to provide continuity. As previously discussed, if others have ideas, I’m glad to listen and incorporate the topic as appropriate.

Demetri's Corner

Time for reflection. Since the last newsletter, technically I’ve been in business for a month, but realistically, it’s my down time and I’ve been realistically in business for about a week. There’s no actual progress to report, but some hopeful motions have been made, and I’m starting to get used to the concept of working for myself. I’m already not sure I could ever go back to a 9-5 style job at this point. Going back to the skydiving analogy (you’ll have to read the last newsletter to be in the know) at this point the pilot chute has opened. My path is stabilizing, and there’s every indication that the main chute will deploy, but when, how fast, and the condition of the main canopy is unknown.

So on to the good stuff!

Today's Subject - An Engineering Method

The subject is really a follow-up on the last subject of being an engineer. We’ve all heard of the Scientific Method, and in many ways, it’s used to define what a scientist does. As previously discussed, coming across the definition of what an engineer does is much more complex. So how can there be an analogous process for an engineer?

“Analogous” may be a little too extreme. We require more “flexibility” than a scientist in approach, as our end goals are often squishy, so it’s never really clear when we’re “done”. Let’s start with the scientific method as defined by Merriam-Webster:

principles and procedures for the systematic pursuit of knowledge involving the recognition and formulation of a problem, the collection of data through observation and experiment, and the formulation and testing of hypotheses

Perhaps we need to break it down a little more systematically. I’m sure we’ve all seen some version of this in high school science.

  1. Define the knowledge you want to gain. Examples include, “Why is the sky blue?”
  2. Create hypothesis on the answer to the question posed. Examples include, “An airplane full of blue paint exploded a while back and we’re still seeing the color spray.”
  3. Develop a test to validate the hypothesis. An example would be, “I’ll buy a 737, fill it with as much blue paint as it can carry, fit it with autopilot, fly it to a visible part of the sky, and blow it to smithereens.”
  4. Perform the test and evaluate the validity of the hypothesis. “Well, I guess a part of the sky was a little blue, but in the end, I just ticked off a neighborhood in New Mexico and have the EPA all over me, so I guess that’s probably not how the sky got blue.”
  5. Repeat…with a more plausible theory.

Of course the example is in jest, but in all reality, it’s a very sound system for gaining core knowledge. And it is incredibly important that someone do this work so we can understand the world around us. But it’s not the job of engineers. Engineers need to let the scientists do their work and understand the successes and failures of their experiments so they can extrapolate the experience into other areas. Engineers are “reprocessors” of scientific knowledge, not creators of it.

So how do we modify that for engineering? It’s surprisingly similar:

  1. Define the problem. This is both simpler and harder than it sounds. Usually, when someone tells an engineer they have a problem, either they actually don’t know what’s important, or have a preconceived notion of the solution. Both of these issues need to resolved at this step. This can be a simple as stepping back and taking an objective view, to as complex as doing a full failure analysis. And unlike the scientific community, we are beholden to people that want things and results, so often a charm offensive is necessary to ensure that the correct problem is addressed.
  2. Develop a designed solution to the problem based on experience, technical knowledge, limitations, etc. This is the heart of what most consider engineering, which is coming up with a solution to a problem with a specific set of constraints. This is the definition of an engineer in the previous newsletter paraphrased. So this step would be considered “engineering”, but it’s not the entirety of the engineering process.
  3. Have independent reviews of your solutions. This is deeper than just a check to make sure there’s some reasonable expectation you didn’t mess anything up technically. This is a review of the reasoning behind all of the design decisions made. The importance of this step cannot be overstated, and often it is the step most likely short changed. People don’t like conflict, and this is intentional conflict. As engineers, we must have a reason for every decision made, but also be capable to accept that better reasons exist for a different path. Flexibility and leaving our design ego at the door is necessary. We must be confident and collaborative at the same time.
  4. Iterate the design as much as possible. You are never going to be “done”, but you are going to run out of resources (time, money, people, knowledge) at some point. The more you learn about the design, the better the product, so this iteration is important to root out any issues not addressed by the review. As an engineer, there will always be something that you do not address, whether intentionally or unintentionally. It’s really upon engineering judgement to make sure you are focused on aspects of the solution where critical failures could occur and addressing those during the iteration to increase confidence in design success. Sometimes this can take the form of a risk informed approach in focusing the design optimization effort. That is ideal, and should be the model on which all design efforts should be iterated, but this can take many forms based on the complexity of the problem, resources available, and criticality of the solution.
  5. Implement the solution. This is where the rubber hits the road. At this point, usually an engineer’s reputation is at stake, as even if the solution is non-critical, or can be adjusted in process, it’s the first time the client will see the solution in action.

Now, this is just my interpretation of the process, and it is far from set in stone. Every time I revisit this subject, I change my mind a little bit. This could almost be a yearly segment and look different every time. But much like the engineering method in general, I will continue to iterate it until I run out of resources, but since those resources are at my disposal, they will not be exhausted until I stop thinking, which hopefully is very far in the future.

Dose of Aphorisms

This particular word jumble is credited to something I wrote eight years ago sitting on a plane in a notebook on my way to a power plant. I just recently unearthed this “gem” which goes to show I’ve always had a penchant for making up sayings (thought I didn’t know it at the time). I also found a poem in the same notebook about the trials and tribulations of flying. I will not bore you with that (unless someone asks).

You can have your cake and eat it too, as long as you’re willing to learn how to bake and put in the effort.

Explanation of Fields in the SMARRT form submission

Reference Scenario Inputs:

Number of People Infected – How many potential members of the gathering are infectious. The simulation starts when they enter (time=0).

Type of Activity – Impacts the number of particles spread as aerosols per respiration. More strenuous activities result in more viroid particles being released.

Air Changes per Hour – This is the air exchange rate with fresh air for the volume of air being breathed by the gathering. If you use forced air exchange, you can calculate the number of air changes per hour for your specific situation.

Space Floor Area and Ceiling Height – These are used to calculate the total space volume.

Duration Infectious Person is Present – This is how long the infectious person stays in the space after their initial entry. For the reference scenario, this defines the end of the simulation.

Gathering Scenario Inputs:

See the reference scenario for all inputs up to Time of space entry.

Time of space entry and exit – These values represent when you enter and leave the space referenced to the infectious person. For example, if you show up fifteen minutes late, but stay an hour after the end of a one hour party, the Duration Infectious Person is Present is 60 minutes, the Time of Space Entry 15 minutes, and the Time of Space Exit 120 minutes