Design Norms for LogiSketch -- Part 2: Design Norms

 

Part 2: Design Norms

In Part 1, I described a new brain game app I wrote for my wife, Pam. Named LogiSketch, it is a nonogram puzzle app. I used that experience as a springboard to talk about engineering design, focusing on design decisions. Engineering design always involves making decisions to choose between alternative approaches. Valid alternatives all correctly solve the problem, but in different ways. To choose between the alternatives we must apply further decision criteria, and those criteria represent our values. Making those decisions explicit makes for a better product. It also provides an opportunity to talk about values arising from our Christian faith in a way that can be more authentic and less “in your face” for non-believers.

For Part 2, let’s expand our ideas about design criteria beyond the standard textbook list of factors such as cost, time to market, safety, etc. Based on the work originally done by the authors of <i>Responsible Technology</i> (https://www.google.com/books/edition/Responsible_Technology/8cLuAAAAIAAJ?hl=en), we will also consider the design norms.  You can also find a more recent treatment in the book that I co-authored with Brue and Schuurman,  A Christian Field Guide to Technology for Engineers and Designers. For this article, I’ll apply four of the norms to my latest design work on the LogiSketch app.

Design Norms Applied to LogiSketch

Justice

The design norm of justice puts weight on the fairness of the design to all stakeholders. (By stakeholders, I mean everyone affected by the product, which is a larger set of concerns than the product purchaser alone.) One of the ways I satisfied the norm of justice relates to the images I use for puzzles. When a puzzle is solved, the image is displayed. If the image is not my own, I have confirmed it could be used commercially under a license such as the Creative Commons Attribution license.  I then ensure that the attribution is provided immediately below the image. This respects the rights of the image owner. 

Another way I satisfy the norm of justice relates to how I price the app. The app itself is free. It comes with a starter collection of puzzles (that I call a “gallery” following the museum theme). Other galleries are available for purchase. I made sure the starter gallery had plenty of puzzles so that users had a fair chance to evaluate the app and decide if they wanted to pay for other galleries. I also tried to price the galleries reasonably. Those are only a few ways we can honor justice directly in our designs. Next up, clarity.

Clarity

The design norm of clarity (also called “Open Communication”) puts weight on honesty and transparency of the design to all stakeholders. One of the ways I satisfied the norm of clarity was accuracy in how I describe the app in marketing literature. I clearly indicate  that while the starter gallery is free, additional galleries are in-app purchases. The number of puzzles is indicated for each gallery so that the buyer knows what they are getting for their dollar. 

I also provide clarity through a version description list that indicates what changed or was added in each version. This list is not just “spin” on the good stuff, but also transparently discusses any bugs that were fixed. 

Another nod to the norm of clarity was designing  configuration items to be self-explanatory, so that one could understand the settings without needing to refer to the help page. 

Often I think a design is clear only to see a user struggle. The norm of clarity probably requires some user studies or focus groups to know if you really hit it well (or not).  Next up, harmony.

Harmony

The design norm of harmony puts weight on the integrity and aesthetics of the design. Form should follow function. I aimed to satisfy this norm by keeping the visual User Interface (UI) focused on solving puzzles. I added a consistent visual and text theme built around the idea of the puzzles being artwork that needed to be restored. 

The solved puzzles themselves also provide an aesthetic aspect as they exhibit natural beauty, such as the Tree of Life gallery. They also exhibit constructed beauty, such as the Clothing gallery or Architecture gallery. 

The norm of harmony honors beauty, but particularly beauty that is more than skin deep. For engineering designs, that means more than cosmetic features. Thoughtful designs have a beauty integral to  their function, rather than a facade hiding their fundamental structure.  Next up, last example norm: caring.

Caring

The design norm of caring puts weight on a design that shows kindness to all stakeholders. One way I hoped to show caring through my app was by enabling Family Sharing on in-app purchases. This allows family members to share purchased puzzle galleries. 

Another means of care came to mind when generating puzzles of living creatures. I realized my wife would likely not want to see certain living creatures, so I created a Creepy Crawlers gallery to clearly signal the contents — for those that dare look!  

I also kept an eye on accessibility.  Some of this is provided by Apple inherently, such as the ability to enlarge fonts (for those with poor eyesight) and control audio volume (for those with poor hearing). It doesn’t come completely “out of the box” to the developer however. For example, I had to ensure I did not unintentionally prevent larger fonts in my app view (which I did in a few cases until I tested specifically for this). Further improvements included an intentional design choice to consistently pair visual and audio feedback, so that hopefully one or the other was noticed.  For those with poor dexterity, I included an option to make the puzzle grid cells larger.  

While I was implementing a feature to help those playing color puzzles, I realized this could also help those who are color blind. Although I purposely encode pictures to include some visual distance between the puzzle colors, these can still be a bit difficult to differentiate. I thus added a feature to allow customizable colors. Once I had done that, a little research revealed that someone had looked at this problem of distinct colors. Alexandr (Sasha) Trubetskoy was working on displaying subway maps and wanted to give each line a distinct color that most people could easily distinguish from the others. He developed a handy list of 20 colors (https://sashamaps.net/docs/resources/20-colors/) The 20 colors are carefully sequenced so that you can take any number of colors from 2 to 20. As long as you start from the beginning of the list, the colors will be maximally distant in perceived color.  

He further did the world a service by looking at the population with color blindness. His list of 20 colors covers 95% of the population. A filtered list that works for 99% of the world’s population reduces the list to 16 colors. Further filtering for 99.99% reduces it to 7 colors. I used this data to provide a “maximal distance” color list that can be used as a custom option for the nonogram color puzzles in the app. A design that provides color schemes that work for those that are color-blind is a design honoring the norm of caring.

These examples for four of the design norms demonstrate how faith principles can influence technical design decisions. This engineering with integrity honors God. Furthermore, I think engineering itself is not only pleasing to the engineer, but pleasing to God.

The Pleasure of Engineering

The 1960s and 1970s saw a flourish of anti-technology writing, from the likes of Jacque Ellul, Lewis Mumford, and others. Samuel C. Florman, an engineer by trade, wrote a famous counterpoint to this position in his 1976 book <i>The Existential Pleasures of Engineering</i>.  While I recognize the dangers of technology and appreciate the warnings from Ellul and others, I also resonate with Florman’s point.  Engineering is an essentially human activity involving creativity, aesthetics, and human values (as we saw in the previous section).   

In the movie <i>Chariots of Fire</i>, the character Eric Liddell is a devout Scottish Christian who is competing in the Olympics. He says: “I believe God made me for a purpose, but He also made me fast. And when I run, I feel His pleasure.” Those of us called to engineering are also made by God for a purpose. He made us creative and gave us strong math and science abilities. He made us problem solvers. And when we engineer well, we should feel His pleasure.

While developing LogiSketch, I brought those typical engineering skills to bear. What surprised me was that many further skills were marshaled as well. As I wrote about in another blog (TBD: link), I have become an amateur biologist using the iNaturalist app. The pictures I took of hundreds of unique species became images in my Tree of Life gallery of monogram puzzles. My lifelong interest in architecture was sparked anew as I created an Architecture gallery, so that I needed to brush up on the different architectural styles. I reviewed to make sure I didn’t mix up Art Deco and Art Nouveau, to make sure I placed Early and High Gothic examples correctly. It was gratifying to find that my interest in photography and in travel paid off with quite a few photos that turned into puzzles in the Architecture gallery.  I got much better using Gimp (an open source photo editing tool). I also was able to exercise my love of music, composing some short pieces as background music for some of my YouTube Shorts to use for marketing. I enjoyed this mismash of different skills necessary, and more importantly, I think this work glorified God.

Do You Please God in Your Engineering?

How do you make your faith real in your work? In the actual output? In the work of your hands, not just the words of your mouth? Are you using your employment and career as a means of witnessing? Good.  Are you also using your career to glorify God through the actual engineering design work? God is pleased when his children cultivate and develop the creation as good stewards. He is pleased when an artist completes a gorgeous painting, when a musician composes a beautiful score, and when an engineer designs a beautiful, effective product.

Are you noticing the decisions you make during design and development of your product, or are you just doing what comes to mind first? How does that impact your responsibility and accountability? 

---

Sidebar: Tools I Used

In case you are interested, here is a list of tools I used during development of the LogiSketch app. It is not quite exhaustive, but I think I have captured most of the key ones.

Music and sounds

• Garageband

• Piano (yes, the physical musical  instrument)

• AutoPiano

• Apple QuickTime

Visuals

• SF Symbols

• LibreOffice

• Photo editing

• GIMP

• ImageMagick

• sips

• Apple Preview

• Apple background remove

• iMovie

• Photo sources

• My own photos on iNaturalist

• Photos with suitable licenses from Wikimedia Commons 

Themes, titles, descriptions, gallery categorizations

• Gemini 

• ChatGPT

• Perplexity

Software Development

• Xcode

• pytest

• ruff

• pyright

• swiftlint

• Visual Studio Code

• Claude 

• git

• xcbeautify

---

Design Norms for LogiSketch -- Part 1: Decisions, Decisions

Part 1: Decisions, Decisions

I’ve designed and released a few apps for iOS over the years, but I’ve never developed one by request – until now. Pam, my wife, likes brain game apps, from CandyCrush to Sudoku and more. One genre that has her hooked lately is Nonograms. However, none of the apps she tried were quite what she wanted for gameplay. When I retired in April, she asked if I might consider developing a better Nonogram for her. And thus I started work on my first  commissioned app, which I would ultimately name LogiSketch.

While this would be an app dedicated to my wife, I also aimed to place it in the App Store so others could enjoy it as well. Whether designing for one customer or a million, this work provided an opportunity to think through practical implications of my Christian faith on engineering design.

For context, let me briefly describe nonograms. A grid of cells represents a picture once the correct cells are filled in. The picture is quite blocky, but a good puzzle produces a recognizable drawing. The challenge is knowing which cells to fill based on clues. Each row has a set of number clues and each column has a set of number clues. The numbers represent the number of cells in a row that are filled in.  For example, if the row clues are “2 4 2” that means that row contains a run of 2 blocks, a run of 4 blocks, and a run of 2 blocks. We know there is at least one empty cell in between each, but do not know whether there is more than one.  If the row happens to be 10 cells wide, then we would know for certain that only a single empty cell can separate them, since that adds up to 2 + 1 + 4 + 1 + 2 = 10, the total width.  But if the row is 15 wide, now there are many possible combinations, requiring more sophisticated logic to solve. 

With that quick background, let’s look at three interesting obstacles I faced during development and how each turned into an opportunity.

Three Challenges

During development of the new app, I encountered plenty of issues to solve, but I’ll highlight just three of them here. One challenge was a problem of scale for the developer; another was a problem of scale for the user. The third challenge was the difficulty of measuring difficulty.

Challenge 1: Developer Scale

The challenge of scale for me, the developer, was designing a large number of interesting, solvable nonogram puzzles. A strong player could solve multiple puzzles a day, meaning I needed hundreds or probably thousands of puzzles available. Designing them all completely by hand would be onerous. Like any good software engineer, I turned to automating as much of that task as possible. 

Solving the problem of generating a large number of puzzles by using automation also led to one of the distinguishing features of the app: all puzzles would be generated from real photos. This in turn addressed a deficiency Pam had noticed in some of the other nonogram apps. When she finished some puzzles, it was difficult to determine what the picture actually represented. The pictures are of course very blocky, so simply knowing what it should be often is enough to trigger visual recognition. So I would do both: reveal the source photograph and name the subject. This approach was also the genesis for the theme of the app: a museum. Each picture is revealed as if it is framed art. Collections of puzzles are called galleries, wings, and so forth. 

Converting a high resolution image thousands of pixels across into a blocky image dozen cells across did not work well with my first attempt, nor my second. It took many tries to get it right. I wrote the puzzle generator code in Python, allowing a quick turn around for trying out ideas since it is an interpreted language that can be run immediately, rather than waiting for a compile. In addition, there were existing libraries for image processing, solving algorithms, and more. I experimented quite a few times to narrow down the sorts of image pre-processing, filtering, and post-processing that could do the job. I did some simple Design of Experiments (carefully selected variations of the driving parameters to identify which most influenced the end goal of a recognizable, uniquely solvable puzzle). Even with all this, I still ended up with dozens to hundreds of candidate puzzles from one image. So I also designed a Python tool to help me quickly review the candidates and down-select. This means the final puzzles are all still checked by hand. 

I also wrote some Python code to use the Z3 solver to ensure the puzzle was uniquely solvable. Since the puzzles are created from a picture, I start with the solution of filled-in cells, then reverse engineer the row and column clues. If the solver cannot find a solution based on those clues, something is wrong (since we *know* there is a solution). After working out a few bugs, the solver consistently confirms the puzzle is solvable. But then I add that first solution as a constraint and have the solver try for a second solution that does not match the first. If it finds one, the solution is not unique and I throw out that particular puzzle variant.

Every puzzle is listed in a gallery with a title and description that intentionally avoids directly naming (giving away) the subject. This adds a bit of mystery for the player to uncover using the numerical clues at first, but perhaps the narrative clues as the subject comes into view. For thousands of puzzles, I used some support from AI to generate candidate clues, though it took a bit of prompt engineering to get strong candidates (fun, interesting facts about the subject without directly naming it). This worked well over 90% of the time, allowing me to quickly choose a candidate title/description and do a bit of final copy edit. Some of the AI descriptions surprised me or made me suspicious. I needed to carefully review and fact check in any questionable case, which occurred perhaps in 1 out of 10 descriptions. Where none of the AI-generated candidate descriptions were suitable, I filled those in myself.  

I now had the means to generate thousands of quality puzzles, with a variety  of sizes.  The largest ones posed the next challenge, this one a customer-facing obstacle that my puzzle solving users would run into.

Challenge 2: User Scale

The second challenge was also of scale, but now for the user. Many of the existing nonogram apps are limited to puzzles that are at most 15 cells wide or high. I wanted  workable game play on puzzles of that size, but also for much larger puzzles that did not fit on a small screen. 

My first thought was to make the cell size configurable. That gave me only minimal benefit, going from a puzzle 10 cells across to a puzzle 15 across. Anything larger and the cells became unusably small. I kept the cell configurability for accessibility reasons, but continued looking for a better solution for large puzzles.

My puzzles would be as much as 100 cells in either or both directions. My next solution was to allow the puzzle to be scrolled, so that you still had a manageable 15x15 grid at any one time in view, but it could now be part of a larger puzzle. A small “minimap” feature then allowed the user to see the entire picture forming anytime they scrolled to another region of the puzzle. That solved the main problem.

However, sometimes solving one thing breaks another. Scrolling is intuitive on mobile devices: one simply drags with one finger on the screen. But for the apps with a fixed small puzzle, they usually used that one-finger drag gesture to allow the user to easily fill a string of cells along one direction. I tried a couple different approaches with feedback from my trusted tester. I ended up using the pinch-out gesture for filling many cells at once, and this also allowed filling a block, not just one row or one column at a time.

Now I could provide a nice variety of puzzle sizes. Two refinements arose during subsequent testing. First, Pam found that when scrolling across a large puzzle, it was hard to keep track of which row you really were looking at, since you could no longer see the edges where the clues were. I solved this by adding a feature to lock a row (or column) so that its clues were visible even when you scrolled away from an edge.

Even with this, I wondered: would some users still find the gargantuan puzzles just too daunting?  It would be nice to give them an optional approach. This reminded me of an old riddle. 

How do you eat an elephant? 

One bite at a time. 

This led to the other refinement, a “panel” feature. As an option, the user can solve the puzzle in panels that are 10 or 15 cells in each direction, with clues for only the active panel. That also gives a better sense of progress knowing you have some panels finished.

I now had a collection of quality puzzles with a wide variety of sizes. This is when I noticed that other nonogram apps treated large puzzles as harder. But that turned out to be only part of the story.

Challenge 3: Measuring True Difficulty

I became aware of the third challenge while working on the second challenge of large puzzles. Although large puzzles take longer to fill in, that does not mean they are intellectually more difficult. Some large puzzles can be solved with rudimentary methods; some small puzzles require much more sophisticated solution techniques.

I browsed several existing nonogram apps and found that most of them simply labeled larger puzzles as harder. This is partially true – a larger puzzle has more cells to fill. But that is not the whole story. I thus set out to find a better difficulty metric that was not tied solely to size.

My first attempt at a metric tried to re-use my existing code with the Z3 solver. I simply measured how hard the solver “tried” when solving the puzzle. But the Z3 solver is not all that smart; it is simply exhaustive. The number of possible solutions it tries can quickly number  in the millions. On a decent laptop the solver  can finish in sub-seconds for a small puzzle, minutes on a large puzzle. But exhaustive search of the solution space is not the way humans solve a puzzle. I needed something more realistic as my difficulty measure.

To get a more realistic measure of the human difficulty, I turned to some of the nonogram tutorials on the web. These provided the typical strategies that a beginner, intermediate, or advanced player might use. This was just what I needed. I coded these strategies and then categorized my puzzles based on whether they could be solved only with easy methods, only with easy + medium methods, or required the hard methods to solve. After several rounds of refinement, I found that very few puzzles could be completely solved with only the beginner methods. In order to roughly divide my puzzles into three buckets, I adjusted my metric so that if a large fraction of the puzzle could be solved using the beginner methods, then I would rate it as easy. If a large fraction could be solved with beginner + intermediate methods, I would rate it as medium. The remainder of the puzzles I then rated as hard.

Hidden in each of these challenges were decisions, selecting one approach among many possibilities. That selection was not based solely on what would work, but what would work best. Defining what we mean by “best” is the point of the rest of this article. Let’s start with the traditional way to compare and judge design alternatives: design criteria.

Decision Criteria

The prior section described three challenges that required some design decisions and refinement. And that is how any engineering design goes. Almost all problems we solve have more than one solution. We must thus weigh the different approaches based on something more than simply “it works”.

Beyond correctness, other factors we consider are sometimes more formally called design (or decision) criteria. These criteria typically include factors such as cost, time to market, maintainability, recyclability, safety, and more. 

These criteria are all good things. But they sometimes conflict. Improving one can degrade another. For example, we can improve safety in an automobile design by including more metal in the frame, which acts like armor to protect occupants during a crash. But that extra armor increases the initial cost of the vehicle. It also has ongoing costs, for the driver via decreased gas mileage and for all of us through a bigger environmental footprint. And so it goes. The design team must balance the various “goods” in their design. Some engineering disciplines (such as software engineering) sometimes fall into the trap of thinking the first solution imagined is the only one and miss that there are important alternatives that should be considered. Every architectural pattern, library choice, and error-handling scheme involves tradeoffs. Choosing the first solution that comes to mind isn't the absence of a decision. It is simply an unexamined one.

Once we have identified the decisions we must make, and then identify the design criteria that should help us weigh and balance alternative decisions, the heavy lifting is done. The next step, actually making the choice, might seem rather mechanical and deterministic. Some might even use a decision matrix to tabularize the decision. But even if we use some math or spreadsheets to apply our weights, the decision is never purely mechanical and never predetermined. Those criteria represent our values, individually and collectively. The weight we put on factors such as safety or cost expose what we see as important in life, uncovering our world view as we make the more difficult trade-offs. 

Because these engineering design trade-offs depend on our values, our Christian faith must come into play directly in our work. Not just how we behave around co-workers. Not just in how we talk.  Directly in our engineering decisions.  Since it is rare for a single engineer to make all decisions about a product, these value judgments usually get decided as a team. When we surface these decisions and the values that drive them, making them explicit, we also uncover an opportunity for witness. It is an opportunity to talk about values arising from faith. 

This is the end of Part 1. I hope these ideas come to mind during the next design project you tackle. I encourage you to look for the decisions inherent in your work. Furthermore, recognize the opportunities to apply your faith and witness in a winsome way that benefits both your product and your co-workers. In part 2 I’ll suggest some additional criteria that you won’t often see in an engineering textbook, but are important to consider when looking at the full perspective of an engineering design. These are the so-called design norms. We will look at applying a few of them (justice, clarity, and more) to the development of the LogiSketch app.

High-Fidelity Discipleship: What Engineering Taught Me About Modeling Christ

In 1970, when Apollo 13’s oxygen tank exploded, the first explanations were not enough to tell NASA exactly why a mission designed with careful engineering had suddenly turned into a life-or-death emergency. Engineers had to dig deeper than the original assumptions and rebuild the problem with more faithful hardware analysis and testing, tracing the disaster to a chain of real physical effects in the tank’s wiring, heating, and ground-test history. That shift from a rough picture to a higher-fidelity model exposed the root cause and guided the redesign that made later Apollo missions safer. (NASA, “Report of Apollo 13 Review Board, https://ntrs.nasa.gov/api/citations/19700078913/downloads/19700078913.pdf)

Modeling Diodes

When I was a professor teaching at Calvin University, one of my favorite courses to teach was ENGR 204 “Introduction to Electronics”. This was a sophomore level class taken by all engineering disciplines (not just the electrical engineering students). For much of the semester, we studied basic concepts of voltage and current and simple linear devices such as resistors that related voltage to current by a constant proportion:  

voltage = current * resistance

Whether the current was big or small, the voltage is always a fixed multiple of the current. 

Later in the semester we briefly examined a more challenging device, the diode. Although the diode was one of the simplest of the semiconductor devices, it was still a challenge – because it was non-linear.  In this case, current is no longer related to voltage by a simple scaling factor.

You can see the non-linearity in the diagram. Watch what the current (vertical scale) does as the voltage increases going to the right. At first, increasing the voltage has no effect on the current, it remains zero. But as the voltage further increases, suddenly at around 0.7 volts, the current starts rising. But it does not rise in proportional to voltage – it takes off with a vengeance! This is the non-linearity in action. Such unusual behavior made it difficult to use the tools for circuit analysis that the students used thus far in the course.

To cope with this oddly behaving electronic device, I then gave a lecture on modeling. I do admit we actually had been modeling the electronics all along. Even a resistor is not precisely, mathematically linear. But it is close enough for most purposes. Now we needed to explicitly recognize that the model was not the reality.

In my lecture on modeling of diodes, I presented four different models:

• Ideal (switch) model
• Battery (constant V) model
• Battery + R (linear V-I) model
• Shockley Diode model

The first model is very simple, but rather inaccurate.  Each model in the list gets progressively more difficult to apply, but it also gets progressively more accurate.  The last model, is a non-linear equation and rather difficult to apply:

What I hoped they learned was that choice of model is a trade-off. More fidelity is more work. The simplest model is very easy - one can analyze diode circuits on the back of a napkin. The better models take more work.The higher the fidelity (the closer the model represents reality), the harder it is to calculate. But the higher cost comes with a payoff – we get closer to the complex truth of the semiconductor circuit behavior.

Modeling Computer Hardware

Modeling is not just for students. When I was a computer engineer working at Boeing, I designed software for the flight computers. Safety critical software like this must be thoroughly tested. Software developers from other industries are often astonished at the level and rigor of testing to ensure the software is correct. 

Although there are some tools to check software without running it, usually we need to run the software in order to test it.  The challenge is often that there is not enough computer hardware to do the testing. This is not as big of an issue when writing software for a laptop or mobile device. However, for devices that are behind the scenes or under the hood, the specialized hardware is often in short supply before the product goes to full production.

Even with my iPhone app development, sometimes I want to run a bunch of tests in parallel, but I only have one iPhone. Thus we turn to simulated hardware. Modern laptops are powerful enough that they can simulate the operation of a computer processor so that we can run our software virtually in order to test it.

However, these simulations are models of the hardware, they are not the real thing. In safety-critical industries, this difference means certain tests *must* be run on real hardware. Which tests? The tests where we cannot be absolutely certain that the simulated behavior will match the real behavior. 

One example of such an area is where we need a deterministic worst-case timing response from a multicore processor.  Each core might be running a different application. One of the cores running an important calculation may need to finish within a certain time frame in order to maintain safety. However, the other cores can sometimes interfere because cores share memory and certain other features of the hardware. It turns out that even the best simulation and virtualization tools today do not fully capture the nuances of those interactions between cores. We thus turn to the more expensive testing on the real hardware in these cases – because we need to be absolutely sure.

Modeling Christ

Modeling is not just for engineers. As followers of Jesus, we are repeatedly told to imitate (i.e., model) him.

“I have set you an example that you should do as I have done for you.” (John 13:15)

“Whoever claims to live in him must live as Jesus did.” (1 John 2:6)

“In your relationships with one another, have the same mindset as Christ Jesus:” (Philippians 2:5)

It is also clear from scripture that this will not be easy. The highest fidelity requires a lot of work and even sacrifice. Peter tells us this: “To this you were called, because Christ suffered for you, leaving you an example, that you should follow in his steps.” (1 Peter 2:21) In his letter to the church in Ephesus, Paul also says so: “Be imitators of God, therefore, as dearly loved children and live a life of love, just as Christ loved us and gave himself up for us as a fragrant offering and sacrifice to God.” (Ephesians 5:1-2 NIV)

Take Away

Engineers learn to “get it done”. We find the most efficient way to accomplish the requirements. We are not looking for the easy way out so much as we are finding the way that costs the least. We try to avoid making a mountain out of a molehill. 

In that electronics course, I taught my students to use the model that fits the need, not spending more time on a harder model if you did not need that level of fidelity. But this thinking must not unduly influence our spiritual walk. When we model Christ, we must not seek the least costly solution. We must be willing to do the hard work of discipleship. We reach the highest fidelity, and most closely emulate Christ when we put the sins in our life to death and live our new life in him. 

Isn’t it ironic that we image bearers – the imago dei, made in the likeness of God – need to be reminded to bear the image? “For those God foreknew he also predestined to be conformed to the image of his Son, that he might be the firstborn among many brothers and sisters.” (Romans 8:29)  We are children of the King – start acting like it!

How Safe is My Castle?

Castles on the Rhine

One of the highlights of a Rhine River cruise occurs on the middle portion of the tour. As the river meanders back and forth down the valley between France and Germany, castle after castle appears on the heights looking down on the aquatic highway of commerce and travel. The soaring towers and arched walls are beautiful, ancient relics. 

Castles protected the domain of a duke or lord, allowing him to command a region of the valley. They offered protection during an attack from his enemies. The predecessor of the castle was the wooden palisade, providing a reasonably sturdy fort against the attacking enemy. Until the enemy came with battering rams and flaming arrows. Like the third little pig, the fortification designers turned to brick and stone as a stronger material than wood. The duke could rely on stone bulwarks to keep him and his subjects safe.

How safe was the castle? Though the stone could withstand flaming arrows easily, it still had certain vulnerabilities. If the enemy couldn’t penetrate the walls, they could go over them. They could run up to the wall with ladders and quickly climb to the top. Even with defenders shooting at them, a large enough force could eventually surmount the walls. 

Even then, engineers realized that any single point of failure was not acceptable. This led to the invention of a moat to surround the walls, slowing down any would-be invader sufficiently to repel the attack. The necessity of entry and exit created a permanent structural vulnerability—a weak point that required further innovation. The invention of the portcullis helped fortify this gap. The portcullis was a metal grating that could be lowered into the archway to prevent entry. 

The degree of safety all depended on people. The lord of the castle had to trust that the architect planned it well and that the builders constructed it with proper materials and technique. One slipshod use of materials could weaken a wall, making it vulnerable. He had to trust the guards who stood watch over the gates at night. One bribe might let the enemy slip inside during the night watch. The lord of the castle would be making a grave mistake to believe that the physically imposing structure by itself guaranteed his safety. He would be putting his trust in something that seemed reasonable and tangible, but ultimately the wrong foundation on which to place his trust.

Stone bulwarks provided a tangible sense of security in the past. Even further in the past, humans trusted in technology to protect them, such as military grade carts and horses. But then as now, perhaps their faith was misplaced. “Some trust in chariots and some in horses, but we trust in the name of the Lord our God.” (Psalm 20:7)  Let’s take a closer look at our own personal safety in light of scripture.

Personal Safety and Scripture

My home is my castle; my body is my temple.  These are metaphors of physically imposing structures that imply stability and safety. We all want to feel safe in our own homes and feel safe from bodily harm.

In contrast, the Bible points us away from ourselves. Even though self-preservation is our natural instinct, the urge to preserve ourselves can lead to sin. Pursuing our own safety can lead to the sin of pride by putting ourselves before God and others. It can lead to the sin of idolatry by putting something else powerful in place of God to give us (the illusion of) safety, such as  money, power, or technology. The problem is not the desire for safety by itself – the problem is who or what we trust to make us safe.

Safety is most often described in scripture as finding our refuge in God. God tells us to change the direction we turn for self-preservation. Instead of focusing on ourselves or earthly things, we must focus on trusting him. I suspect this is one way of honoring the greatest commandment, to love God with all our heart, soul, and mind. That is, love is not just a feeling of our heart, but the trust we place with our mind.

Engineering a Parapet: Safe Designs for My Neighbor

The second greatest commandment gives us another twist on how Christians should think about safety. Our urge for self-preservation was turned upward to trusting in God, now it is turned outward as well. The commandment to love our neighbors as ourselves means that we must preserve our neighbor as much as we preserve ourselves.

Engineers can do a lot to preserve the safety of our neighbors. We can improve their physical well-being and reduce their risk of harm through the technology we design. We can also be mindful that our technological products themselves could harm our neighbor. I have mentioned this passage in a previous blog “Running with Scissors” but it is worth repeating here: “When you build a new house, make a parapet [low guard wall] around your roof so that you may not bring the guilt of bloodshed on your house if someone falls from the roof.” (Deuteronomy 22:8)

Clearly we are responsible for the health and welfare of our guests. If our belongings, including our technology (such as rooftop terrace) cause harm, we are accountable. As engineers, we should think of our designs the same way: if they cause harm, we take responsibility and work to reduce that harm in the future. Building a higher parapet is building in a safety factor.

Besides concern for everyone using our technology, we engineers can also give extra attention to our neighbors who are most vulnerable to harm. In the Old and New Testament, we repeatedly see that God has a special heart for the defenseless, destitute, and unwanted among us, such as widows, orphans, and foreigners. Most of us live in places that have a capitalistic economy, which drives technology design to cater towards the rich. While capitalism can be very efficient and often fosters stewardship of our resources, it can also devalue the vulnerable who are usually short on cash. 

Thus, it might seem that the only way we can design for the vulnerable is when we pursue it as an altruistic work of volunteerism. It is true that there are many opportunities for engineers to serve their communities near to home or around the world. However, I wonder if we could think deeper, based on a presentation I once heard at the national conference of the American Society for Engineering Education (ASEE). The presenter pointed out that billions of people in the world today live on less than a few dollars a day. He noted an opportunity for development focused on very low-cost technology that could still be attractive to business because of the huge scale (billions of customers). Volunteers might be able to address poverty in a single community.  By creating a technology along with a business plan, helping the poor could be scaled up to global proportions. He challenged the audience of engineering educators to inspire their engineering students to think along these lines. I think we too can think along these lines for addressing the safety of our vulnerable neighbors. That is, in order to provide safety at scale, we need to be particularly ingenious about developing technology with a business value. We need to incentivize mass production to get to global scale.

I suspect our Christian witness speaks most clearly through actions that show love of neighbor. Neighbors that see we care for their physical safety may then be more receptive to understand the second greatest commandment and pass it forward themselves.  That understanding may then cultivate a readiness to understand the greatest commandment: to love the God from whom all good things come.

Epilogue

Although some Rhine River castle sites date as far back as the 12th century, around the 14th century castles no longer provided safety to the monarch and his subjects.  A disruptive technology was invented in China and became a widespread tool of war in Europe in the 14th century: the cannon. Rounded towers replaced square structures because they withstood glancing cannonball blows somewhat better. Eventually castles gave way to star forts, which used sloped, angled walls and shorter, stouter earth and breastworks and stone battlements.

The old castle ruins remained for hundreds of years until refurbished in the 19th century. However, the refurbishments tended to fantasize how a castle should appear, with lofty towers reaching to the sky, large windows, and broad archways that satisfied the whimsy of the romantic period. Thus the castles we see along the Rhine today are beautiful, but do not accurately depict the previous historical structures. The real castles of previous ages were much less romantic but much more defensible. In architecture, a “folly” is a building constructed primarily for decoration, but it is built to look like it has another purpose.  (Headley and Meulenkamp, Follies: A Guide to Rogue Architecture. 1986).  What an apt name for these faux castles.  But also an apt description for our pursuit of safety through our own devices and own power.  It is true folly to place our trust in anything besides our all-powerful and loving God.

One final thought. Safety is a good thing that we seek for ourselves. God does not ask us to stop behaving safely or seeking safe environments. Rather, we must put God above our personal safety needs, and put our neighbor’s safety needs above (or at least equal to) our own. Likewise with other good things: health, justice, prosperity, peace, and so forth. We may rightly seek them, if ordered correctly. We must seek them for our neighbor as much as ourselves, and we must pursue God more than any of these, for God is our greatest good.

Technology Should Recognize Human Frailty

My drone controller has two control sticks. They screw on to the controller near the top. Before I pack away the drone and controller, I must unscrew the control sticks, tuck them into a holding slot and then slide the controller into my drone satchel. Why do they make me go through this hassle each time? Because if the satchel got bumped hard or squeezed between other luggage, those control sticks are perpendicular to the rest of the controller and would be a weak spot that could easily break. During normal use, it would probably be fine, but this ensures no failures even with unexpected rough and tumble. 

What are the chances I drop one of these small sticks while setting up? Maybe I am just clumsy, but in my experience so far, chances are about 1 in 5. I am often out in a remote area to fly my drone, so when I get the controller out, I am mindful to remove and attach the control sticks while standing over a flat, wide surface. That way, if I accidentally drop one, it is unlikely to roll away or fall into a crack. I rarely drop one, but this practice ensures no unexpected failures. 

I see this as a case of the engineering maxim: “Hope for the best, but plan for the worst.”

Planning for the worst means anticipating abnormal and faulty behavior. Such planning is a hallmark of good engineering and is at the heart of safety-critical engineering. While it is relatively easy for me to anticipate the abnormal case of dropping a control stick, many of the systems we engineer are massively complex. Then it is not trivial to enumerate all the ways things can go sideways. As an example, let’s look at modern software.

Modern software is complex

To quantify how big modern software has gotten, I will use the traditional measure – in units of Apollos. That is, if the US 1960s spacecraft had around 30,000 Source Lines of Code (SLOC), then how many “Apollos” is a modern piece of software? The Operating System (OS) on your device (whether a smartphone or laptop) is in the 10s of millions of lines of code, or over 500 Apollos.

Consider the Linux kernel. It has surpassed 40M SLOC. Where does all that code go? The Pareto Principle states that roughly 80% of consequences or effects result from only 20% of the causes. Likewise in many software programs. Only a small portion of that OS code is exercised regularly. Much of it is rarely used, and on any specific machine, much of it may never be used. 

You can see in the Sankey diagram that the lion’s share of the Linux kernel goes to drivers. Many of these drivers are only needed on a select few target machines. (Kind of like in typical church congregations where 20% of the people do 80% of the work!)  

On the one hand, this uneven distribution means that the open source community can focus on ensuring the quality of that central core of the kernel. On the other hand, this means some bugs may lurk in the less used (and thus less examined) code. Whether they are software bugs or design miscalculations, subtle errors can be difficult to detect even with thorough testing, especially when the flaw only presents in unusual corner cases. The behavior of complex engineering systems can be very difficult to predict comprehensively. Even when the individual components are simple, the sum of the parts can exhibit unforeseen emergent behavior.

Beyond the Blueprint: The Secret Life of Complex Systems

Our designs often do not behave exactly as we intend. Abnormal behavior that we do not foresee can lead to unanticipated consequences that cause harm. This lack of foresight can be traced back to two fundamental characteristics of our human identity: we are finite and fallen.

Finite

Engineers who design technology (such as the Linux kernel) and people who use technology (all of us) are finite. Humans are finite – not as a result of the fall into sin – but from the very beginning. God created us; we are creatures. 

God intended the human characteristic of finitude. We are engineered with this inherent design characteristic. Although made in the image of God, we do not share God’s infinite qualities of omniscience and omnipotence. We thus do not have perfect foresight and cannot anticipate all consequences for our designs. Our brains have a limited capacity. 

Even when we augment our thinking by working with teams of naturally intelligent people using tools like artificial intelligence, our collective capacity for foresight is still finite. 

Because every creature, and indeed all of creation is finite, certain trade-offs were necessary even in the beginning, before the fall. Even in the garden of Eden, the design of a bridge would require choosing the right materials, trading off load capacity with total length, and so forth. That finite nature of our materials holds true today: trade-offs are a natural part of the design process.

Fallen

Both the engineers designing technology and the people using it are fallen. Humans are corrupted by sin, and all creation with us. Sin taints our thinking and our desires, and thus it taints our engineering design. Sin taints the thinking and desire of the users of technology.

God did not intend this human characteristic of fallenness. However, when the first humans sinned, although not God’s plan, he provided a new redemptive plan to address the flaw we introduced. 

Until the final restoration, sin taints creation – though it is often hard to separate out the characteristics of creation that are finite  from those that are fallen. To act as Christ’s redemptive agents in this world today, we require the discernment that comes from the Holy Spirit so that we can identify the original creational good and work to root out the corruption of sin. 

There are many virtues we could bring to bear in designing technology that properly recognizes both these characteristics. As an example, let’s consider the virtue of humility and see how it undergirds one particular avionics technology.

Case Study: Avionics Partitioning

A new avionics standard was published in late 1996. In that year I was an Assistant Professor of Engineering at Calvin College (now University). I wanted to keep my teaching fresh and relevant, so I pursued engineering consulting work during the summers. That particular summer I landed a part-time position at Smiths Aerospace in Grand Rapids. One of my tasks was evaluating the proposed international standard, ARINC 653. Little did I know then that I would continue working with this standard for much of my career. Thirty years later, just before my retirement, I have had the privilege to co-chair the ARINC 653 standards committee.

The ARINC 653 standard was first published in the fall of 1996, but my manager back then at Smiths had an early draft of the standard for consideration over that prior summer. I was part of a three-person team that he asked to evaluate the proposed standard. It would be used on a new powerful centralized avionics computing system. The new approach would consolidate numerous legacy federated computing systems into a single Integrated Modular Avionics (IMA) platform. Since each federated system was a separate box in the aircraft with its own power supply, enclosure, and connectors, this consolidation would substantially reduce the Size, Weight, and Power (SWaP) needed to execute all the software on a modern aircraft.

The substantial reductions in SWaP provided by IMA increase the range of the aircraft while reducing its cost. The drawback is that software previously segregated on physically separate computers is now integrated on one. This raises the possibility of unanticipated interactions between independent functions. The ARINC 653 standard, coupled with another standard, DO-297, describes how to continue segregating independent functionality using robust partitioning. 

System engineers map each independent software program to a partition. The partition is allocated a certain portion of the resources. The resources are provided by the computing platform, but shared among multiple partitions. This sharing can be done in one of two ways: time partitioning or space partitioning.

Time partitioning gives a partition exclusive access to a resource but only periodically. Think of a teacher who gets to use a classroom for a 9am class, but gives it up at 10am. Likewise, the partition gets to use a processor core for the first 10ms of every 100ms, but gives it up for the rest. 

Space partitioning gives the partition continuous (rather than scheduled) access to a resource – but not the whole resource, only a portion of it. Think of a student who gets one locker out of a bank of lockers, but has exclusive access to that one locker whenever they want. Likewise, the partition gets to use certain pages of memory that contain its data, which no other partition may read or modify.

Partitioning as Design Humility

By partitioning all shared computing resources in time and/or space, we can have high confidence that one partition cannot influence the intended behavior of another partition. Avoiding unintended interactions and reducing the chance of unanticipated changes in behavior is important for safety-critical systems like avionics.

Partitioning demonstrates humility in our design. As an engineer of any stripe, but especially a Christian engineer, I ought not put undue confidence in my own ability to comprehend complex systems and foresee all the ways things could turn out. 

Partitioning is a way to recognize my finite nature. By segregating each independent function, I can now simplify my analysis by restricting myself to thinking about that function alone – knowing that the other functions cannot impede or alter the function I am examining. I might not be able to wrap my finite mind around 50 complex software programs all combined into one monolith, but I have a fair chance at comprehending each one individually. Partitioning allows me to divide and conquer.

Partitioning is also a way to recognize the fallen nature of humanity. A negligent or malicious design of one function is now isolated in a partition so that it cannot harm the operation of other partitions.

Conclusion

If you are an engineer, whether designing software, automobiles, bridges, or some other technology, consider humility not only as a personal virtue, but one that can become part of your work as well. Humbly consider all the ways you yourself could be biased against seeing a flaw. Humbly consider all the negligent and malicious ways a user could abuse the product beyond its intended use. Designing technology in humility makes it safer for all. If our systems are too big for any one mind to hold, is it arrogant to build them without partitioning (or equivalent)?

Welcome to the Fishbowl: Do we have the Right to Privacy?

A distraught woman wrote Dear Abby, worried that she had made some unflattering comments about her daughter-in-law to her son. 

She got caught because the comments were recorded on their Ring doorbell, which the daughter-in-law heard later. The famous advice columnist replies that the mother-in-law has “learned the hard way that in our technological society, privacy is history.” 

We can no longer assume our conversations are private at someone’s doorstep. Before 2013 we assumed our phone calls were private. But then Edward Snowden debunked this misplaced trust. He leaked information about a government program to collect broad swaths of data regarding the phone calls of its own citizens. The existence of such programs was previously denied by US intelligence officials. James Clapper, Director of National Intelligence, justified his original denial that the government collected such broad data by explaining he was forced to use the “least untruthful” statement in order to keep the program secret. After the program was outed, some of the same officials told the American public not to worry – they weren’t actually listening in on our phone calls, merely recording the time and destination of the call. However, given that officials  felt compelled to tell “untruths” about the programs in public testimony before Congress, it was hard to discern whether the later statements might be true or again, the “least untruthful”. Stories about our lack of privacy seem to come out weekly. We are being watched: by social media, by CCTV, by drones, by doorbells, and more.

Stories of close electronic scrutiny in our everyday lives remind me of “The Dead Past”, a science fiction short story by Isaac Asimov. The protagonist is a historian, desperately trying to gain access to a chronoscope (a sort of time machine that lets one see any location in the past), in order to study the history of ancient Carthage by direct observation. However, the instruments are controlled by a heavily bureaucratic government. After years of red tape and rejections, he builds his own chronoscope -- only to have it quickly confiscated by government agents. It turns out that the instruments have poor resolution and cannot look very far into the past. The government keeps the machines under lock and key because they realize the implications for privacy:  the past begins immediately after the present. Thus, one can observe another’s private behavior in the past, but the past is simply moments ago. That is, the instrument observed events in nearly real time. The past was not so dead after all!  The story ends with the inadvertent publication of simple instructions for building a chronoscope and thus privacy is destroyed for all: “Happy goldfish bowl to you, to me, to everyone …”. 

An NSA program to spy on the public is the first step to living in such a fishbowl. Face recognition technology and ubiquitous recording devices give many public and private institutions an extraordinary amount of intelligence about the ordinary citizen. When only privileged people in power have access to this intelligence, such power can easily be abused. It is thus worth examining more closely what precisely is the nature and origin of the so-called “right to privacy”. 

Cultural Origins of the Right to Privacy

The US Constitution does not have an explicit right to privacy. However, over the last century US courts have interpreted several clauses in the Bill of Rights to include privacy, particularly the 4th Amendment’s prohibition against unreasonable search and seizure and the 14th Amendment’s prohibition on limiting one’s liberty (extended to include privacy) without due process of law. Other nations have followed suit, giving limited privacy protections to citizens because such benefits have been collectively endorsed by society. For example, the Charter of Fundamental Rights of the European Union states that “Everyone has the right to respect for his or her private and family life, home and communications.” (Article 7) and “Everyone has the right to the protection of personal data concerning him or her.” (Article 8)

There are legitimate reasons to keep personal information confidential. Privacy helps prevent identity theft. Privacy prevents stigma because of medical conditions. Privacy protects intellectual property, such as a trade secret – the “secret sauce” ingredient in a company’s flagship product.

The secrecy of our data is valuable to us because of the potential harm that comes with its public release. It thus represents a kind of power. Identifying information enables us to conduct business and obtain services. We share certain information with selected organizations in order to confirm our identity. As long as only the two parties (you and the selected organization) know that information, it serves as your ID. 

However, once you or any of those organizations lose control of that information and it falls into the wrong hands, your ID is no longer secure and others can successfully impersonate you online. Thus a thief who steals your identity holds power over you. Likewise, an unscrupulous person who learns of your confidential medical condition could use the power of that information to blackmail you, shaking you down for cash or favors in order to keep the information from going public. Stealing intellectual property such as an invention idea is truly theft because it robs the owner of the full value of the idea.

While this section briefly outlined the social foundations of the right to privacy, it is also worthwhile for Christian readers to consider whether biblical foundations also support privacy.

Biblical Origins of the Right to Privacy

It turns out that scripture doesn’t have much to say about privacy. First, let’s look at a couple spots that hint at privacy but really seem to be about something else. 

We could perhaps infer such a right from the commandment against stealing, interpreting stealing to include the theft of someone’s intellectual property. However, that may be a stretch, since this commandment seems more about justice than privacy.

Another place where we might infer a right to privacy is the Sermon on the Mount. Jesus exhorts us to keep certain acts secret (out of the public eye), including our giving  (Matthew 6:3) and our prayers (Matthew 6:6). However, in both these cases, the purpose of privacy here is not about the power of someone else because they know confidential information. Rather, the purpose of privacy in these cases is to avoid prideful pretentiousness. Giving or praying publicly is to impress people rather than God. Giving or praying in private is directed toward God instead of fellow humans. 

In the same hilltop sermon, Jesus tells us to avoid judging others, lest we ourselves be judged (Matthew 7:1). His mandate recognizes that we only have a partial picture of our neighbors, and it is wrong for us to judge them without fully knowing their circumstances. Thus, there is an implied value for keeping information about others private and not gossiping about it. Paul repeats the call to avoid judging. “Therefore judge nothing before the appointed time; wait until the Lord comes. He will bring to light what is hidden in darkness and will expose the motives of the heart.“ (1 Corinthians 4:5, NIV)

Albert Borgmann notes the connection between privacy and judgmentalism:  “...Thomas Huff has helpfully isolated the notion of privacy as freedom from intrusions that can lead to an unwarranted judgment on the person whose sphere of intimacy has been invaded. Of course, our next of kin, who are naturally members of our personal circle, and our friends, whom we have invited into it, are entitled to judge whatever we do. No one else may without our permission.” (Albert Borgmann, Power Failure: Christianity in the Culture of Technology, Grand Rapids: Brazos Press, 2003, p. 40.)  However, Borgmann then observes that we often use privacy to shield our consumerist behavior from the prying eyes of others. “What Huff calls the privacy norm is in large part the collective affirmation of consumption as an exercise of freedom that would be encumbered by judgmental intrusion.” (p. 43)  

Materialism is not the only bad behavior we attempt to keep secret. Most sins are private affairs that would shame us if made public:  adultery, domestic abuse, addictions, and the like. 

Privacy as Cover

Modern technology can afford us privacy in the form of anonymity on the web.  However, this privacy can be used to shroud illicit acts. The shroud can hide the sin or hide the sinner.

Hidden Sins of a Public Person

We are all public persons in one way or another. We may not be celebrities, but we are known, and thus “public” to our friends, family and colleagues. We value what others think of us, so we cultivate a certain public image. When we use privacy to hide shameful behavior that could tarnish our image if it became known, the technology of anonymity becomes an enabler of sin. 

The perception of electronic anonymity facilitates bad behavior on the web, such as online affairs or gambling. Ironically, people may turn to these vices in trying to find fulfillment. Yet the biblical book of wisdom tells us the opposite results:  "Whoever conceals their sins does not prosper, but the one who confesses and renounces them finds mercy.” (Proverbs 28:13, NIV)

Public Sins of a Hidden Person

Some sins are public by their nature. In these cases, anonymity shrouds the perpetrator rather than the sin. 

An example is cyberbullying or anonymous revenge porn, where a break-up leads to an angry man posting risque pictures of his ex-girlfriend that she shared with him when they formerly trusted each other. This sin (of posting the pornographic pictures without permission) is perpetrated publicly while often keeping the perpetrator hidden. 

Why is bullying wrong? ”With the tongue we praise our Lord and Father, and with it we curse human beings, who have been made in God’s likeness. Out of the same mouth come praise and cursing. My brothers and sisters, this should not be.” (James 3:9-10)   The apostle reminds us that the person we bully is made in God’s image. We must treat all humans with the respect due image-bearers.

Using Privacy with Care

Our legal right to privacy is not absolute -- one’s privacy can still be invaded if warranted, i.e., if due process is afforded to ensure the invasion is justified, in the judgment of a fair and unbiased court. This is important to prevent abuse of those rights. 

Likewise, any biblical basis for privacy is limited. And certainly if privacy is a cloak for sin.

• "...And know that your sin will find you out.." (Numbers 32:23)
• “Nothing is hidden that will not be revealed, and nothing is secret that will not be made known. So then whatever you have said in the dark will be heard in the light, and what you have whispered in private rooms will be proclaimed from the housetops.” (Luke 12:2–3)

Accountability to others depends on their ability to regularly observe our behavior. However, privacy allows us to hide our behavior. While there might be legitimate reasons for keeping that communication and data out of the public eye, how do we avoid the temptation to use privacy to hide our bad behavior?  Here’s a check. Would you dare let a trustworthy friend review your past week’s email or web browsing history?  

As engineers designing technology, are we making it too easy for people to live double lives?  Do we enable people to have a public face of righteousness with a technologically hidden face of wickedness?

Our Christian faith should make us cautious when exercising and enabling the privilege of privacy.  Privacy is too often merely a pretext to keep our sinful ways out of the light of day.  “It is shameful even to mention what the disobedient do in secret. But everything exposed by the light becomes visible.” (Ephesians 5:12-13, NIV)