Metaphysics and Software Design

When I say that this is an experimental blog post I mean it.  I’m thinking out loud here.

Those who know me know that I am somewhat critical of some modern advancements in software design.  It’s not that I’m a Luddite or anything but the root of my discontent is that software and real life often do not match well.  Inbox by Google is a good example of this.  They refuse to put an “unread” feature into their software.  It messes with their blessed workflow.  Never mind that sometimes real life breaks the workflow, like if you accidentally click on an item. In the case of Inbox that accident means that you either have to open up other software (Gmail) or snooze the item you accidentally opened.

That’s an example of a mismatch of UX and reality.  But it also deeper than that.  Essentially any place where there is an interface between the human and the machine, from the user interface all the way to an API, there is going to be a mismatch between what the machine needs and how the human needs to interact with the machine.  And our response is often to make the human match the machine instead of the machine matching the human.  And given that the machine is often the interface between two humans, this seems backwards to me.  But I digress.

Consider the old interface with Magento 1.

class ArbitraryClass
{
    public function doSomething()
    {
         $request = Mage:app()->getRequest()->getQuery();
    }
}

How in the world does this break with metaphysics?  Well, one of the principles of Aristotelian metaphysics is that an object cannot actuate a potential that it does not possess.  In other words a ball cannot make water because it does not contain the potential for water.  But Oxygen and Hydrogen do contain the potential for water.  (Remember we’re talking about METAphysics, not physics.  It is very easy to get hung up on that.)

Going back to the example it could be argued that the code is bad code insofar as it breaks from metaphysics.  ArbitraryClass does not have the potential for a request.  How do we know that?  Because it’s Formal Cause (or Form) is not request-like, or request-ish.  And because there is a dissonance between its formality and efficiency, it is broken insofar as that dissonance occurs.  That’s not to say that it won’t work, but it’s workability will be a function of its alignment with its form.

Consider a triangle.  Have you ever seen a triangle?  No.  Never.  “You’re insane, Kevin,”  You might be thinking.  “I have seen triangles all over the place!”  Yes, you have seen examples of triangles, but they have never been perfect triangles.  A perfect triangle exists only in the immaterial sense.  What you have seen are objects that represent triangularity, but due to slightly curved lines, shifts on the paper, variations in the molecular density of the lead, among other things, you have never, ever in your life seen a triangle.

But you can still recognize a triangle based on its resemblance of triangularity.  In other words, it will still work as a triangle just like our code will still work like our code should.  But the degree of its success will be based on how well it confirms to its reality.

You might be thinking that this is all crap.  But let’s look at a more current implementation.

class ArbitraryClass implements DoSomethingInterface
{
   protected $request;

    public function __construct(RequestInterface $request)
    {
        $this->request = $request;
    }

    public function doSomething()
    {
        $this->request->getQuery();
    }
}

$object = $dependencyInjectionContainer->get('ArbitraryClass');
$object->doSomething();

This example follows the principle that an object cannot give what it does not have.  As a result it is also “better” code.

But it also does a lot more than that.  It actually demonstrates some of the fundamental parts of Aristotle’s philosophy.

1. It has an Essence or Form.  The DoSomethingInterface is its form, like triangularity.
2. It does not have “request-ability” and so it must be given by something that does (the Dependency Injection Container).
3. It has its material cause in its instantiation.
4. It has efficient causality.  It “does something”.
5. It has final causality.  It has a purpose.  (nobody intentionally creates un-purposed code)

And so forth.

This does not mean that you are required to code according to philosophy.  What it does seem to show is that the quality of code can be measured against how well the code fits against a logical metaphysical framework.

Bear in mind that this idea is new to me and there could very well be some disqualifying concept that renders this moot.  I’m, in a sense, debating myself in public.

But the flip side of this is that if this is correct, and good software does seem to follow good metaphysical flows, that may be able to be a framework for people to write code that is not only better, but works better in the real world.

But then again, this would turn programmers into Philosophers and God help us if that happens.  🙂