Designing the Husserl Way

Designing is hard
One of the most common difficulty I had to face when trying to create an application, being a business app, or a purely technical framework, was that frankly, nobody really knows what he/she is talking about to the level required by a machine.
Before computers, one could always rely on some sort of human interaction to fill in the gaps, to clarify things when needed, and fix the obviously wrong side effects of any process. Fully automated process dealing with many transactions per second can't have any of those side effects, and that makes things orders of magnitude harder.
People think computers are smart because they do so many great things. Well, here's the secret : a computer is about as smart as a biological virus. It has absolutely 0 intelligence, it doesn't understand anything at all . Create some object called "User" in your code, with a property named "age" that you defined as a number, and put that in your regular HTML web page for someone to fill in his age. Well, you may enter 0 to 4 billion without the computer even blinking an eye. Unless a computer programmer explicitely performs a check (such as  "check that the age isn't greater than the maximum age of a human being, like 120 years"), your program may have potentially weird behaviors.
The consequence is that, as someone whose job is to have a computer behave like something that's smart, you've got to somehow know and understand every behavior, in every kind of combination, without any supposition at all (and things get even worse when you're dealing with security, where users might do crazy things on purpose).

Design & philosophizing
So how do you do it ? How do you get to know every single behavior, item of logic, in every actor of the process you're trying to model ?
Well, there are other kind of people that had the exact same kind of issues as we're having, and among those are philosophers.
When you (actually, I) think about it, a philosopher trying to think about a particular issue that no one did before follows quite the same train of thought :

1. What is it i'm talking about when i'm talking about this specific problem ( take, for example "is it morally right to kill someone ?")
2. Let's decompose the problem into bits (ie "moral", "to kill", "someone")
3. Let's define every bits as precisely as i can ( and if i need more concepts, or if my language doesn't provide me with the tool I need, let's invent new words, or give regular words a slightly different definition).
4. Once those definitions are clear, let's see how the bits assemble to try to solve my problem and get an answer.

Computer scientist often learn about object oriented programming, functional programming and algorithmic at school, which deals with writing down the answer the best possible way once you know it, but i've never seen a lesson on how to find that answer. Note that when dealing with mathematic or physic issues, the issue of formalizing the problem is dealt by physician, or mathematician using scientific concept, in such a way that computer scientist don't have much work to do other than feeding the computer.
But with business processes, things are much more fuzzy. Typical IT projects involve functional specifications and technical ones. Functional specification are supposed to deal with all the steps described before, and technical specifications is just about feeding the machine. The problem is, as i've stated in the introduction, no none-computer scientist can realize how imprecise our common definitions of the world is. Most of the time, computer scientist are left with trying to fill in the gaps, and most of the time (to my experience), those gaps are huge.

Tips from Husserl
Last time I read books about phenomenology (invented by Husserl), which deals with steps even before step 1 (that you may sum up as "how do i get knowledge of things around me", bringing the observer into the game) but which has impact over all the other steps, i was amazed to learn about his method for trying to identify "objects". This method is called "eidetic reduction".

It's quite simple, and you may probably already do it naturally when you're doing Object-Oriented design. But it's always nice to identify what you're doing, so that you may get back to it when you're lost. The method is just to make your object's properties vary mentally to a great extent, and see if the nature of the object you're trying to define remains the same.
It's really simple, but let's see how it works :

The chair example
Let's suppose that you're trying to build an interior design software, and are currently working on the "Chair" object.  Here you are, creating the "Chair" class in Java programming language and trying to figure out which properties you should have in that class, which are optional, which are compulsory.
Here's what eidetic reduction tells you to do : pick every single property and make it vary by a great deal. If the essence of the object remains the same, then the property isn't characteristic, and doesn't belong to the definition for that class.
As an example, your first intuition would be that a chair had a color, and thus you'll probably create a "Color" property for the chair. But following Husserl's method, i can say that an object being red, green or blue, or even transparent doesn't change anything to the fact that an object can be described as a chair or not. Same goes for the matter : the fact that the object is made of wood, or plastic, or metal, doesn't tell you if it's a chair or not.
So what properties are charateristics ? Well, let's see what the dictionary tells us (dictionaries are a really good starting point, even for things you may consider obvious):

"A piece of furniture consisting of a seat, legs, back, and often arms, designed to accommodate one person."


There you go : if what you want is to have a "Chair" class, then the only properties you need that belong to that class are a "seat" property, an array of "legs", an array of "arms" and a "back" property.
Let's check that using Husserl's method : try to think of a chair, and remove the seat, is it still a chair ? nope.  Now let's do it the other way : let's take any object and give it a back, a seat, legs and arms. Could it be described as a chair ? For the most part, yes (1).

Now, you may tell me : "but, hey come on, a chair do have a color and a matter !". You are right, they do, but these are not characteristic. What colors and matter are characteristic of are Physical Objects (2) Nothing prevents you from having the Chair class inherit from something else.

More on the chair
The questions i've asked so far were only of the form "if it has no xx" or "if it has", but eidetic reduction is more precise than that. It tells you to make properties vary not just be or not be. What does that mean in our example ?
Well, take the number of arms for example : suppose that i build an object which has 2000 arms. Would that be a chair ? well, most presumably not. There's a limit to the number of arms that an object can have and still be considered a chair instead of just a piece of art.

That will bring us to the another coming post of this blog about quantities and why it matters so much.



Notes:
(1) For the most part only, because if you think about it, the back, the seat legs and arms need to be in certain positions for the chair to really be a chair.  Thinking about those things more deeply will probably makes a modern artist out of you :)

(2) i can't think of a physical object having no color or no matter, and any object having a color and a matter can be thought of as a physical object. One may even go deeper, and say that color is a property of matter. Another interesting property you may add to Physical Object is its coordinate in space. Once again, i can't think of a physical object having no coordinates, and the fact that something has a coordinate tells me it is a physical object.

Why Codo Sophia ?

I'm doing programming as a job and philosophy has been a hobby for the last 10 years. During all those years I couldn't help but noticing the fundamental similarities between the work of philosopher that tries to put the world into more or less abstract concepts, and the work of a programmers that tries to model a specific problem into classes, objects and properties.

It only occured to me quite recently that this was no coïncidence :  greek philosophers (mainly Aristote) created basic logic, upon which all reasoning should be based but also upon which computers and all programming languages are built, as well as the notion of categories and properties which are today's main tools for structuring code in object oriented programming.

But, as philosophy is only a hobby, I didn't feel quite legitimate to say out loud that this was an interesting or even relevant point of view. That was until University of Oxford decided to create this courses.

This blog is aimed to be a place where the sets of methodologies, thinking and conceptualization found in philosophy and programming mix. It will try discuss how things learned as a computer scientist could benefit to subjects regularly discussed from a purely philosophical point of view (such as political, moral or ethical issues), as well as the opposite.