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)

Second Commandment Technology: Part 2

In the first part I made the case that in describing the  second greatest commandment, Jesus defines our neighbor very broadly. Further, I suggested that technology expands our neighborhood significantly. In part two, let’s look at why we should care for our neighbor and then examine a few specific examples of tools helping or hindering us in that endeavor.

Why Should I Care?

Why should I care about the perspective of someone far from me? Or even if they are close, why should I care about others more than myself? I should care because God commands it.  However, let’s look closer. There is some rich depth and consistency to this divine directive if we dig a bit deeper.

Care for Humans Created in the Image of God

I should care about my neighbor because loving God’s creatures honors the creator. In Genesis 1:28, God appoints humans as stewards of his creation. As stewards, we are to love and care for his creatures and cultivate the garden of his creation. Our neighbors deserve extra stewardly attention because in contrast to all other creatures, humans are created in the image of the Creator. Thus, the second greatest commandment (to love our neighbor) is related to the greatest commandment (to love God). We are created in God’s image, so we honor God when we care for people also created in his image. At the same time, that image has been distorted by sin.

Care for Sinners in Need of Grace

I should care about my neighbor because fallen people stained by sin need grace and care. In Adam and Eve, all humans have inherited a sinful nature. On our own we can do no good – we tend towards selfishness and evil. Even our best efforts are marred by our fallen nature. I am called to care for my neighbors even though they are not perfect people. In the story of the Good Samaritan (Luke 10:25-37), the expert in the law wanted to justify himself and asked Jesus: “Who is my neighbor?” Why would he ask this? Did he really not know? Perhaps he was hoping that Jesus would provide some criteria to judge which neighbors were worthy – and which were not. When serving those in need, I sometimes likewise find myself becoming judgemental.

I was too quick to judge when I previously served as a deacon at a church that ran a food pantry. We worked with a county agency to help us identify families in need. Each week one deacon was assigned to make deliveries to those families. Occasionally when it was my turn, I came across a disturbing situation. As I brought the grocery bags laden with food into the home, I noticed that they had a nicer couch and larger television than I had myself. I was dismayed and even a bit angry that a family would take advantage of the system. Nevertheless, I brought the food into the kitchen. That’s when I noticed their cupboards were literally bare. As the family put away the groceries, I could see they had no food – that my delivery was desperately needed. I suspected those expensive items in the living room might be “rent-to-own”. Those expensive items on high-interest loans meant they were likely in too much debt to buy food. 

The point is, we never really know the full story about someone else. Even if occasionally our food pantry served someone that wasn’t needy, I resolved that it was worth being generous to all that were perceived to be in need, even if occasionally it was undeserved. Thinking further, who was I to judge who was deserving or not?  The grace of God is not based on merit – just the opposite! In my sin I am most undeserving, yet Christ’s all-sufficient merit covers my debt. I am not called to love my neighbor because they are deserving; I am to love them with no regard to merit. I am called to love them as fellow image bearers.

That’s not to say we shouldn’t pay attention to justice. If our food pantry had been running low, I might be justified in ensuring the most needy families got fed first.  In my case, the pantry was full. We had food sufficient to cover all who asked. And honestly, my work as a deacon was a lot more joyful and a lot less burdensome when I stopped judging and started serving. When we serve in love of God and neighbor, we are acting as redemptive agents in Christ’s name.

Care for Those We Are Called to Redeem

I should care about my neighbor because I am called to be Christ’s hands and feet in this world. God promised that through Abraham, all nations would be blessed. Two-thousand years later, Christ embodied (literally and figuratively) the fulfillment of that promise. When we put our faith in Jesus and become Christ-followers, we become Christ’s redemptive agents in the world.

Having answered the question of why one should care, now consider how one should care. More specifically, how can we love our neighbor with technology? Technology – whether a tool, process, or algorithm – is always an instrument, i.e., a means to an end. We who design or work with technology can shape and use these tools to love our neighbor. Engineers and scientists are not the only ones to use tools.  Making and using tools is part of what makes us human. Using tools to love our neighbor is one of the finest examples of this creative yet practical aspect of our humanity. 

Tools for Loving Neighbors

Tools and instruments that can be a means to the end of loving our neighbor include those for hospitality, for care, and for stewardship. These are simply examples, with the hope you will notice many of the tools you have at hand can serve similarly.

Tools for Hospitality

Oxford Languages defines hospitality as “friendly and generous reception and entertainment of guests, visitors, or strangers.”  Here are a few examples of technological tools that enable or enhance our welcoming of neighbors.

Homes are hospitality tools. My church recently supported the building of a tiny home community. It is a set of 16 very small homes designed as inexpensive housing for the working homeless in our area. Designed to function as a home in a very small space, they provide hospitality to the homeless – and further, giving the newly homed a space to show hospitality to others.

Electronic communication is a hospitality tool. My wife and I support two missionary couples. One couple posts pictures and stories regularly on social media, helping us stay in touch with the work they do. The other couple is working in a sensitive area where publicity could be problematic. Their choice of communication is thus a bit more selective, posting a newsletter by email to supporters. Both communication technologies connect us  with missionary neighbors who are geographically distant. 

Open source software is a hospitality tool because it encourages sharing and collaboration. By licensing code in this way, software developers create a community of professionals that can build creatively on each other’s foundations.

Instant Messaging is a hospitality tool. My team at work is spread out geographically, with most working from home. We use a variety of communication tools, including MatterMost for instant messaging. One of the channels is named “Water Cooler” where team members can share a bit of their personal lives: gardening, woodworking, music, cooking, latest big purchases, vacation photos, or new baby photos. This channel helps co-workers to be neighbors to each other.

Barbecue grills are a hospitality tool. Technology for entertaining and welcoming guests is not limited to modern, high-tech digital devices. It can be a device as simple as a grill used for the community cook-out.

Tools for Stewardship

Merriam-Webster defines stewardship as “the careful and responsible management of something entrusted to one's care.”  Let’s look at a couple of example tools to help pursue stewardship. 

Citizen science community apps are a stewardship tool. With my retirement approaching, I decided to become a bit more serious as an amateur biologist. I have started using the iNaturalist app to record my observations. The app helps identify the species and shares the recorded sighting with others on the app. I can then see a map of where the species has been spotted. It also enables others to confirm or correct the identification. So far I have identified 270 distinct species (134 at research grade). Using this stewardship tool, I am becoming more observant of the variety of plant and animal life that surrounds me, learning greater appreciation for God’s good and complex creation. This app also creates a community, thus becoming a tool enabling hospitality. Recently I had a more professional biologist comment on my picture of a Meadowhawk dragonfly, noting that the lighting did not allow for them to see the legs clearly enough to identify the specific species. However, like a good neighbor, they did not leave criticism alone – they also advised on additional resources and offered encouragement to continue contributing.

Clean water technology is a stewardship tool. For much of the developing world, finding potable water is a challenge. “Lack of clean drinking water corrodes the critical structure of communities—health, education, business” (Clean Water Institute). In order to keep a well-water system working effectively in developing areas, the replacement parts for maintaining the well and filtering the water must be low-tech. That is, the tools must be appropriate to the neighborhood. By designing tools for stewardship such as clean water technologies, engineers can love many neighbors in far away places. 

Tools for Care

Oxford Languages defines care as “the provision of what is necessary for the health, welfare, maintenance, and protection of someone or something.” We can get some perspective on such a provision from Cornelius Plantinga Jr, in his book Not the Way It's Supposed to Be: A Breviary of Sin. Plantinga defines a concept related to true caring: shalom. “In the Bible, shalom means universal flourishing, wholeness, and delight--a rich state of affairs in which natural needs are satisfied and natural gifts fruitfully employed, a state of affairs that inspires joyful wonder as its Creator and Savior opens doors and welcomes the creatures in whom he delights. Shalom, in other words, is the way things ought to be.” 

 Shalom is thus a deep way of caring for our neighbor. I suggest two tools for caring below. 

Assistive technology is a caring tool. These instruments of care – such as eye glasses or hearing aids – restore human abilities to the way things ought to be. They are tools for restoring shalom. And restoring shalom is a key way of showing Christ’s redemptive love.

GPS mapping is a caring tool. Although I am fairly good with directions, I still rely on my mapping app for most travel. It helps me avoid unexpected traffic snarls and ensures I get to my destination even when I miss a turn. Voice prompts or heads-up displays provide further care by helping me keep my eyes on the road. 

These are just a few examples of tools designed intentionally as means to virtuous ends. Even when the designer had only one good end in mind, we users of technology can creatively find ways to use the tool as an instrument of more diverse virtuous ends. Unfortunately, the reverse is also true, which we investigate in the next section.

Tools for Hating Neighbors

By their nature, tools amplify our abilities – they make us more powerful. Sadly, sin can taint our technology design so that we end up with more powerful means of division and hate. Every tool has tendencies that are built-in, i.e., by design. Some of these tendencies are intentional; some are involuntary. In the former, the designer is consciously trying to bend the design toward the specified use. In the latter, biases and prejudices of the designer sneak into the design.  

A design intended for a virtuous end might also be abused by the user, making it a means to some sinful end. Even when the designer puts safeguards in place to prevent unintended uses, we clever humans often find work-arounds. 

For some concrete examples, consider the following technologies that can amplify the vices of greed, sloth, and malice.

Tools for Greed

Greed is a “selfish and excessive desire for more of something … than is needed.” (Merriam-Webster).  Technology can be easily abused to feed our greed. 

Credit cards are a greed tool. Many have yielded to temptation to buy now and pay later. Purchases are now so easy. Too easy. We don’t always judge carefully whether we really need more. We deceive ourselves and greedily desire more than we need. 

Bitcoin is a greed tool. Originally designed as a digital currency, it has become a platform for speculation. Many now use  it as a tool of greed, hoping that the value will rise like a pyramid as others buy it. 

Malware is a greed tool. Perhaps the most insidious of greed tools, there are technologies designed specifically for greed. For example, malware is designed specifically to extort money from others.

Tools for Sloth

While greed is desiring more than necessary, sloth is the “turning away from the necessary effort” (Merriam-Webster)  

Home automation can become a sloth tool. I have a number of automated devices in my home. 

When I am away from the house, I use these devices for security such as turning on lights or detecting motion and recording on a camera. My connected thermostat dials back the HVAC, conserving energy and saving money. However, this automation can become a little too convenient. Just as the TV remote has made us couch potatoes, home automation further lulls into never leaving the easy chair.

Tools for Malice

Malice is the “desire to cause pain, injury, or distress to another.” (Merriam-Webster)  Although I earlier listed social media as a technology that could be used for virtuous purposes, like most technology, it can also be abused for evil. 

Social media is a malice tool when used for cyber-bullying, spreading lies, or insulting someone. Perhaps worse, some social media sites use algorithms that are focused on increased engagement resulting in emphasis on angry posts.

Cars are a malice tool when road rage overcomes the driver. Some technologies are so dangerous that we, as a society, choose to regulate them. These include heavy machinery and certain chemicals and drugs. Likewise, the automobile is regulated via licenses, insurance requirements, and driver’s license requirements. Regulations help prevent tools being used for malice. But even with regulation, we sinners find a way to abuse the technology, such as when road rage gets the better of us when behind the wheel.

Wrap-Up

Jesus calls us to love beyond those that love us. He calls us to love our enemies, to love those that hate us. My sin-tainted inclinations make it easy to do the former and quite challenging to do the latter. Tools can help – technology used thoughtfully can be an instrument towards loving our neighbors. 

Second Commandment Technology: Part 1

My Peculiar Map

I couldn’t understand what was odd about my map. Working remotely during COVID, I often started my work day early in Grand Rapids to overlap with my globally-distributed colleagues, who were five hours ahead in York, UK. To encourage camaraderie during the enforced isolation, one day our managers encouraged us all to share pictures of our home workstations on the company messaging board. What a variety!  I posted my own setup, proudly showing my laptop with a second large monitor on a sit/stand desk. I had my Galileo thermometer standing in the corner of the desk, and a stylish map of the world on the wall behind the desk. Most of the comments on my setup were encouraging or humorous. But one observation stood out.

A response from a wise colleague in the UK caught me by surprise. He said he couldn’t figure out at first what was odd about the world map on the wall in the background, ending his reply with the enigmatic “...and then I realized.”

What did he realize?  He never did end up telling me. What was so odd about my map? What was he seeing that I was not?  

Here is a photo of that wall map. Later that day I realized the oddity was due to our differing perspectives of the world, literally. Having purchased my wall art in the US, it centered my own country in the middle, even though this placement awkwardly splits the continent of Asia across the edges. A more globally friendly split would have been down the Pacific ocean, so that all continents appeared unbroken on the 2-D rendering.  

What prevented me from realizing why my map seemed odd? In part, it was a local coordinate system error.  My choice of map art literally centered the world around me. Figuratively, I was placing myself at the center of the universe. While most maps—paper or digital—center on the location of interest, a lack of empathy (or perhaps a touch of pride) prevented me from even noticing how literally self-centered my map was.

My Odd Neighbor

As a Christ follower, I am called to love my neighbor. But Christ didn’t really mean for me truly to love someone beyond my immediate family and those that love me, right?  Does it really include my odd neighbor? The one that acts strange? The one that smells funny?  The one that puts up political signs for the party I vehemently oppose? 

But at least I only need to tolerate those that live immediately adjacent to me. Surely someone at work is not my neighbor. Or someone I meet while traveling. Loving a friend makes sense. But does it make any sense to love a stranger or an enemy? They will not likely repay such kindness.

Yet, astonishingly, Christ says to love our neighbors and even our enemies.

The Second Greatest Commandment

Matthew 28 records “The Great Commission” where Jesus tells the apostles to go make disciples of all nations. This commission is often a central tenet in modern church vision statements. Yet this was not the mandate Christ identified as one of the greatest commandments. To first love God and secondly to love our neighbor – these were the greatest. Jesus stated these two as a summary of the law and prophets. (Matthew 22:36-40)

That second command – to love your neighbor as yourself – appears throughout scripture.  In the Old Testament, the command appears to apply to literal neighbors who are of the same nationality:  ‘Do not seek revenge or bear a grudge against anyone among your people, but love your neighbor as yourself. I am the Lord.” (Leviticus 19:18)  

Rather than reading this commandment expansively, the Israelites likely read it very narrowly. By contrast, Jesus ensured we understood this command to love others very broadly, in the story of the Good Samaritan, found in Luke 10:29-37. He also makes this point in other places, such as:  “But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven...If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? Do not even pagans do that?” (Matthew 5:43-48)

Caring for the Alien>

In many science fiction tales, the alien is an intelligent being from another world.  These creatures are so different from us that they seem grotesque and horrific. They look, communicate, and act in ways we do not expect – that do not fit inside our comfort zones of “normal”.  But such differences need not necessarily lead to aversion. We could also experience surprise, or even wonder and curiosity. Many other science fiction tales tell the stories of first contact, of amazement and enjoyment of differences, leading to understanding and respect. The aliens are simply using another perspective, making them seem quite foreign until we understand the translation. It is like the topsy-turvy world of the spherical coordinate system compared to our more familiar Cartesian coordinates. It is like the parable of the blind men and the elephant, where each touches a different part and reaches radically different conclusions about the same animal.

Of course aliens are not just science fiction creatures from another world. The alien at our gates could be a fellow human being from another city, another state, or from the far side of the globe. Even with other people we are prone to notice differences first – in appearance, dress, language, and mannerisms. 

Look even nearer to home and we still have differences. Those closest to us – family and friends – are not precisely the same as us.  The call to love our neighbor is not different in kind, but only in degree when we consider the spectrum of humanity that Jesus calls us to love.  (I’m not sure if there really are aliens on other worlds, but if there are, I’m pretty sure we are supposed to love them too.)

The Hebrew word for “neighbor” in Leviticus 19:18  can be translated literally as the word friend or companion. It comes from the same root as a verb that means “to associate with.” Neighbors defined as associates leads to a rather small circle of those we ought to love.

Jesus expands that circle. The Good Samaritan finds not a close associate lying beaten by thieves on the road, but a sworn enemy. The neighbor is now anyone we come across.  The neighbor is the one who shows mercy. Living in proximity no longer defines our neighborhood. The Good Samaritan did not live near to the victim – he was merely traveling along that road.

More Tech = More Neighbors

Technology is woven throughout our society, and it tends to give us more neighbors – especially when we define our neighbor as broadly as Jesus did.  By technology, I do not mean simply modern computer technology -- I mean all tools that we design. For example, tools designed to stamp out a product: the wine press, printing press, and machine press. Tools designed to transport us from A to B: the wagon, bicycle, automobile, and airplane. Tools to help us communicate: the telegraph, telephone, and the Internet. Technology expands our neighborhood in several ways: who we work with, who we work for, and who we interact with.

Neighbors are the people we work with

Technology has expanded our work networks over the past few centuries. Prior to the industrial revolution, which started in Great Britain around 1760, most people worked in small-scale agriculture such as farmers or laborers – or small crafts, such as a butcher, baker, or blacksmith. This meant a relatively small number of people were one’s co-workers, a handful of folks at most. The industrial revolution concentrated workers, where early factories led to teams of dozens. 

In the modern mass-production society, a factory or a digitally connected corporation puts one in contact with hundreds or even thousands of work colleagues. For example, I am regularly on web conferences (using tools like WebEx, Microsoft Teams, Zoom, or Google Meet) with professional colleagues. They are frequently in different time zones, and often in different countries. Yet they are my neighbors. 

As a Christian who is an engineering professional, my work connects me with yet more neighbors. I have made acquaintances and friends through my work, including at engineering conferences. I recently served as the general chair for the 2025 Digital Avionics Systems Conference, leading a steering committee of volunteers to plan and organize the conference. By offering a forum and venue for exchange of professional ideas, we were providing hospitality to our professional “neighborhood” – a kind of professional block party.  

Neighbors are the people we work for

As an engineer, I design technology for my employer, but ultimately I am designing technology for people. The customers that use the technology I design are my neighbors. Even people that did not purchase the technology may be impacted by it, and they are also my neighbors. 

I can love my neighbor through my technological products by thoughtful design. I can show loving care by ensuring the design is safe for everyone, incorporating robust fault tolerance and strong security.  I can show loving hospitality with intuitive and aesthetic designs where form implies function. I can demonstrate loving responsibility by providing prophetic witness. How can an engineer be a prophet? By raising ethical flags, warning of dangerous technologies, and testifying to the potential dangers of abuse for even seemingly benign technologies.

Neighbors are the people we interact with

When the Internet was first introduced in the 1980’s, it was mainly a technological neighborhood for scientists and engineers. With the advent of the http protocol and the world wide web in the 1990s, the neighborhood opened up to a much wider audience. Smart phones starting in the 2000s made that neighborhood instantly present.Today, we are more globally and immediately connected than anytime in history. We are aware of the needs of neighbors who are geographically distant, but technologically adjacent. 

The Second Commandment compels us to reject self-centered maps and embrace a more hospitable perspective. As engineers and scientists, our expanding technological neighborhood is not just a feature of our work; it is a mission field. In Part 2, we will explore the tools, interfaces, and algorithms that can either build bridges of mercy or walls of division in our ever expanding circle of neighbors.