Programmers also need Moral Philosophy

I stand corrected; programmers need knowledge of moral philosophy too.  I realized this after hearing this BBC story about developers of self-driving cars explicitly asking philosophers for help in formulating which person the car should hit.   .  .  .  .  .

When first starting my project to teach other programmers all the practical concepts I was learning from Philosophy, I focused on ontology, the study of describing the world. Philosophy has 2500 years of study of this topic that computer science naively leaves up to intuition. I thought that only the IS side of Hume's IS/OUGHT divide would be relevant to actual programming.  It turns out that real programmers doing real software development need the OUGHT side too.

Hume's IS/OUGHT Divide

The philosopher David Hume wrote that all statements fall into one of two categories: descriptive statements about "what IS", versus, prescriptive statements about "what OUGHT to be", and one can't judge what ought to be without a clear accurate understanding of what is.

One of the basic tasks of Philosophy is to try to explain and justify one's intuition and gut reactions via a set of explicit logical rules.  The IS side of things worries about the best way to describe and categorize things, and how we can justify that we know what we think we know.  The OUGHT side of things worries about rules guiding "moral" decisions, and which rules apply in which situations, and what are the overriding goals of each rule system. In other words, what is the "right" thing to do.  In both of these categories, it turns out that our intuitions often result in conflicting answers, thus the need to analyze and sort them out (ahem, easier said than done).

The IS statements are the ones that first come to mind when developing a self-driving car. What IS the terrain, the car speed, the distance to the curb, the position the car in the next lane will be in two seconds.  These questions are the kind covered in Artificial Intelligence classes, the ones first needed to be able to drive at all.  The ones that let a system detect potential collisions, and formulate the set of options available to avoid them.

But, IS statements don't describe which of those options is the "right one", the choice it OUGHT to make. It is only after you realize that sometimes there is no purely "good" option, no option that leaves everyone unscathed, that you realize you will have to program the car to decide who to hit! How does the poor programmer decide that?! Luckily, some programmers had the wisdom to call a philosopher for help encoding moral rules rather than blindly using their programmer's intuition.

So, if a self-driving car hits someone, who OUGHT to have responsibility?  The auto maker? The car owner? The car's software developer who programmed its rules?   If a bicycle darts in front of the car, but the action of swerving to avoid an inevitable collision will itself cause a collision with someone else, who OUGHT to be hit?  The "at fault" bike? The more-likely-to-survive but "innocent" car in the next lane? Override the "never cross the double yellow line" rule and swerve into oncoming traffic (potentially resulting in a chain reaction)?

"Moral" Philosophy

When looking at the language describing the scenarios above, we see words like "action", "choice", "responsibility", "cause", "result", "fault", "innocent", "never", and "more likely to survive". These lead to classic concepts in moral philosophy like Action and Agency, Causation, Free Will vs Determinism, Moral Responsibility vs Moral Luck, Desert (i.e. who deserves what) and Legal Punishment, which are intertwined in the following way; we expect those making decisions to be morally/legally responsible for the consequences of their actions, assuming that they were able to make a free choice.

But there are debates about whether the ends justifies the means (Consequentialism) versus a bad deed is a bad deed (Deontological Ethics). There are also debates about what the overarching goals should be; the most good for the most people (Utilitarianism) versus the most deserving (Prioritarianism), or the most freedom (Libertarianism), or the most equality (Egalitarianism), etc, etc.

These are just the tip of the iceberg, but it is worth the study since they provide a language for documenting and explaining your ultimate set of rules as well as making you aware of the many non-trivial scenarios. Lest you programmers think that Philosophy is overkill, take a look at books like "The Pig that Wants to be Eaten" cataloging the many well-known moral paradoxes that result from relying on intuition and gut reactions.

POSTSCRIPT - Sep 29, 2016
NPR reports on a newly formed industry consortium to tackle just these sorts of automated "Moral" decisions:: Tech Giants Team Up To Tackle The Ethics Of Artificial Intelligence.

POSTSCRIPT - May 4, 2017
When I first wrote this post, driverless cars were still considered a distant possibility; Now they look to be here sooner rather than later, and the "moral philosophy" aspect of it is being taken much more seriously. A case in point:: Driverless Cars at the Moral Crossroads: Philosophy Talk LIVE.

POSTSCRIPT - July 4, 2017
Now, exactly (but only) 3 years after I wrote this item, the topic is all the rage. "Who the car should hit" is explicitly addressed in the recent BBC Horizon episode "Dawn of the Driverless Car". It is also the topic of the cover story on the current issue of The Economist 1843.

POSTSCRIPT - Oct 26, 2018
Another NPR update on the topic of automating moral decision making:: Should Self-Driving Cars Have Ethics?

POSTSCRIPT - June 14, 2021
The BBC program "Click" has an episode on the Future of Transport that has a segment on people training auto-drive AIs in just this sort of moral decision making:: MIT Is Crowdsourcing Moral Decision Making For Self-Driving Cars

POSTSCRIPT - Mar 12, 2026
The BBC short series "AI Confidential with Hannah Fry" has an episode: Death by Driverless Car that covers in detail the moral/legal issues involved in actual deaths now caused by auto-drive AI.

POSTSCRIPT - July 8, 2026
NPR has a story: Why AI companies are hiring philosophers to help develop their models that says AI companies finally read this blog post. [JK]

No Social Constructs in My Little Town

In Paul Simon’s song “My Little Town”, there is the lyric “everything’s the same in my little town”.  This can be contrasted with "the big city" that is cosmopolitan, multicultural, not all the same.  It is only when you have the experience of more than one culture that it becomes natural to see that there can be more than one notion of how things are.  In Philosophy, when there is one “correct” definition of something, due to it existing in nature, independent of man, it is called a “natural kind”.  However, when something only exists because people have agreed to think that it does, that is called a “social construction”.  Computer programmers need to be aware that, of the things they have to model in their databases, user interfaces & business models, most are social constructions, and hence, there are many ways to skin a cat, but not arbitrary ways.  Two case studies are given that show how programmers can err on either side of the spectrum.

Social Constructs versus Natural Kinds

It is common to consider Natural Kinds to be “discovered”, and Social Constructions to be “invented”.  An example of something that only exists because we say it does is money.  A Bitcoin (or an ounce of gold, or a piece of paper with $100 printed on it) is worth whatever we say it is, and how many Big Macs can be bought with each is whatever we agree upon.  And via the computerized marketplace, we can change our collective mind every microsecond.

Social Constructions are also inherently “relative” to some culture, which means that there can be more than one version of it floating around, and each can be equally valid.  A traditional example is the definition of what it means to be a woman.  While there are the aspects of womanhood that are controlled by DNA and biology, many aspects are defined by society, and there are many different definitions existing simultaneously.

On the other hand, we believe that atoms exists in nature.  We may discover better definitions and understandings of them over time, but those would be mere changes in our knowledge of them, rather than making them an invention.  When Europeans thought that swans only came in white, and then found black ones in West Australia, their definition of swan changed, but we still think that swans are in fact a natural species, independent of whether you’re European.

Natural Kinds that Aren’t

There are times that something is thought to be a natural kind, but later realized to not be, for example, planets.  We thought that planets existed objectively and independent of our latest definition.  We now realize that those orbiting chunks of rock and clouds of gas may exist objectively, but our classifications of “planet” versus “dwarf planet” versus “failed star” do not.  I.E. they are arbitrary enough that aliens landing here will likely have different ways of classifying orbiting stuff.

Saving the Phenomena

So, if planets aren’t “real”, where did they come from?  An early view of the universe was that everything literally revolved around the earth in a perfect circle, except for a handful of “wanderers”, the original meaning of planet.  As we gained more knowledge, we would update our definitions. But we always (if only unconsciously) wanted to “save the phenomena”; in other words, make sure that the new definitions didn’t drop any planets and didn’t add any, otherwise, we would be defining something that did not match our intuitive notion of planets.

Of course, recently that became impossible because we realized that we were either going to have to add hundreds of new “planets”, or, drop Pluto, to be consistent.  The more that people tried to keep the original collection, the more it became clear that the collection was based on culture and history rather than an objective category of things in space.  Some even say that Jupiter is not really a planet, but a failed star.

Case Study: World Headquarters in My Little Town

The world headquarters of Coca-Cola is in Atlanta, and while a world headquarters would be expected to be pretty cosmopolitan, it is in The South which was traditionally very monoculture, conservative, and religious (which I can say because I grew up there).  I was there, on a Y2K project, redesigning data files which were using just 2 digits to represent years (even though the file formats had been specified only two years previously, by the way).  During discussions with the developers (all Atlanta locals), it was assumed that there was only one obvious “correct” way to represent dates in a string: mmddyyyy.  Having lived overseas, I knew to point out that most of the world doesn’t do it that way, instead using ddmmyyyy, or yyyymmdd (and we did not even get into other calendar systems).

The point is that it was assumed that dates were a natural kind when they are actually very socially constructed. In my little town every thing is the same and therefore looks like the one and only way God intended.

Case Study: Bizarrely Arbitrary User Interface at domain.com

While the concept of “social construction” says that there can be several equally-valid ways of defining some things, do not forget about the “social” part! I.E. you should not create an arbitrary definition that no one actually uses and therefore no one will understand.

On the website of domain.com (a domain name registry provider), there is the domain name registration form which includes a mandatory phone number field.  The required format is so bizarre though that it took a chat with customer support to figure out what is was.  It turned out to require the phone number to be entered as the fractional portion of a floating point number…let that sink in…floating point notation, with a mandatory leading plus sign and mandatory integer of 1.  So, phone number “(123) 456-7890” had to be entered as +1.1234567890  ...AND, to make matters worse, the error message received when it was not entered that way, only said that a legal phone number was required, without explaining what the non-obvious required format was.

When I pressed the support chat operator for an answer to my question, WTF?! , I was told (after some time on hold) that “that was the format that the developers chose”. There was no answer to my question: Of all the phone number formats on the planet, who has ever used that?   Apparently it was the culture of domain.com off-shored contract developers with no managers who were engineers enough to review the design.

Programmers also need Moral Philosophy

I stand corrected; programmers need knowledge of moral philosophy too.  I realized this after hearing this BBC story about developers of self-driving cars explicitly asking philosophers for help in formulating which person the car should hit.

When first starting my project to teach other programmers all the practical concepts I was learning from Philosophy, I focused on ontology, the study of describing the world. Philosophy has 2500 years of study of this topic that computer science naively leaves up to intuition. I thought that only the IS side of Hume's IS/OUGHT divide would be relevant to actual programming.  It turns out that real programmers doing real software development need the OUGHT side too.

Hume's IS/OUGHT Divide

The philosopher David Hume wrote that all statements fall into one of two categories: descriptive statements about "what IS", versus, prescriptive statements about "what OUGHT to be", and one can't judge what ought to be without a clear accurate understanding of what is.

One of the basic tasks of Philosophy is to try to explain and justify one's intuition and gut reactions via a set of explicit logical rules.  The IS side of things worries about the best way to describe and categorize things, and how we can justify that we know what we think we know.  The OUGHT side of things worries about rules guiding "moral" decisions, and which rules apply in which situations, and what are the overriding goals of each rule system. In other words, what is the "right" thing to do.  In both of these categories, it turns out that our intuitions often result in conflicting answers, thus the need to analyze and sort them out (ahem, easier said than done).

The IS statements are the ones that first come to mind when developing a self-driving car. What IS the terrain, the car speed, the distance to the curb, the position the car in the next lane will be in two seconds.  These questions are the kind covered in Artificial Intelligence classes, the ones first needed to be able to drive at all.  The ones that let a system detect potential collisions, and formulate the set of options available to avoid them.

But, IS statements don't describe which of those options is the "right one", the choice it OUGHT to make. It is only after you realize that sometimes there is no purely "good" option, no option that leaves everyone unscathed, that you realize you will have to program the car to decide who to hit! How does the poor programmer decide that?! Luckily, some programmers had the wisdom to call a philosopher for help encoding moral rules rather than blindly using their programmer's intuition.

So, if a self-driving car hits someone, who OUGHT to have responsibility?  The auto maker? The car owner? The car's software developer who programmed its rules?   If a bicycle darts in front of the car, but the action of swerving to avoid an inevitable collision will itself cause a collision with someone else, who OUGHT to be hit?  The "at fault" bike? The more-likely-to-survive but "innocent" car in the next lane? Override the "never cross the double yellow line" rule and swerve into oncoming traffic (potentially resulting in a chain reaction)?

"Moral" Philosophy

When looking at the language describing the scenarios above, we see words like "action", "choice", "responsibility", "cause", "result", "fault", "innocent", "never", and "more likely to survive". These lead to classic concepts in moral philosophy like Action and Agency, Causation, Free Will vs Determinism, Moral Responsibility vs Moral Luck, Desert (i.e. who deserves what) and Legal Punishment, which are intertwined in the following way; we expect those making decisions to be morally/legally responsible for the consequences of their actions, assuming that they were able to make a free choice.

But there are debates about whether the ends justifies the means (Consequentialism) versus a bad deed is a bad deed (Deontological Ethics). There are also debates about what the overarching goals should be; the most good for the most people (Utilitarianism) versus the most deserving (Prioritarianism), or the most freedom (Libertarianism), or the most equality (Egalitarianism), etc, etc.

These are just the tip of the iceberg, but it is worth the study since they provide a language for documenting and explaining your ultimate set of rules as well as making you aware of the many non-trivial scenarios. Lest you programmers think that Philosophy is overkill, take a look at books like "The Pig that Wants to be Eaten" cataloging the many well-known moral paradoxes that result from relying on intuition and gut reactions.

POSTSCRIPT - Sep 29, 2016
NPR reports on a newly formed industry consortium to tackle just these sorts of automated "Moral" decisions:: Tech Giants Team Up To Tackle The Ethics Of Artificial Intelligence.

POSTSCRIPT - May 4, 2017
When I first wrote this post, driverless cars were still considered a distant possibility; Now they look to be here sooner rather than later, and the "moral philosophy" aspect of it is being taken much more seriously. A case in point:: Driverless Cars at the Moral Crossroads: Philosophy Talk LIVE.

What is Philosophy?

Because I am endeavoring to teach ideas from Philosophy to computer programmers, who typically have no background in it, a question I must answer right off the bat is "what IS philosophy?"  Here is the answer I provided to a new MOOC "Introduction to Philosophy":

Given that the single word "philosophy" is commonly used to refer to multiple different (albeit related) things, all answers to the question "Q: What is [Western] Philosophy?" actually depend on one: "doing philosophy; the act of philosophizing" which I explain to even children as:

A: Being able to answer the question, Why do you think what you think? Why do you believe what you believe?

And while you want to be able to answer to someone else's satisfaction, you foremost want to be able to answer to your own satisfaction because you want to know the truth. (BTW, the western bit is "we believe humans are capable of working it out ourselves")

All the other things the word philosophy can refer to build on, and depend on, the above. e.g. Philosophy as meaning "the body of knowledge accumulated by those doing philosophy" (which entails history of philosophy, individual ideas, individual philosophers, tools/techniques/criteria for doing it well, favorite topics for philosophizing about, etc, etc) all naturally spring from someone somewhere starting to "do philosophy".

Of course for programmers who will say, "so what does that have to do with me?", I have to quickly add that even thousands of years ago, philosophers already had come up with some really good techniques for describing the world, and being able to justify that those techniques were better than our intuition.  So, since a large portion of our work as programmers is to describe the world via our data models, object models, class hierarchies, classification schemes, etc, etc, we would get better at it if we replaced our intuition with techniques philosophers know but we typically havent been taught.

Not All Properties Are Created Equal (Part II: Says Who!?)

It is said that Beauty is in the eye of the beholder. If one were developing a data model for Person, there are various properties that might be attached. Unlike some other properties, it might be more self-evident that a property like isBeautiful would be problematic because it begs the question “Says who?”. There is a relationship between a particular beholder and a particular beheld, in which an isBeautiful property would be more appropriately placed. It may even be a many-to-many relationship with multiple values of isBeautiful coming from multiple beholders as in a beauty pageant panel of judges. Or, as in the case study below, the credit grade of a banking customer is actually several grades, coming from different bankers and algorithms over the life of the business relationship, and international banking regulations now mandate their tracking and optimization.

Of the many subcategories of properties that Philosophers have come up with, an important pair are what John Locke named Primary and Secondary Properties (aka Qualities). The distinction between them being that Primary properties are those that are “objective” and “in the object”, while Secondary properties are “subjective” and “in the mind of the perceiver”. Primary properties of an apple would be its mass, shape, size, etc. Secondary properties would be its color, taste, smell, etc.

That apple isn't really red?
Color is a classic case in point because it seems that color might be objective.  There are surely some collection of wavelengths of light reflected off an apple that could be classifiable as “red”. Alas, there are mountains of evidence that color perception depends on the person and the external conditions.

A famous mountain of evidence (sorry, pun intended) is Ayer’s Rock (aka Uluru) in Australia which attracts thousands of tourists to see it dramatically change colors right before their eyes. Over the minutes of sunset or sunrise, “the color” ranges thru black, red, pink, orange, brown, etc.

In the rain it even turns blue and purple...

So, the mountain can’t really have a simple “color” property with a simple single value.

 

Again, as with Essential properties, how is this primary/secondary distinction supposed to make me develop differently than I do now?

• Model Clarity: Keeping the properties of an entity or class limited to primary qualities helps to insure that your data model will match data models developed by others. You will be more likely to agree on what the properties are in the first place, and, on what data type best represents that property (see Stronger Types below).


• Better Normalization: Your entity database tables are normalized when limiting to Primary properties because those truly are properties of that entity. By recognizing and removing Secondary properties, you won’t be mixing in columns that are really a flattened relationship with some other beholder entity.


• Better Keys: When deciding which properties of an entity are candidates for being part of it’s “key” or “identifier”, it definitely helps to verify they are really objective properties of the entity. Otherwise, they are based on some external beholder & conditions that can change over time, even though the entity itself didn’t change! A drivers license search will fail if a witness’ notion of a suspect’s hair-color doesn’t match the DMV’s notion of that hair-color.


• Data Provenance: Realizing that each value of a secondary property begs the question “says who?”, you need to identify the authority that provided each value for that property. As you can see, there could be anything from a one-to-one to a many-to-many relationship between the original class and the various authorities providing data values. If the answer is “all values of this property come from a single source X”, then that need merely be noted in the documentation.  At the other end of the spectrum, there may need to be a sophisticated sub-model just to keep track of the source and circumstances of each of the several values that property could take on for a single object! (see the Basel II banking case study below).


• Stronger Types: Authorities providing data values for secondary properties, usually define entire “types” rather than just values from some universal type. For example, authorities specifying colors usually limit them to a custom collection of colors (i.e. a palette), or even collections of palettes.  Ralph Lauren defines many palettes of colors, most with one or more “reds”, but none of them are the same as the “red” of a 1964 Ford Mustang which comes from the small palette of factory colors from Ford for that year. If you need the simplicity of a single universal “red” value then you are looking at defining mappings from one palette to another. Car salesmen do this mapping intuitively by showing you a "cypress pearl"Infiniti when you ask to see either "black" cars, or "green" cars. Do you need that sort of detailed modeling? You do if you are trying to make it easy for customers to find what they want (see the fabric.com case study below).

1964 Mustang Factory Colors

Ralph Lauren Palette

Case Study: Basel II Banking Accord

One of the fundamental practices of banks is to keep a certain amount of money in reserve. When taking customer deposits in, and loaning it out to make a profit from the interest charged, there is a danger if all the deposits are handed out as loans. So, a reserve must be kept, but, there is a conflict between larger reserves for more safety and smaller reserves for more profit. Because banks have erred on the side of more profit, over the past several years international banking regulations have added requirements that the amount of reserve be calculated on a more scientific basis, and be optimized over time.

One of the major criteria in determining how much reserve is required, is to base it on the quality of the customers that the bank lends money to, as measured by their credit grades. A credit grade is really just a prediction of how likely a borrower is to pay back a loan, and how much they would leave unpaid if they did default on a loan.

The regulators recognized (though maybe not in these philosophical terms) that “credit grade” is not a primary property of a customer; it is a secondary property based on the grader and the procedure or algorithm used. The Basel II Banking Accord specified that simply keeping track of customer credit grades was not enough.  Banks needed to start keeping track of “says who?” and “what did they base it on?”. With this data, it can be verified after the fact which of these predictions of future default panned out. This enables evolving better algorithms and weeding out graders and methods that were not very good.

Case Study: fabric.com

In the early days of marketing on the web, the start-up fabric.com (since bought by Amazon) was building a web store to sell clearance fabrics and apparel. Like all online retailers, there is the problem of making it easy for the customer to find the products they want. A common approach is to build a web site with a left-column navigation bar containing filter-by-property controls. This works fine for Primary properties, but is more of a problem for Secondary properties.

Alas, if one doesn’t know that there is a difference, one builds all of the filters in the same manner. For fabrics, filtering by the dimensions of the piece being sold is straightforward and effective because it is a primary property. For color however, there are problems because it is a secondary property, and hence opinions differ on how to describe the color.

Look, even though the “color” of a fabric may be in the eye of the beholder, it is an objective fact that the manufacturer described the color as X, right?. How about we use that since we have to pick something? 
Well, two big problems:

• All those colorful color descriptions cause an overly large list of colors in the color filter, plus related colors are spread all thru the list (e.g. avocado, green, lime, olive, etc) 
• When the customer searches for “green”, she won’t find all those fabrics with the color described as “lime”.

Okay, fine, we are going to have to go to the trouble of mapping each item to a simple set of colors that we pick. So, Mr. Programmer, go set up a set of simple colors in the database so that we can pick the color when we enter these items into inventory. Well, one other big problem:

• While everyone is entitled to their own opinion, some opinions are worth more than others.  The programmers did not have the industry experience needed to pick an appropriate set of colors.  It was the brick and mortar fabric sellers that knew things like “stripe is a color”! So, it took someone who had experience with what buyers actually ask for to know that along with “green” in the color list, also needed was “green and white stripe” but not the manufacturer’s description “lime and white stripe”. They also knew that, in addition to simple color families like yellow and brown, subtle categories like "gold, “beige”, and “cream” were needed (and in fact the last two combined into a single category). On the other hand the green family did not need to be augmented by “lime” and "avocado" families.

SO, just as with Essential properties, more important than any particular use case is knowing that there IS a distinction between objective intrinsic Primary properties versus Secondary properties which are in the eye of the beholder.

Not All Properties Are Created Equal (Part I: Essentials)

Just a few years ago, I started reading “Philosophy 101” type books and I was immediately surprised at how relevant the ideas were to day to day software development.  So relevant, in fact, that an even bigger surprise is that these ideas are not part of the basic computer science curriculum, nor mentioned in technical books & magazines (with the possible exception of graduate level artificial intelligence). The following idea was the first I encountered that made it clear to me that programmers need to know what philosophers already know. It was also my first clue that philosophy has a whole body of knowledge about developing data & object models that computer science books leave up to intuition.

Did you know that 2500 years ago, philosophers like Plato and Aristotle were doing Object-Oriented Analysis and Entity-Relationship Modeling? More surprisingly, they were already more sophisticated than software developers are now!   Why?  Well, for one thing, they already understood that the properties of an object are not all created equal.  Whereas programmers today basically think that a property is a property, even ancient philosophers understood that there are several different categories of properties. And most importantly, only some properties define WHAT something is; the other properties merely describe HOW it is. Embracing this distinction will change the way you carve up the world into classes and relationships, and which attributes you assign to which entities.  I have come to feel that creating data models without this distinction is like wearing glasses so out of focus that distinct objects blur together into indistinguishable blobs. 

The properties that something must have, in order to be what it is, Philosophy calls Essential properties. Those properties that something may optionally have are called Accidental properties. For example, for you to be a human, you must have human DNA; it is an Essential property. Being named Smith, however, is an Accidental property because you would still be human even if you had a different name or even no name.  So, our everyday meaning for “essential” is different than the philosophical meaning. If a client says that the address is an essential part of the customer data, that doesn’t mean that it is Essential in the philosophical sense. In fact, it is not Essential because whatever a “customer” is, it will still be that same kind of thing even if its address changes.  The distinction between essential and accidental properties is even embedded into some human languages like Irish where there are two different “is” verbs; “Tá” is used for accidentals like “He is hungry”, but the verb they call The Copula is used for essentials like “He is Hungarian”.

A hallmark of Essential properties is that they are unchanging. An object’s Essential properties can not change without that object becoming a different kind of thing. There is an ancient philosophical paradox of how something can change and yet remain the same. You are different than you were as a child, and yet you are still the same you. As Heraclitus said, "You can’t step into the same river twice because the water is always different."  The solution the Greeks came up with was that Accidental properties may change but Essential properties must remain the same (otherwise, a metamorphosis has occurred!).  This philosophy is known as Essentialism.

Socrates taught that everything has an “essential nature” that makes it the kind of thing that it is. His pupil, Plato, taught that these essences are manifest in ideal “Forms” of which all objects are mere copies. Plato’s pupil, Aristotle, taught that Essential properties were those that defined a Form, and Accidental properties were those which distinguished one individual object from another of the same kind.  Our object-oriented programming notion of Class is analogous to Plato’s Forms. Like a Class, a Form is unchanging and it pre-exists any objects which instantiate it. Naturally, Entity tables are the database equivalent of Forms with their records being the objects.

So, what is using this idea supposed to buy me? I think a case can be made for at least the following:

1. Better definitions of entities, classes, and relationships result because it forces you to weed out all the non-essentials (pun intended). By striving to understand entity essentials, and not just normalizing data tuples, you will be more likely to accurately model the world.
2. Better specifications result because there will now be a place to put all those unwritten (even unspoken) assumptions about the nature of the problem domain. Ironically, when gathering requirements and doing analysis, the essential properties of things are often given short shrift  because they mostly don't get stored in databases, because.…that's right, they don't change!  It is the changeable accidental properties that get stored, with the unchanging essential properties getting buried as hardwired assumptions in the programming logic.
3. Better system interoperability results because universal essential data is separated from local accidental data. The integration of data between a customer system and a patient system and an employee system would be much easier if they had modeled the essential entity, which is Person. When customer and patient and employee are recognized as merely accidental roles of a Person, there is an immediate common entity type to synchronize on rather than widely divergent data tables.
4. Better identity systems result because life-long identifiers will no longer be confused with changeable properties like names, addresses, and phone numbers.

Examples of using Essentialism

• Imagine a Person table where we already understand that using the Name column as the primary key is a bad idea, simply because names are not unique.  Some are tempted to create a compound key using name plus some other column(s) like address, phone, etc.  With an Essentialism perspective it is clear that, while the compound key may be unique for the moment, it is composed of accidental properties and hence can change at any time!  Stored references to previous keys will fail. Current keys won’t match future keys.


  
  We want keys using essential attributes that remains fixed for the life-time of the Person. A unique, fixed, objective, essential attribute like the person’s complete DNA sequence would do the trick! However, a government issued tax ID like SSN can be a practical substitute, plus it’s better than a proprietary “customer ID” because it is something that is effectively universal, and therefore can be used to integrate databases from multiple sources.
  
  Lest you think this example is contrived, I witnessed a Top-5-in-the-USA bank design a customer identity system using a key composed of accidental properties rather than SSN because “we have not traditionally collected SSNs” (despite government “know your customer” security laws requiring it!)  They had to continually fix their ever-changing data because they only focused on having a “unique key”.
  
  
• In tutorials for any technology that uses entities, the example of a “customer” entity is almost cliche. The design of databases, XML schemas, UML diagrams, SOAP messages, Java Classes, etc, etc, have all used it.  But when we ponder the essential nature of a “customer”, there is an immediate problem…


  
  Philosophers have devised many systems for organizing “what exists”, and one of the first of their “20 questions” is: Is its essence physical or abstract? Customers can either be a person (a physical thing that exists in time and space), or a corporation (an abstract thing that doesn't exist in space), so, which is it?  This is our clue that it isn’t an entity at all.  With some thought (and benefit of reading more philosophy), it becomes clear that “customer” is really just a role that different entities can play.  It is part of the relationship between that entity acting as customer, client, buyer and that entity acting as vendor, seller, provider.

Whatever interpretation you would give about the essential-ness of this or that property, the main point is that it is worth knowing that there IS a distinction. And more generally, Philosophy has some ideas to which we programmers need to be exposed.

Neural Nets, Vagueness, and Mob Behavior

In response to the following question on a philosophy discussion board, I replied with the short essay below and reproduce it here.

"It was then that it became apparent to me that these dilemmas – and indeed, many others – are manifestations of a more general problem that affects certain kinds of decision-making. They are all instances of the so-called ‘Sorites’ problem, or ‘the problem of the heap’. The problem is this: if you have a heap of pebbles, and you start removing pebbles one at a time, exactly at what point does the heap cease to be a heap?"

VAGUE CONCEPTS
This leads to the entire philosophy of "vagueness". i.e. are there yes/no questions that don't have a yes/no answer? Are some things like baldness vague in essence, or, is our knowledge merely incomplete? e.g. we don't know the exact number of hairs on your head, and/or, we don't know/agree on the exact number of hairs that constitutes the "bald" / "not bald" boundary?

NEURAL NETS
My personal conclusion is that there ARE many vague concepts that we have created that are tied to the way our brains learn patterns (and, as a side effect, how we put things into categories). In contrast to rational thought (i.e. being able to demonstrate logically step by step our conclusions), we "perceive" (ala Locke/Hume/Kant) many things without being able to really explain how we did it.

In Artificial Intelligence, there are "neural network" computer programs that simulate this brain-neuron style of learning. They are the programs that learn how to recognize all different variations of a hand-written letter "A" for example. They do not accumulate a list of shapes that are definitely (or are definitely not) an "A", but rather develop a "feel" for "A"-ness with very vague boundaries. They (like our brains) grade a letter as being more or less A-like. It turns out that this technique works much better than attempting to make rational true/false rules to decide. This is the situation that motivates "fuzzy logic" where instead of just true or false answers (encoded as 1 or 0), one can have any number in-between, e.g. 0.38742 (i.e. 38.7% likely to be true).

WISDOM OF THE CROWD?
Because each person has their own individually-trained "neural net" for a particular perception (e.g. baldness, redness, how many beans are in that jar?), we each come up with a different answer when asked about it. However, the answers do cluster (in a bell-curve-like fashion) around the correct answer for things like "how many beans".  This is what led Galton to originally think that there was "wisdom in the crowd".   This idea has been hailed as one of the inspirations for the new World Wide Web (aka Web 2.0). The old idea was that McDonalds should ask you if "you want fries with that?" to spur sales. The new Web 2.0 idea is that Amazon should ask you if you want this OTHER book based on what other people bought when they bought the book you are about to buy. I.E. the crowd of Amazon customers know what to ask you better than Amazon itself.

The problem is that there are many failures of "crowd wisdom" (as mentioned in that Wikipedia page in the link above). My conclusion is that most people advocating crowd wisdom have not realized that it is limited to "perceptions". Many Web 2.0 sites are asking the crowd instead about rational judgments, expecting them to come up with a better answer than individuals. The idea of democracy (i.e. giving you the right to vote) has been confused with voting guaranteeing the best answer, no matter the question. In fact, Kierkegaard wrote "Against The Crowd" almost 200 years ago where he recognized that individuals act like witnesses to an event, whereas people speaking to (or as a part of) a crowd, speak what we would now call "bullshit" because they are self-consciously part of a crowd. We can see this in the different results of an election primary (a collection of individuals in private voting booths) versus Caucuses where people vote in front of each other.So, Web 2.0 sites (Facebook, MySpace, blog Tag Clouds, etc) that allow people to see the effect on other people of what they are saying, are chronicling mob mentality rather than collecting reliable witness reports.

BTW, I have written several blog posts related to vagueness, for example:
http://existentialprogramming.blogspot.com/2010/03/model-entities-not-just-their-parts.html

POSTSCRIPT - May 16th, 2011
There is a new study that shows science catching up with 150+ year old philosophy with regard to the (lack of) wisdom of the crowd. Kierkegaard's observation about people (who are consciously a part of a crowd) acting differently than individuals has been verified in new studies reported here in Wired Magazine.

Is Morality Eating Your Own Dogfood?

There are two schools of thought about whether programmers should have to write tests to verify their own code (in addition to writing the code itself). The philosophy of economics, and psychology, and morality, all overlap in studies that show how people will readily abandon moral responsibilities if they are given ways to avoid the stigma of doing so. This leads me to feel more justified in my belief that programmers do a poorer job of reading, understanding, and implementing a specification when someone else has the responsibility of verification.

Changing the rules changes people’s attitudes

There is a 1998 experiment[1] that keeps popping up in the new “freakonomics”-type literature[2][3] (e.g. Economics 2.0 [4]), where a controlled subset of Israeli day-care centers started charging a fine for parents who came late to pick up their children. To everyone’s surprise, the number of people showing up late almost doubled. Additionally, when the fine was later dropped, the number of late parents stayed at the high level. It is theorized that the moral responsibility parents felt to be on time was much stronger than the economic cost of paying a fine, which was rationalized by the parents as a fee, thus removing the stigma of being late. The fee made it “just business”. As Professor Michael Sandel summarized[5]…

“So what happened? Introducing the fine changed the norms. Before, parents who came late felt guilty; they were imposing an inconvenience on the teachers. Now parents considered a late arrival a service for which they were willing to pay. Rather than imposing on the teacher, they were simply paying her to stay longer. Part of the problem here is that the parents treated the fine as a fee. It’s worth pondering the distinction. Fines register moral disapproval, whereas fees are simply prices that imply no moral judgement.”

 Don’t make “not my job” “just business”

The blind experiment is a well established doctrine in science requiring that people should not know too much about something they are testing, otherwise the results are often biased. Scientists gathering their own raw data (not to mention interpreting their own data) often get the results they expected to get, where objective outsiders don’t. With that theory, it is argued that software development projects should engage external, objective, “QA testers” to develop and administer test suites against the code produced by the “programmers”. Since many programmers don’t like to eat their spinach, ahem, write their own tests (or documentation for that matter), there are not usually arguments against the idea.

From my experience though…

• Programmers will suffer peer pressure and social costs if they fail their own tests (which is a good thing).
• Programmers who understand that they are obligated to deliver testable components, will do so more often if they must actually produce the tests themselves, compared to those where testing is “not my job”.
• The act of writing a test forces a clearer understanding of both the interface and the implementation of the tested component compared to just programming it.
• Programmers who fail their own tests will be much more likely to change that component’s implementation if needed, rather than obstinately maintaining that the externally-produced test is wrong.
• Writing your own tests is the most systematic method of “eating your own dogfood”

Belt and Suspenders

I say, both independent testers AND the original programmers should each write independent test suites. This way you get the power of both perspectives. This is an old lesson from the days of computer punch-cards; two different people key-punch the same data so that they can later be compared, thus eliminating most typos.

[1] A Fine is a Price, URI GNEEZY and ALDO RUSTICHINI, Journal of Legal Studies, vol. XXIX ( January 2000)
http://rady.ucsd.edu/faculty/directory/gneezy/docs/fine.pdf

[2] Brain food: when does a fine become a fee?, Aditya Chakrabortty, The Guardian, Tuesday 23 February 2010
http://www.guardian.co.uk/science/2010/feb/23/brain-food-fines-and-fees

[3] Why an L.A. Times wikitorial effort went wrong, Clay Shirky, O'Reilly Media Gov 2.0 Summit, 2009-09-09
http://itc.conversationsnetwork.org/shows/detail4411.html

[4] pg 7, Economics 2.0, Norbert Haring, Olaf Storbeck, Palgrave Macmillan, 2009

[5] Michael Sandel, The Reith Lectures 2009, BBC, 9th JUNE 2009
http://www.bbc.co.uk/programmes/b00kt7rg

The purpose of a thing is in US as well as in IT

In an earlier post, I advocated adopting Philosophers' practice of considering the purpose of a thing when creating a definition for that thing.  Plato and Aristotle would have said that one of the things that made an acorn, an acorn, was that it had the "goal" or "purpose" of becoming an oak tree.  In defining a domain model (aka business objects model), document the "purpose" of a class in order to get at its true attributes and behavior. But, as I was recently reminded, not only can the purpose of a thing be "in the thing itself", it can also be solely in our minds.  I.E. it begs the question: if we are defining a class of things, what is our purpose in caring if we know that something is one of those things?

I had this AHA moment after reading the article "Unclassified" in the June 2010 issue of Discover magazine, where I was surprised to learn that there is no accepted universal definition of a biological species; there are at least 20+ competing definitions.  I had thought that "being able to breed fertile offspring" was the definition, but that is only one (and of course it leaves out the vast majority of living things on earth that reproduce asexually).

After having read about all the conflicting ways to organize and cluster individuals into species, each one with its own way of looking at things, it begged the question: Why do you want to know? I.E. What is the purpose of knowing which species something is?"  Depending on why you want to know, you choose one definition over all the others.

But of course as Darwin thought, this would mean that species are not "real". Instead of discovering pre-existing forms, we would merely be inventing arbitrary sets of attributes-in-common. Therefore, unlike the "teleology" of Plato and Aristotle where the "purpose" or "goal" of a species is internal to itself, it would seem that a possibly more important purpose is the one that WE have in wanting to place a particular into that species.

For example, Ponder all of the various shapes, sizes, forms, etc of things that you would want to call a "chair" [and do a Google image search of "chair"]. Now, ponder coming up with a universal definition of chair (such that all chairs would be recognized as such, and nothing else would), and you will see that it will be much easier if you can refer to the purpose we have for them; i.e. being able to sit (comfortably?) on them.  Without that, it is hard to distinguish between a storage box (not a chair) and a storage bench (a chair).  [Try it. Do a Google image search for storage box and then storage bench.]

In this sense, a species would be more like a Java Interface than a Class.  Classes usually embody the pre-existing forms viewpoint, i.e. the notion that attributes and behavior are really "in the thing" rather than merely "how we want to look at it".  And while in practice Interfaces are often just wrappers around class definitions, ideally, each Interface defines a standard socket into which an object of any "form" may fit, as long as it can perform a certain "role" and participate in a certain "protocol" (see my definition of component).

SO, the lesson to learn is: When considering the purpose of a thing as a part of its definition, "purpose" is both its purpose, and our purpose for wanting to recognize one in the first place.

POSTSCRIPT - July 4th, 2011
Once again, I see that I've come to a brilliant insight that someone else did a long time ago. In the new "The Philosophy Book", I just found the following apropos quote: "Every way of classifying a thing is but a way of handling it for some particular purpose"- William James.

Class Constructors considered harmful

PREFACE: There is a school of thought in computer programming that Classes are harmful in certain ways, but the basis for those arguments are very programming-technique specific.  This essay is about a much more general, mind-set oriented, objection.

My basic project these days is to learn Philosophy 101 and contemplate what impact that knowledge should have on software development practices.  After reading topics like the Philosophy of "becoming", and Aristotle's "four causes", it is clear that Philosophers spend much more time trying to define the circumstances of an entity's creation than do system analysts and programmers. While Philosophers have long been concerned with WHY did WHO do WHAT to cause an object to come into being, programmers are mostly concerned with the mechanics of HOW an object should be constructed.  It strikes me that this is due to the tunnel vision encouraged by the class constructor method.  [And, due to destructors and automated garbage collection, an even worse situation applies to object “death”.] So, to paraphrase a famous title, I (albeit tongue-in-cheek) consider Class Constructors harmful.

CASE STUDY: At a recently defunct Top-5 bank, I uncovered the fact that there were major incompatibilities in data being used to produce credit scores for borrowers and their loans. The scores depended on a grade generated for a "facility". The problem was that the very concept and definition of "facility" was not the same in various parts of the bank. If they had answered the following simple questions, they would have realized that they were not talking about the same thing: When and why does a new facility come into existence, and when/why does it cease to exist.

In the course of analysis and requirements gathering, a major goal is to identify and define the various business domain entities. But, in a vicious cycle, the definition of an entity is often too shallow with regard to its birth and death because “causal” information often stagnates as merely background text in some requirements document.  This is because programmers have no standard place to put that logic into the code.

Object oriented practice has one put "all" the properties and behavior associated with an entity into its Class definition, where "all" for class Dog means "the dog, the whole dog, and nothing but the dog"[1].  However the "nothing but the dog" constraint means that, the logic involved in deciding whether an instance of class X should be created, is not normally a method of class X.  Since the "cause" of X's instantiation usually involves other classes, that logic lies outside of X proper, thus, standard development methodologies leave the analysis of causation and purpose out of the design of class X.  Even Factory classes are focused on object construction, rather than why it should be constructed, and why now, and by whom.

The Mediation pattern comes to mind as a place to put this sort of logic because it involves multiple classes.  The logic that decides it is time for a Sculptor to use a Chisel to carve a Statue out of a block of Marble doesn’t belong solely in any of those classes.  A programmer would be tempted to put a “carve” method in Sculptor since that is a “behavior” of the sculptor, but Philosophy considers it an essential part of the definition of the statue itself.  And that is a problem with Mediator classes in the first place; the desire to have everything relevant to X be “nearby in the source code” (a raison d'être for classes) is defeated when some of it is off in various Mediators.  Having the teleology of Statue off in some CarveMediator isn’t much better than it residing in Sculptor.carve().

With event-driven systems (e.g. MOM, SOA), the series of events that trigger the creation of an entity instance may be complex. And whether event-driven, or "batch processing", the sub-systems are often distributed, increasing the value of encapsulating this logic in a single place. With Java EE and service oriented designs, there would be value in having the entity services include this logic.

In any event, I believe that there is a need to learn from Philosophy that their concept of "form" (which is the equivalent of OOP's class) has always included the purpose of a thing as well as its blueprint.

[1] Object Oriented Analysis and Design, Grady Booch,  1991

Silver Bullet: Model the world, not the app

DISCLAIMER: Ok, I admit it...this is cut/pasted directly from my brain fart notebook, i.e. not ready for prime time...but dammit Jim, its just a blog!

In the arsenal needed to fight unsuccessful software development projects, it will take a whole clip full of silver bullets.  One of those silver bullets, I believe, is more accurately modeling the world using knowledge of Philosophy.

There is a great struggle between getting everything "right" up front,  versus, doing "just enough" specification and design.  When trying to balance "make it flexible" in order to support future re-use, versus XP mandates like "don't design what isn't needed today", it is hard to know (or justify) where to draw the line.  Due to "changing requirements", those "flexible reuse" features (that were merely contingent at design time) are often mandatory before the original development cycle is even complete.

WELL, lots of requirements don't change THAT much if you are modeling correctly in the first place.

Humans haven't changed appreciably in millennia, even if the roles they play do.  So, if "humans" are modeled separately from "employees", it is that much less work when you later need to integrate them with "customers". [Theme here is "promote roles programming", the justification of which is made more obvious when taking essentialism to heart.]

In general, the foundation of one's data/domain/business/object/entity-relationship model is solid and unchanging, if all "domain objects", "business objects", etc are modeled based on a clear understanding of the essential versus accidental aspects of the "real world", and NOT based on the requirements description of a particular computer system or application.  Modeling based on "just what is needed now according to this requirements document today" is too brittle, both for future changes, and especially for integrating with other systems and data models.

After all, adding properties and relationships to entities is fairly easy if the entities themselves are correctly identified.  It is much harder to change the basic palette of entities once a system design is built upon them.  Also, all the more reason to be sure and not confuse entities with roles they can take on.

Example: I don't have to wonder who I might have to share employee data with if I realize that an "employee" is actually just a role that a person takes on.  If I model the essentials of the person separately from the attributes of the employee role, it will be much easier to integrate that data with, say, a "customer" database later.  If the customer data model recognizes that "customer" is just a role that a person takes on, its Person table is much more likely to be compatible with my Person table than would be the case with my naive Customer and their Employee tables (and still other Patient tables, etc, etc.)

Do Objects Have Souls?

While writing the article, Implementing "Real" Classes in JavaScript for Developer.com, I was tempted to add a sidebar with the provocative title "Do Objects Have Souls?".  The article itself demonstrated a technique for simulating Java-like classes in JavaScript, and as introductory material, it explained the difference between Java's "class"-based semantics versus JavaScript's "object prototype"-based semantics.

For Java programmers: In a nutshell, Java creates object instances that have all, and only, the properties of its Class, and the property list is fixed over the life of the object. In JavaScript, object instances have no "real" class, however, each object is free to add and delete properties at any time.  Because of this, JavaScript Object objects are pretty empty compared to Java Object objects at birth because they can become anything after they have already been instantiated [hence Existential Programming!].

In trying to understand the language differences myself, I began musing on the parallels between philosophical notions of "the soul" and JavaScript's empty shell of an "object" that is generated by obj = new Object;

Souls as property containers

In western philosophy there has been a 2500 year old school of thought that "things" (aka objects) have properties, some of which can never change (i.e. essential properties) versus those which may change over time (i.e. accidental properties).  One concept of "soul" is that it is the bundle of essential properties that constitute a thing.  This idea has also been equated with "identity".  Attached (non-permanently) to the attribute bundle are the various accidental properties.  This sounds a lot like the "empty" JavaScript object which is ready to add and update and delete [accidental] properties, while all the time keeping constant the essential, unchanging, object identity (as referenced by obj !).

When medieval alchemists distilled liquids into their essences they called them spirits because they were the "soul" of the grape, herb, flower, etc. To insure removing all of the accidental properties, they distilled things 5 times to produce the quintessential spirit.  Distilled spirits in the alcohol sense often have names that reflect the notion that they have a life essence captured in them. Whiskey and Aquavit are both names that translate into "water of life" in their original languages.  In the movie Perfume, a villain repeatedly attempts to distill the essence of pretty women using the same techniques as distilling flowers into perfume. [Spoiler Alert: flowers don't survive the process...]

When the Well of Souls runs out of RAM

Another aspect of souls that rhymes with JavaScript is the ancient lore that newborns are given a soul at birth which is plucked from a "well of souls" (aka the chamber of Guf).  In JavaScript, as empty objects are created and given an identity, they are plucked from a heap of available memory (i.e. dynamic memory allocation). In both cases, bad things happen when there are none left.

When the well of souls runs dry, the Messiah will come and reboot the world; when your browser runs out of heap space, your JavaScript will gag and someone will have to come and reboot the browser (or at least the web page).  The plot of the 1988 Demi Moore film, The Seventh Sign, is based on the Guf mythology. Demi's baby is due to be born on February 29 which is the date on which the last soul will leave the Guf and it will be empty.

Moore's Paradox... I'm just saying!

The popular phrase "I'm just saying" has been around long enough for most people to have heard it, but not long enough for it to be well-documented as to where it originated.  I heard a great stand up comic bit about it in the 1980's by Paul Reiser. There are several blog sites that muse over its origin and solicit theories:

• http://prestwickhouse.blogspot.com/2010/01/plain-english-im-just-sayin.html
• http://painintheenglish.com/?p=958
• http://www.urbandictionary.com/define.php?term=i%27m%20just%20sayin%27

It turns out that the most common definition of the phrase exhibits a logical paradox from Philosophy.  The book "this sentence is false" is a collection of philosophical paradoxes, and it describes Moore's Paradox (as developed by G.E. Moore).  I summarize it as follows:

Normally, everything that can be said about the world can be said by anyone. I can say the moon is made of green cheese, and you can say it.  The state of the world described by me can equally be described by you with no logical paradox...EXCEPT... I can say that the moon is made of green cheese, and I can say that you do not believe that the moon is made of green cheese, but YOU can not say the same thing.  I.E. you can not say that X is true and at the same time say that you do not believe that X is true.  Note that you are not saying that you could be wrong in your belief, you are saying that you both, believe X is true, and X is not true, at the same time. A logical contradiction.

However, whenever you use the phrase "I'm just saying!", you are in effect performing Moore's paradox.