Visual Debt. Really?

Here’s how Jeffrey describes the term:

Nobody talks about visual debt. It’s not a thing. Yet it is. We all spend eight hours a day staring at a computer screen. Like it or not, each line of code is fighting for your brain power and energy, and we only have so much to give. Sadly, the current trend in the PHP community is one that pushes for more complexity, not less.

While I don’t disagree with all the points in the video, one of the central concepts troubles me a little:

…each line of code is fighting for your brain power and energy

It’s a good point, as we do only have so much energy and so much attention to give. Let’s look at the code used to explain the concept of Visual Debt, which you can see below.

It’s one quite exemplary of modern PHP, using a variety of modern development practices, such as interfaces, return types, and type-hinting.

interface EventDispatcher
{
  public function listen(string $name, callable $handler) : void;
  public function fire(string $name) : bool;
}

final class SyncDispatcher implements EventDispatcher
{
  protected $events = [];

  public function listen(string $name, callable $handler) : void
  {
    $this->event[$name][] = $handler;
  }

  public function fire(string $name) : bool
  {
    if (! array_key_exists($name, $this->events)) {
      return false;
    }

    foreach ($this->events[$name] as $event) {
      $event();
    }
  }
}

During the video he progressively refactors it until it becomes more like this:

class SyncDispatcher
{
  protected $events = [];

  function listen($name, $handler)
  {
    $this->event[$name][] = $handler;
  }

  function fire($name)
  {
    if (! array_key_exists($name, $this->events)) {
      return false;
    }
  }
}

Quite a lot simpler, no?

At this point, Jeffrey argues that the visual debt is removed, such that the code is now less complex, requiring far less mental energy and effort to work with.

But that’s my issue, the code in the original example — well most of it — would help result in less code, not more, over the course of a project.

Let’s take a before and after look at one function out of the example used, to further clarify my point:

// before
public function listen(string $name, callable $handler) : void
{
  $this->event[$name][] = $handler;
}

// after
public function listen($name, $handler)
{
  $this->event[$name][] = $handler;
}

In the before example, it’s explicitly clear what the parameter types are and what the return type is. Contrast that with the after example. When calling this method, you’ll then need to either:

1. Add some form of validation to ensure that the values passed to the function are of the correct type

Or

2. Perform explicit casting to ensure that the code works consistently given the ability to pass anything in

Then there’ll need to be tests that test against different values to ensure that the code works correctly based on freedom to pass anything.

Why not let the language do that for us? Why not let it help us help ourselves, when it’s able to?

By being less explicit you’ll end up having to write more code; code which “will fight for your brain power and energy”.

Consider these two questions:

• Does less code not equal less maintenance and therefore less effort?
• Is less effort not one of the main reasons which the video cites for reducing the amount of code in the cited examples?

To me then, it’s ironic that we’d not use the language features which allow us to do less, not more. And the lack of a nuanced discussion about the benefits of using some of these features — showing us that they can actually help, and not hinder, us — is also concerning.

To be fair, there’s nothing necessarily wrong with writing either way; after all, flexibility’s one of PHP’s great strengths. Unlike other languages, such as Go or Python, PHP has no one right way of doing things. With PHP, you can use it for whatever you want — in the way that suits you best.

I just wish Jeffrey’d said that, and provided a much more nuanced discussion about why he feels as he does. I wish more time had been taken to qualify — in a less sweeping way — some of the assertions made.

In Conclusion

I realise it was a short video. And I realise that the central theme was to call us all to question the beliefs we have about how we should code. As he is a community leader, I praise him for using his influence to do so.

What I don’t agree with though is the dismissive treatment of some of the newer language features — especially given his position as a community leader. I believe this will discourage a large number of junior developers from even learning about the features, let alone using them where they makes sense to do so.

I believe it may also encourage a blinkered perspective to how developers should use the language; one which can lead to sloppier code and very real, not to mention costly, technical debt.

That’s my opinion. I’d love to hear yours!

CC Image Courtesy of GotCredit on Flickr