The Reign of Quantity

or, Why Two are Better Than One

Matthew Weier O'Phinney
@mwop

Who and why?

Then

Project Lead, Zend Framework
Principal Engineer, Zend

Now

Project Lead, Laminas Project
Product Manager / Principal Engineer, Zend by Perforce

I worked for over 13 years at Zend Technologies, starting in eBiz, and rising through the ranks to lead Zend Framework.
We were acquired in 2015 by Rogue Wave Software, and following some restructuring in 2018, we made the decision to transfer Zend Framework to the Linux Foundation.
CLICK
The Laminas Project launched on New Year's Eve, though we're still working on things like finalizing our technical charter and getting funding.
And I was hired by Perforce, who acquired Rogue Wave, and thus Zend, last year. They are having me continue my work on the Laminas Project, as well as expanding my role into their commercial offerings, which include commercial support for Laminas itself, as well as a new enterprise PHP offering, which we are launching here at SunshinePHP. Please be sure to check out our booth!

What is Quality?

A metaphysical digression

This story begins during my Junior year of college, back in the early 90s. While I studied computer science, a course in artificial intelligence got me more interested in philosophy and religion, as we asked questions such as whether or not it would be ethical to turn off an AI.

So while I studied computer science, ultimately, I earned a degree in comparative religion. This particular course was covering various aspects of the intersection of the mundane and the divine, and the first book we studied as a book by the French philsopher René Guénon, "The Reign of Quanitity, or The Signs of the Times." The book was published in 1945, and questioned the foundations of modernity, mainly in terms of spiritual movements, but also within society as a whole.

What was happening in the world at that time (besides the end of World War II)?

Increasing industrialization, and, particularly, the rapid rise of the assembly line.

The assembly line is an amazing concept. It takes the idea that somebody would know the whole process of building something on its head, and instead breaks the process into discrete pieces, and puts people in charge of just one piece at a time.

This makes training people easier, and can lead to incredible output in the right conditions. However, it also means we end up with specialists, people who know one part of the process, instead of people with the ability to understand how each part of the process serves the final product.

The book covered a lot more, but this was the take-away for me years later: that quality cannot be achieved by quantity alone; it requires an understanding of the system as a whole.

That said, my experience in the martial arts provides a counterpoint.

How many of you have ever trained in a martial art?

How many of you have achieved a black belt or Dan ranking? How long did it take?

I've trained in various martial arts off and on since college, including T'ai Chi, Aikido, and most recently, Hapkido. I earned the rank of first degree black belt in Aikido, a process that took around four years.

Yes, years.

See, the thing about martial arts is that it takes years to build muscle memory and technique. In fact, most martial arts treat the rank of black belt as not mastery, but rather of competence. It is in many ways the beginning of your practice.

But there's another secret: you never train alone. See this image? There's one person performing the technique, and another receiving it.

In fact, they are both training. One is practicing the technique, the other is practicing ukemi, or the art of receiving.

I have never once had to use the techniques I've learned doing martial arts. Falling, though? I've used that one many times!

But the point is, you learn only when you are training together. Sure, I can practice things like kicking or striking with a punching bag, but when somebody else is there, they can point out problems in my technique — preventing me from injuring myself.

One thing that has stuck with me all these years was something Sensei Olsen told me when I was studying Aikido. He had been teaching for around 20 years at that time, and had one broad observation: Students could train with intense focus, and initially have broad gains in their technique, or they train with joy, without much direction. But the interesting part was this: after a period of around two years, the two would have roughly the same skill level. The first would plateau in skill earlier, while the second would gradually acquire skills through sheer repetition.

As you start learning a skill, you initially have a huge gain. For instance, when learning a new programming language, everything is new, so anything you do is something new learned, something new you can apply to a problem.

But at a certain point, you hit a plateau. You're no longer learning as quickly, or perhaps you're not gaining new techniques - in programming, this might be when you are no longer learning basic syntax, or have learned the majority of functions you need to do your current work.

Leonard calls this time a time of integration. The idea is that you keep practicing, repeating the skills over and over so that they become second nature.

At some point, you'll discover there's something more you can do, and that's when the process begins again, and you start on another upward rise.

One of the things that will often trigger new learning is becoming aware of the bigger picture. When we understand the bigger picture, we get a better idea of how to apply what we've learned, or, in some cases, how we've learned it poorly and need to relearn it a new way.

Remember "The Reign of Quantity" from earlier? This is one of the points: that we need to understand both the individual pieces as well as how they all fit together in order to truly achieve balance and move towards quality.

Zentangle

Gratitude and Appreciation
Corner Dots
Border
String
Tangle
Shade
Initial and Sign
Appreciate

To give an example, this past year I started drawing using the Zentangle method, which provides a process for drawing non-representational art.

The process is a set of steps to follow.

At first, you follow the steps. Part of that process is learning tangle patterns you can use. Later you learn that there's concepts such as reticula and fragments, or tanglehancers, or myriad other drawing techniques, and you gradually incorporate those.

The point is, the process is only a framework. It gives you structure to learn and allows you to put pen to paper immediately to get you out of the dilemma of what to draw.

By following the process over and over again, your drawings improve.

Competence and Expertise

A psycho-educational digression

The first one I want to cover are the Four Steps of Skill Acquisition.

This model has popped up under a variety of names since the late 60s. It posits four stages to learning a skill:

Unconscious Incompetence
Conscious Incompetence
Conscious Competence
Unconscious Competence

Basically, we start out not knowing where to even start, and no skill whatsoever. We then start to understand some of the breadth of what we need to learn, while yet acquiring any proficiency. At a certain point, we gain that proficiency, though we have to consciously apply our knowledge. Finally, we get to a stage where we are able to apply our skill without even thinking about it.

The Dreyfus Model

Skill Level / Mental Function	Novice	Advanced Beginner	Competence	Proficient	Expert
Recollection	Non-Situational	Situational	Situational	Situational	Situational
Recognition	Decomposed	Decomposed	Holistic	Holistic	Holistic
Decision	Analytical	Analytical	Analytical	Intuitive	Intuitive
Awareness	Monitoring	Monitoring	Monitoring	Monitoring	Absorbed
Rules-Based		Big Picture

This visualization makes a state machine out of the stages. At each, you can either move forward, or stay at that stage.

Think of it like the spikes and plateaus.

Now, a novice is entirely new to the subject. They will dogmatically follow rules provided to them, without understanding the big picture. At the opposite end of the spectrum, the expert has an intuitive and complete understanding of the big picture, allowing them to transcend rules

The second stage, the advanced beginner, has made a go of it at this point, and is starting to see patterns to what they do. They can remember how they've done things when they encounter them a second and third and more times.

A developer named Erik Dietrich made an observation at this point.

Many developers, in the absence of somebody to mentor and review their work, go on to a stage between the advanced beginner and competence, which he terms the Expert Beginner.

The expert beginner has plateaued. However, they have not yet learned something important, which is how to see the big picture.

There's a reason why that state is off to the side, and doesn't have a next state. Because at this point, they stop learning.

The author talks about this through an analogy, detailing his experience learning to bowl.

He was always athletic, so when he joined an after work bowling league, he picked it up pretty quickly. But he did so unconventionally: he didn't use the holes in the ball, and used a twisting throw to get the ball down the lane. It ultimately worked, and he found as he kept practicing, he improved.

Until he didn't.

If he'd been the top scorer in his league, his path might have ended right there.

But he wasn't, and it was the observation that others were able to do better that allowed him to break out of that cycle. He talked to somebody, and they told him he was doing it entirely wrong, and helped him basically start over in his learning process so that he could properly acquire the skill.

The Expert Beginner

What the Expert Beginner is about is a "belief that expert status has been reached, and thus further improvement is not possible."

We've all been there.

We have success with a particular approach to a problem, and then do it again once, twice, a few times, and start thinking, "hey, I'm pretty good at this!"

And there's nobody else to review what you've done, because you're the only one on your team who has done it.

And maybe you then teach somebody else on the team, or present at your local user group, and still nobody questions what you've done.

And you think, "hey, I might be an expert at this!"

Jack of All Trades

Master of None

Many people do this in serial. They get to that Expert Beginner phase, and then go seeking a new challenge.

A PHP developer might go and learn about databases, and then a caching system such as Redis or Memcached, and then dive into nginx or Apache configuration, maybe play with configuring Docker containers and container orchestration.

Each time they feel they've (AIRQUOTES) mastered (/AIRQUOTES) something, they move.

But really, we all know what a Jack of all Trades is, right?

A Master of None.

Don't Miss the
Big Picture

But How Does This Relate to Software Quality?

Do you want to be a software craftsperson?

Over the years, one thing I've seen come around again and again is the idea that developers don't want to be engineers, they want to be craftspeople, or, as one framework suggests, artisans.

We want to think of ourselves as artists, creating beautiful code.

This is a qualitative yearning.

So, how do we get there?

We Practice

What do we practice?

Coding Standards
Testing

Coding Standards

Just use one

Consistency
Readability

When it comes to coding standards...

Just use one.

Seriously. It doesn't matter which one. Choose one, stick with it, and make sure you have automation in place to fix and check for violations. Most IDEs and editors have functionality built in to do this.

Seriously. I use Vim, and have had plugins in place for a decade or more.

Why do you need one?

Because when everyone on your team uses it, it means that developers are not getting into commit wars over meaningless changes, and everybody is able to grasp the structure of anybody else's code at a glance.

But whatever you do, do not create your own. Use an existing standard, such as PSR-12, or one that's developed by whatever framework you use. Nothing says arrogance so much as developing your own coding standard.

Testing and Making Testable Systems

A Value Object


final class Quantity
{
    private $value;

    public __construct(int $value)
    {
        $this->value = $value;
    }

    public function getValue(): int
    {
        return $this->value;
    }
}

We're trained to test everything. We chase after the code coverage metrics, aiming for 100%.

But the real question is: do I need a test for this?

In this example here, the answer is "No". Why? As a value object, it provides exactly one way to use it. The constructor accepts an integer; the getValue() method returns an integer. The class is marked final, so it cannot be extended, and so there's no way somebody could write an alternate form that modifies its behavior.

Your tools tell you to write a test. Experience and knowledge of your programming language tell you it's not needed.

So that's your first lesson: learn when tests are really necessary.

Covering Your Paths


class ValueOfSomeKind
{
    public function getParameter()
    {
        if (! $this->parameter) {
            $this->parameter = new ParameterValue();
        }
        return $this->parameter;
    }
}


public function testGetter()
{
    $instance  = new ValueOfSomeKind();
    $parameter = new ParameterValue();
    $instance->setParameter($parameter);
    $this->assertSame($parameter, $instance->getParameter());
}

Sometimes it's useful to lazy-load a value. In those cases, if the value isn't set, we use a default.

Our tests may want to do assertions, and because we like to check a return value against a known value, we write an equality assertion like this.

But does this actually test the entire method? No. Because there are two paths possible: one, where we set the parameter explicitly, and another, where we initialize a default value.


public function testReturnsPreviouslyInjectedParameter()
{
    $instance  = new ValueOfSomeKind();
    $parameter = new ParameterValue();
    $instance->setParameter($parameter);
    $this->assertSame($parameter, $instance->getParameter());
}

public function testInitializesAParameterIfNoneInjected()
{
    $instance  = new ValueOfSomeKind();
    $parameter = $instance->getParameter();
    $this->assertInstanceOf(ParameterValue::class, $parameter);
}

Parameter Overloading


/**
 * @param string|array|Emittable $name
 * @param null|object|Emittable $target
 * @param array|callable|Emittable $argv
 * @param null|callable $callback
 * @return mixed
 */
function emit(
    $name,
    $target = null,
    $argv = [],
    $callback = null
)

How many behaviors does this have?

When we talk about behaviors, we're typically talking about what a given function or method will return given specific input.

The above is a real example. It's actually code I wrote once upon a time. How many behaviors does this have?

There are 36 permutations of arguments, but essentially an infinite number of possible return values. It's basically uncountable. Which means there will always be edge cases.

Code like this is not uncommon. In fact, it's often written to provide flexibility and extension points in framework code for end-users.

But the end result is that end-users struggle to understand how the code works, as there are too many permutations.

How do we raise this code's quality?


/**
 * @param string|array|Emittable $name
 * @param null|object|Emittable $target
 * @param array|callable|Emittable $argv
 * @param null|callable $callback
 */
function emit(
    $name,
    $target = null,
    $argv = [],
    $callback = null
): void


/**
 * @param null|callable $callback
 * @return void
 */
function emit(
    Emittable $emittable,
    callable $callback = null
): void


function emit(Emittable $emittable): void
{
}

function emitUntil(
    Emittable $emittable,
    callable $callback
): void
{
}

Finally, we split the method into two, one that accepts only an Emittable, and one that accepts both the emittable and the callback. By doing this, we rely on the language to tell us when we provide an invalid argument, and we force the user to provide their intent behind usage, by selecting the method appropriate to what they want to accomplish.

We've gone from one method with infinite permutations to two methods with one permutation each. There may be other behaviors based on the arguments provided, but there is only one signature.

These changes lead to much clearer messaging about the behaviors, and helps users choose the behaviors they want to opt in to.

Behavioral Thinking

What is the matrix of possible arguments and the expected output from each combination?
What are the possible errors?

Other Things To Practice

SOLID

Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Single responsibility principle: do one thing only
Open-closed principle: open to extension, but closed to modification
Liskov: I should be able to substitute a subtype without altering the correctness of the program
Interface segregation: each interface should describe one behavior; compose multiple interfaces to describe complex or aggregate behavior
Dependency inversion: depend on abstractions, not concrete implementations

Refactoring

Extract Method
Extract Class
Extract and Generalize Types

Code Calisthenics

Only One Level Of Indentation Per Method
Don’t Use The ELSE Keyword
Wrap All Primitives And Strings
First Class Collections
One Dot Per Line
Don’t Abbreviate
Keep All Entities Small
No Classes With More Than Two Instance Variables
No Getters/Setters/Properties

More info in The ThoughtWorks Anthology

...but they're just more rules.

It takes practice

and endless questioning.

Ask for peer review.

...is ask for review from your peers.

Find somebody to review what you've done, who can let you know what you can do differently or do better.

If you can't find somebody where you work, find your local user group. They may even have a Slack where you can ask questions.

Me? I turn to people like Marco Pivetta, who has an unrivaled eye for how to make software maintainable. But I also turn to people like Larry Garfield, who has an eye for determining what code is usable.

But it's also important to ask the junior developers on your team to review your code. Why? Because one of the best ways to become a better writer of code is to read code. And if a junior developer cannot understand how the code works, explaining it to them will help you understand the code better, and potentially suggest how you can simplify it for others to understand.

If there's one thing I want you to take away from this talk, it's that the best path to increasing your code quality and your skills as a developer...