The master potter and his perfect tea mug



Imagine you are a master potter and you have five keen apprentices. You have a
shelf full of masterfully crafted tea mugs. One day you take one of your best
tea mugs from the shelf and show it to your five apprentices. Then, as an exam
for them to show what they have learned so far, you ask them to take a careful
look at your best mug, then return to their workbench and make a copy of this
mug. All five apprentices study the mug for a while, looking at it from
different angles, making notes, and then they start working.

Ten minutes later your first apprentice comes to you with his new mug. You
briefly inspect his mug and try to hold your smile as it doesn't look like a
tea mug at all, not to speak of your tea mug. It's just a partially dried blob
of clay with a hollow in the middle that makes it vaguely resemble a mug.
Naturally you say to him "You know, a mug is not supposed to look like a blob.
The mug has to have a particular shape, like mine does, to fulfill it's
function, which is to hold liquid. Go back and try again." Your first
apprentice smiles happily but desperately, grinds his clay blob back into a
nugget and returns to his workbench to start again. All other apprentices
overheard what you just said to him and make adjustions to their work.

A short while later your second apprentice reports in with his tea mug. His
work has a shape of a container which can hold liquids. But he made a mistake
with the material and it's made of carton. You look at the mug, and say "Well,
your mug sure looks like a mug, and it can definitely hold liquids, but it's
not made of clay and therefore it will not have longevity." Your second
apprentice whimpers from your feedback and destroys his mug as the clay had
already hardened. All other apprentices overheard your exchange and discreetly
throw away all other materials but clay.

A considerably longer while later your third and fourth apprentices report in
with their mugs at about the same time. You address your third apprentice
first. You take a look at his mug. Things are definitely looking better. It
has the shape of a mug, so it can hold liquid. It's also made of durable clay
and painted with this beautiful dark brown organic paint that you had used.
You give him feedback: "This looks good, but there's one thing - it doesn't
have a handle like my mug does." You put his mug back on the table and shrug
your shoulders.

You address your fourth apprentice. He came to you about the same time with
your third apprentice. You take your his mug and examine it thoroughly. This
mug also looks and feels much better than any of the stuff your first and
second apprentice brought to you. You say to him: "This mug is good too. It is
shaped like a mug. So it can hold liquid. You have made it out of clay. It
also has this beautiful handle, which the previous mug did not have. But you
missed one thing. My mug is painted with this beautiful organic dark brown
paint. Looks like you haven't painted your mug at all. Mine is dark brown and
yours is as gray as clay can get." You give your both apprentices a thumbs up
and they return to their workbenches. The fifth apprentice overheard your
conversation and starts making modifications which would result in better
outcome for him.

After about an hour later your fifth apprentice comes to you with his mug. You
raise your eyebrow and start examining the mug. It certainly is shaped like a
mug, it can hold liquid, it is painted with this beautiful organic dark brown
paint. It also has a sturdy handle. You ask everyone to stop what they were
doing to hear you. You point at your apprentice and say: "Good work. This tea
mug is about the first serious attempt of making a decent copy of my tea mug.
But let's see what happens." You then get some hot coffee from the kitchen,
pour it in the mug and wait. After about a minute, the handle suddenly breaks
off from the mug. As you were holding the mug just from it's handle, the mug
itself shatters to the floor resulting in black coffee over the floor.

You turn towards your fifth apprentice and say: "Did you test your mug with
liquid in it? The handle was too rickety. It was attached to the mug body in a
way that I knew it just couldn't support the weight of the liquid when the mug
is full." Your fifth apprentice shakes his head in shame, gets a broom from
janitor's closet and starts cleaning out the mess. Now that you've seen what
all your five apprentices brought to you, you conclude that none of them was
able to reproduce your perfect mug.

After some careful introspection, you realize that in order for your
apprentices to be eventually able to produce your perfect mug, you would have
to indulge yourself into a long and arduous process of iterative trying and
retrying in which imperfections from your apprentices' creations would be
removed one by one, until they will slowly start hitting the target and
produce copies your mug that not only look like your mug, but would also
contain all the required properties, attributes and qualities of your
creation.

(Important survival tip: Attribute is a quality that is attributed to someone
or something. Property is a quality that exists without any attribution.)

You convey this understanding to your apprentices and comfort them that should
they choose to pursue their craft, they will inevitably get it right. You also
ask them to have a gathering later on this evening in which they would sit
down and discuss about what happened and think of methods how to make the
perfect tea mug. Fast forward this evening and your apprentices approach you
with a paper that reads...



The perfect tea mug
-------------------



How to create the perfect tea mug? Answer: Define it.

Definition of something is one of the most profound questions there is. Many
of us have been trained to think by the lines of class-based object oriented
design. As a result, most test architects would go at this task and try
defining a perfect tea mug by choosing "the Plato's path". In doing so he
attempts to reach an accurate definition of an object by defining a set of
classes, or Platonic ideals, if you will. The aspiring architect, as is often
taught, will create a taxonomy of classes, subclasses and superclasses, which
will not only describe what the tea mug is, but also it's context, and each
class does this via attributes they own. "Plato's path" is, bluntly put, about
creating a perfect clockwork of classes with an assumption that when it's done
right, it will capture the essence of what a perfect tea mug is.

Now I'm going to write - and let me emphasize - in a wildly speculative manner
- of how some of our greatest thinkers have affected the way we think about
writing software.

I honestly think Plato was one of the greatest thinkers to ever walk the
earth. With that being said I think Plato's path has always appeared to me a
little paranoid. What? Am I implying one of our greatest thinkers was a
paranoid? Is that I'm saying? Absolutely no. I'm addressing his logic, not
person. Also, when I'm using the word "paranoid", I'm using Dr. Albert
Bernstein's definition of the term:

"To most people paranoid means delusions of persecution. The word really
describes an exquisitely simple way of perceiving a complex world. Paranoids
can't stand ambiguity. In their minds nothing is accidental or random;
everything means something and everything is related to something else...
Paranoid Personality Disorder.... Paranoia is easier to understand if you look
at the patterns of thinking rather than the false beliefs themselves.
Paranoids are blessed and cursed with the ability to perceive very tiny cues.
Unlike Obsessive Compulsives, who become overwhelmed and confused by life's
small details. Paranoids drive themselves crazy by trying to organize details
into a coherent and unambiguous whole."

In most cases Plato's path can be successfully applied to create the perfect
clockwork of classes. But as software grows in size and complexity, and as
every tester worth his salt and with even a little experience in the wicked
problems of testing, like for example, propagation costs (= you make a fix to
module A, but this same fix breaks module B and C _by propagation_) can tell
you, there are these little "crannies and nooks", which in their vast
diversity in ways of how they manifest, are almost impossible to generalize or
abstract into a cohesive set of rules which would power up The One Test Case
To Rule Them All(TM) that would be able to predict and detect all propagation
errors.

So by stating that the perfect clockwork of classes can eventually solve every
problem in software development and testing is to me a mildly paranoid
statement. But remember that it's paranoid according to the definition of by
Dr. Bernstein. Such a statement would suggest that everything in our world,
with it's unique diversity, imperfection, dirtiness, spookiness and messiness,
could be squished into this comfortable and beautiful clockwork that fits
neatly into a box that is of human design.

So what am I offering in return? If you know the history of western thought,
it should come quite logically.



Aristotle's path



In western history of thought, Aristotle's train of thought has gained
considerable success in comparison against that of Plato's. It introduces a
welcome dose of anarchy into Plato's delicate clockwork of abstractions, or
classes, that have captured perfection of all things. The story of the perfect
tea mug contains the essentials to understand how the code Aristotle's would
have written would have been different from the code Plato would have written.

First, the story has the concept of a platonic ideal, the universal perfect
outcome, the perfect tea mug-ness. Second, the story has five failed attempts
of cloning the perfect tea mug. All five objects created in the process are
imperfect, but all of them contain perfect tea mug-ness to a smaller or lesser
extent.

Aristotle would look at this story and admit that the potter has showed his
apprentices quite an impressive tea mug. But that mug is by no means perfect
or any kind of manifestation of any abstract perfect tea mug-ness. This is
simply because there is no such thing. There is no perfect abstraction
(=class) that any of these five, no, six (now including the potter master's
mug), mug objects would have been cloned from.

Furthermore, a "tea mug" object itself, not class, would represent the
properties and functionality of what is known as a tea mug in general. What
the potter's apprentices have in their hands is five clones of this "tea mug"
object. Note how the word class was not used in any of the two previous
sentences.

Compare this to the more Platonic, "class based" paradigm, where there would
be a "mug" class (not object) extended by something like "tea mug" class, and
then we could just happily go and clone perfect tea mugs from tea mugs class.
See the difference?

The difference is: If you code with Aristotle, forget about classes. Code with
objects only. You may even assign attributes and properties to the objects you
create. But if you destroy an object, it's properties are gone forever.

In this kind of world, you have two ways to create new objects: 1) 'ex nihilo'
which means creating object literally out of nothing or 2) cloning an existing
object. If you clone an existing object, the cloned object will have the
attributes and properties of the object it has been cloned from. Note however
the crucial difference: The properties of cloned objects do not derive from a
class which would be common to both objects. Because, again, and I'm stating
this with a strong dash of humor - Aristotle would have written code without
classes.

In exchange for ditching out the classes, what you get in return is mutable
objects. Because objects in the system are not tied to any particular class,
they become mutable - in other words the objects may i.e. lose or gain
attributes and properties while cloning from one object to the next, and in
this way profoundly change their form. This is a subtle but important
difference. Because it can change the way you can write your software and
presents new ways to think of software architecture.

I have had some experience with strictly class based architecture with
immutable objects and well thought Platonian delicate clockwork of classes.
This kind of architecture contains two kinds of classes: stable and unstable
classes. The stable classes are usually the oldest ones. The unstable classes
are often newer classes which are still in development. The problem with this
kind of class based architecture is that eventually some of stable classes
tend to become "super stable." It means they become like mountains. They
cannot be moved. They cannot be changed easily. And they just keep on growing.
The problem is: when their growth starts veering off in a little bit wrong
direction, and while that unwanted growth is slow, it is almost unstoppable.

This all in contrast to a classless system, in which you have no classes which
would deform into this cancerous "super stableness". Instead, you can keep the
base of your architecture in constant churn and evolve it towards directions
that are stipulated by requests that come in later, of which you had no idea
at all when your architecture was created.



Classless programming



If the reader is astutely familiar with paradigms of object oriented
programming, he will find the words of my previous chapter familiar, because
as it is with most things in this world, whatever may come to many of us as
new revelations, it's highly probably someone has already been there in the
past. Classless programming is no different.

What I just described to you is already known as "prototype based programming"
or "classless programming", which is a paradigm of object oriented
programming. It is not scripting. It is object oriented programming without
classes. You can read more about it and it's history from wiki. To me,
classless programming is the ultimate showdown between Plato and Aristotle,
and looks like Plato is winning. But this upper hand is not necessarily
because of superior design. It is so because it's easier to think and spin
logic that way. Many programmers find classless thinking - a world without
abstractions - unfamiliar, difficult to conceive and some might find it even
alien.

Be as it may, classless design can offer us a very powerful tool especially in
the field of testing. During the rise of AI and machine learning, testcases of
tomorrow will probably be programmed in a new way - in a way they can adapt
and evolve. If you stretch your imagination a little bit, you could literally
see how such a testcase of tomorrow(TM) could be programmed into thinking:
"Let's see, during previous months metric A was relevant for this test case
but it's now reading just '78' all the time. I will remove metric A from my
properties and therefore my future clones will not carry or worry about that
property either. Then again, metric B has been changing wildly so I'm adding
it into my properties instead."

Isn't it amusing how all of our code, in all modern achievements of our
technology, still have fingerprints of some guys who lived around ~300 BC all
over them? Are there any other great philosophers out there who we might have
accidentally overlooked? Hopefully, with a little push provided by my writing,
just like Socrates, you are now able to recognize at least two worlds object
oriented architecture: 1) the apparent world, the world of real objects, which
constantly changes, and 2) an unchanging and unseen world of perfect forms,
the world of classes, the perfect clockwork, which however may be the cause of
what is apparent.

Code well.