ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Seeing God's Design: The Human Body

Updated on June 5, 2022
intelligent design
intelligent design

Introduction

The existence of God really is the foundational question of Christianity (as well as several other major world religions). It all starts there. Is there a creator who made all this? Many modern Christians have latched onto the idea of "intelligent design", which states that "certain features of the universe and of living things are best explained by an intelligent cause, not an undirected process such as natural selection." Obviously this debate is not new, but I would like to add what I think is a new twist on the argument.

I myself am actually a designer (I've been doing software development for 20 years now). In the software development world, we organize programs and web sites into building blocks that neatly fit together to make a whole working system. Even those building blocks are organized into smaller ones, forming an often complicated hierarchy of pieces and parts. As software designers we use patterns and best practices that help us provide a solid software design that is beneficial long term. Surprisingly, these same best practices can actually be clearly seen in the human body! In fact I believe it's so clear that a good designer, after years of design experience, couldn't possibly miss it.

NOTE: I know that my target audience is not composed exclusively of folks with design experience, so I am going to do my best to communicate in a way that my mom (who has no technical expertise whatsoever) can understand. If I confuse you somewhere, please leave a comment and let me know. I'll do my best to fix it. Thanks!

Before we get started, I think it's interesting to point out that a lack of design does not lead to order and structure. In other words, an elegant and efficient design does not happen by accident. If you give a huge project to software developers just out of college, you naturally end up with a mess. In fact, you end up with such a mess that all you really want to do is start over and do it right. That occurs when inexperienced people actually put thought and effort into it. Imagine what would happen if things just happen randomly. Sound without intelligence is just noise. It requires thought to make a melody. Even if the melody is computer-generated, someone had to program the generator to stick to certain rules so the melody sounds reasonable (distance between half step and whole step, etc.). When a guitar gets badly out of tune, it's hard to call the output "music." It seems intuitively obvious that order and structure (especially the kind of structure found inside each of us) only comes from intelligent intervention. As we examine our own design, hopefully we'll begin to recognize the "fingerprints" of the actual designer.

Design 101 - An Overview

I want to quickly explain a geeky term we'll use later: objects. For the purposes of our discussion, systems, organs, tissues, and cells are all objects (some part of the whole). So, objects can contain other objects and they can interact with each other as well.

There are five specific design principles or best practices that I want to address below. Each of these can clearly be seen (in most cases over and over again) by examining human anatomy.

1. Encapsulation (object walls and boundaries)
2. Loose Coupling (simple and limited interaction points between objects)
3. Tight Cohesion (an object's responsibilities are closely related or highly focused)
4. Separation of Concerns (minimized overlap in functionality from object to object)
5. Efficiency (doing multiple things at once; pipelining, concurrency)

These are discussed in detail below.

Encapsulation

Encapsulation is really all about controlling access to the internals of an object. We build a "wall" around it, keeping in what should be in and keeping out what should be out. This principle is critical to many of the systems and organs in the human body. There are actually walls and membranes everywhere. Tubes have walls (veins/arteries, esophagus, umbilical cord, trachea) to ensure proper transport of its cargo. Every cell and every nucleus has a membrane. In the digestive system, it is critical that what's inside the intestine stays in the intestine. Otherwise, a life threatening infection could result. With so many different kinds of fluids in the body which perform so many different tasks, containment seems like a fairly high priority. Blood, urine, bile, feces (a.k.a. diarrhea), amniotic fluid, gastric acid, breast milk, and tears are just a few examples. It's probably not a great idea to start mixing a bunch of these together internally.

A wall is generally a preventative measure (either that or organizational). For instance, arteries are basically transport mechanisms for oxygen. The arterial wall is essential for blood flow. Imagine what would happen if our blood was left to just move in an uncontrolled manner all around the body. Would there be any movement or flow at all? How much of the blood would even make it back to the heart for reloading? If the bladder (for urine) had no wall, we would all end up with uremia (caused by waste products being absorbed back into the bloodstream). This could ultimately kill us. Many of these walls are here for our protection. But doesn't nature ultimately break down walls rather than build them? Prevention is a strategic endeavor, which I believe would not be conceived on its own without intelligent oversight.

Loose Coupling

While it's important for walls to be built, it doesn't work very well if there's no gate. For most objects, there has to be an interface (some way for things to get in and out). Coupling is how interdependent two objects are. For instance, the stomach has two interface points: one coming in and one going out. This also applies to the esophagus, small intestine, large intestine, trachea, etc. Even the heart has one way in and one way out. This is loose coupling (very simple, elegant interfaces between objects). The more dependent objects are the harder it is to understand them and the harder it is to swap them out. The kidney has three main interface points (renal artery, renal vein, and ureter which heads to the urinary bladder. Loose coupling makes the human body easier to maintain and makes it easier to perform transplant surgeries for organs such as the heart, lung, kidneys, liver, pancreas, thymus, and intestine.

Some interface points require a little extra complexity. For instance, the heart has multiple valves which control the blood flow. When the pressure on the outside of the valve is lower than that on the inside, the valve opens. Rather than a constant flow, this creates a more staggered flow through the heart. Valves exist on either end of the stomach as well, although they act differently than those of the heart. This is a slick design indeed, pointing to the involvement of someone who actually thought it through.

Tight Cohesion

Cohesion is all about how closely related (or focused) the responsibilities of an object are. What you find throughout the body is that objects within the body are done right, exhibiting tight cohesion. You don't see any organs or systems that act like a "handyman" for lots of disparate tasks or responsibilities. The heart doesn't pump blood while providing oxygen storage and managing the menstrual cycle on the side. The stomach doesn't process food while managing hormone levels. Each object has a specific purpose and its responsibilities fall in line with that purpose. In the software development world, we do this to make our code more intuitive for people trying to learn it for the first time. As complicated as the human body is, imagine if the responsibilities for systems and organs were all over the map. We weren't given documentation that explained how everything works. We had to reverse engineer it. We clearly benefit from the tight cohesion we find here.

Separation of Concerns

Separation of Concerns is all about minimizing the overlap of functionality from object to object. For instance, what if the throat sent a message to the heart telling it to beat every time you swallowed something? What if your skin pulsated, trying to manage blood flow? The heart might say something like "I've got this covered. Mind your own business." Objects within the body don't get in each others' way. Each object is trusted to do it's job. This works because each object is designed to effectively do the job it's been given. It all goes back to design.

Efficiency

The human body is designed for efficiency. The least efficent design for the circulatory system would be to have one artery flow all around the body, moving from limb to limb, carrying blood to each area of the body until it eventually circled back to the heart for reloading. This is what we call a single-threaded design, where everything must flow through a single pipe. Because this one pipe is responsible for bringing oxygen to the entire body, the distance the blood would travel would be incredibly long. In fact, it would take way too long to get the oxygen to most areas of the body.

Instead, one large pipe leaves the heart (the aorta) which quickly begin to branch into many smaller tributaries. More and more branching occurs, allowing the blood to go down many paths at the same time (ie. concurrency). So many branches are created that its actually impossible to count them (one estimate I saw was over 2 billion, including arteries and capillaries). Once the oxygen has been distributed, the deoxygenated blood must return to the heart. The many concurrent paths then rejoin to ultimately make a single pipe again to flow back into the heart for processing. This is very efficient and minimizes the round trip time back to the heart.

The circulatory system can work this way because, once the blood leaves the heart, it's really just an issue of transportation and distribution. Blood vessels are extremely uncomplicated and easy to replicate. But what about the digestive system? This is a more complicated design problem because processing is required at several points along the way. According to Colorado State University, it takes roughly 4-5 hours for a meal to be fully processed by the stomach, 2-3 hours in the small intestine, and 1.5 days in the large intestine. These are long delays in each station, totaling up to about 2 days. Imagine if our bodies had one large organ called the "food processor" that performed all of the processing of the food in one spot, finally releasing the end result two days later. What if we actually had to wait for this process to completely finish and for the food processor to empty completely before we could insert new food? This would be an incredibly simple design, but it would also be incredibly inefficient.

Instead, the digestive processing is divided up into multiple stations which all are able to operate at the same time (like an assembly line). So, you still end up with concurrency; it's just in a different way. The stomach is working while the small intestine is working while the large intestine is also working. The stomach is a hollow container with valves on either end, while the small and large intestines are actually slow moving tubes. As food moves through the tube, it makes room for new food to come in behind it. By the time the food has exited the tube, it has been successfully processed and is ready for the next station. this is a FIFO design (first in, first out) that's easy to follow and understand. Things go out in the same order that they came in.

But, the stomach is not a tube. It's a container where the food just sits for a while. How does it ensure that it only releases food that's been fully processed? The stomach actually converts the food you eat into a thick liquid called chyme. While the stomach is working on food you ate an hour ago, additional food can be added to the mix. Eventually, the liquid chyme reaches a consistency that the muscular valve called the pylorus is happy with. Then the pylorus releases the chyme into the small intestine for further processing. So, there's actually a test at the bottom to make sure that what flows into the intestine is ready for prime time. It doesn't need to wall off the "in-progress" food from the food that's waiting in line, which is what I might have been tempted to do. This is much simpler. It works because of the infrequency of our meals. Eventually, the stomach will get a 4-5 hour block of time where it can finish the conversion uninterrupted and dump its contents. Again, elegant and efficient.

Conclusion

In this article we looked at several design principles and examined how they are shown in the design of the human body. We specifically focused on the circulatory and digestive systems, but these same principles are clearly seen in the other systems as well. What we have is an intuitive, maintainable, fully-featured design that supports complex data processing, self healing, a reproduction process that doubles as a recreation utility, alarming (messages to the brain when injury has occurred), peer to peer communication, etc. I believe that the fingerprints of the designer are there. The real question is, do you? Either way, please feel free to share your perspective in the comments. I'm definitely interested in your thoughts. Thanks for your time!

working

This website uses cookies

As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://corp.maven.io/privacy-policy

Show Details
Necessary
HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
LoginThis is necessary to sign in to the HubPages Service.
Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
AkismetThis is used to detect comment spam. (Privacy Policy)
HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
Features
Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
MavenThis supports the Maven widget and search functionality. (Privacy Policy)
Marketing
Google AdSenseThis is an ad network. (Privacy Policy)
Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
Index ExchangeThis is an ad network. (Privacy Policy)
SovrnThis is an ad network. (Privacy Policy)
Facebook AdsThis is an ad network. (Privacy Policy)
Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
AppNexusThis is an ad network. (Privacy Policy)
OpenxThis is an ad network. (Privacy Policy)
Rubicon ProjectThis is an ad network. (Privacy Policy)
TripleLiftThis is an ad network. (Privacy Policy)
Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
Statistics
Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
ClickscoThis is a data management platform studying reader behavior (Privacy Policy)