Published Jun 10. 2018 - 6 years ago
Updated or edited Dec 2. 2020

Why I hate complexity

It seems to me that a lot of software problems are solved by adding complexity. It's a bad solution. I hate it.

Nerd alert

This is NOT about fly fishing or fly tying, but about site development and nerdy stuff.

I have just fiddled with installing a PHP library from Google. The library allows me to extract data from Google Analytics in my own routines, save them, work with them, present them.
This is smart because Google Analytics does not make it particularly easy for users to find the data they want, and it's not easy for me to present them integrated with the web site. In addition, there are some analysis, which are difficult to do in Analytics. By extracting data I can get data collected, calculated and shared as I would like.
Enough about that. Back to the core of the story.

Google Client Library

Google offers a small PHP example that shows how to use it. Easy enough: you download the example, which is under 50 lines of code, and put it on a server. Easy-peasy. All that's missing is Google's Client Library itself. The thing that integrates to Google's services. Also quite easy. You can download all the files from GitHub and put them together with the example.
But this is where the fire-spewing dragon starts sticking out its ugly head.
The first warning sign is that Composer is needed.

Composer is the new black in PHP. Composer is a so-called application-level package manager or dependency manager, which helps keeping track of the software packages and external dependencies that a particular feature needs.
A WYSIWYG editor needs some JavaScript.
Images displayed in a popup often uses something similar to the Colorbox library.
If you want to access to a Mongo database, you need some abstraction routines to handle that connection.

Once it was enough to know just that. You then located the necessary library, module or API, downloaded it and installed it. Typically a ZIP file with a handful of files, which were packed in a folder. Unzip and place somewhere suitable, maybe activate and/or configure and everything was good.
But things are not that simple anymore.
The dependencies are more complex. Libraries are now being followed by countless files and folders: include files, config files, numerous other libraries, external API's, examples, profiles, templates, automated tests and all kinds of more or less necessary or weird treats.
That also goes for the Google Client Library.

5,600 files, 349 folders

After running Composer as prescribed, my folder with the example now contained a sub-folder called vendor.
That folder contained more than 5,600 files in 349 folders!

To put that in perspective: The Drupal installation that this was supposed to run under – an entire Content Management System with user management, content management, themes, design, and the whole 9 yards – consists of just over 1,100 files in 149 directories. The installation of Google's library just increased number of files sixfold! To get a single feature, namely integration with Google Analytics.
Disgusting! Naughty! And quite likely unnecessary...

Disgusting! Naughty!

A symptom

This little experience is quite symptomatic for what currently happens with much code and many programs. I am an old guy who remembers when you coded with efficiency and minimum resource consumption as a goal; you counted bytes and even bits, counted clock cycles, and limited and cut where possible.

It's true that you don't have to think like this to the same extent anymore. But it seems to me that many developers – both in connection with the programming process and in the resulting code – don't consider the resource consumption and size at all. They happily install management tools, frameworks and code libraries without considering whether it's optimal, useful – or even necessary.

The list is endless: SASS, Twig, JQuery, Git, Composer, Compass, Assetic, Symfony, Laravel, Bootstrap... The norm seems to be that you add one more tool, one more framework, one more library to solve the problems, which have come as a result of the increased complexity of the project.
A more rational solution would be to remove something and simplify, or...?
Maybe I'm just too old school to understand why the opposite is smart. I'm having a hard time understanding how it might be a benefit to a library that it should be installed with Composer. I simply consider that a sign of it growing too big to grasp.

Files, folders, space
Files, folders, space
Martin Joergensen

Increased distance, decreased insight

I can easily see some advantages of using tools and methods like Composer, Git, SASS, Twig and others to automate and manage complex processes. Frameworks are also smart. There is no need to start from scratch every time. My problem with them is that they rarely reduce the original complexity, but just hide it – while making things more complicated and often delivering so much more than you need.

The developer doesn't have to decide what to add and, not least, remove. He or she avoids making decisions and, in many cases, also avoid any spur of creative thinking. The unconscious use of finished libraries, frameworks and tools simply removes the developer from the core, deprives him or her of knowledge, and indirectly reduces the desire, ability or willingness to refine, to optimize and to rationalize – and thereby make better, simpler, more efficient and clearer code.

Drupal 8,000

My favorite development platform, Drupal, came in a new version in 2016. Drupal 7 went to Drupal 8. I've been with Drupal since 4-point-something, and from there, it has made significant improvements from version to version. But the improvements have come at a price.

Drupal 4 consisted of a staggering 103 files in 13 folders.
The Drupal 5 heir was about 275 files in 50 folders.
In version 6, the number of files doubled, but the directory hierarchy could still be kept just over 50.
Version 7 again gave a doubling in files, but originally in more than 100 directories, growing to almost 150 directories in the latest update.

OK, the complexity was increasing and overview decreasing... and the solution?

Proudly presenting! Drupal 8: Drupal 8.3.6 consists of 13,021 files in 4,030 folders! Seriously! Not just a doubling compared to the predecessor, but four times as many files in almost ten times as many folders. See, that's something that can give you a sense of control!

PS: The code isn't the only thing, which is overly complex. Documentation lags severely too, existing in several incarnations and not very well organized. This article has some very valid points.

Martin Joergensen

Zip with growth issues

Another example: I wanted to create a Drupal feature that could offer download of all original files for a given node's associated images. There would typically be 5-10-20 images for a node, and I thought it would be appropriate to pack them in a ZIP file and then let the user download them.

There are plenty of download modules for Drupal. Download, DownloadFile, File Download, ZipCart, Pclzip and more. They are not all big, but still. Several of them use pclzip, which is a library that can handle ZIP files.
They were all overkill for my use.
ZipCart even offers a form of shopping cart for files, with "Cool JS animations if JS is enabled to see the downloaded item zoom to the cart."
Such a praise gives me chills – and not of the good kind. It's not something I want to drag into my code just to be able to zip some files.

Not least because... PHP can already zip files... without further ado!
A built-in class in PHP can zip and unzip files without additional installations.
The result: a solution of about 10 code lines plus a 20-30 more to do a little household. All implemented as a feature of an existing module.
Simple, efficient, compact.

PS: I have to confess, with permissions, menu items and all it was 120 lines... I just counted. But the core is this:

    // Create the zip-file
    $zip = new ZipArchive;
    $zip->open($zipname, ZipArchive::CREATE);
    // Add each of them
    foreach ($pics as $pic) {
      $pic = node_load($pic);
      $file = drupal_realpath($pic->field_image[LANGUAGE_NONE]['0']['uri']);
      // the extra basename removes paths
      $zip->addFile($file, basename($file));

Simplification through division

I'm not completely blind to actually simplifying by dividing things into multiple bites and that something that looks more complex can give better organization, and through that be a simplification.

You can split large lumps of code into smaller, logical bites.
You can collect related routines in include files.
You can isolate configuration data into their own files.
You can put graphics files into a subfolder so that they do not mud the main folders.

Everything is part of the development that, for example, Drupal has gone through. But this alone can't explain the growth. There has also been added more external libraries, new features, elements that were previously options, and altogether a lot of things have gone into to the otherwise pretty clean and compact core.

Compile, link, run

Much has happened during my upbringing and development with programming. When I started programming in Assembler, C and Pascal, you wrote your code in flat text files, compiled and linked them using complex commands, which had to be written in hand or added to batch or make files.

I remember the revelation when Turbo Pascal was published. Yes, in 1984! That's how old I am... Suddenly you could write the code, compile it, run it, debug it, all inside the same programming environment. No cryptic commands, no make files, no parameters or switches. You pressed a function key and the program ran. Press another one, and an executable file was generated.
That was a huge step forward, and vastly simplified the programming process!

Today I mostly program PHP, and it's largely the same. I work in an environment where there is intelligence in my editor, immediate execution of the completed code as soon as it's saved, useful error messages, and access to a debugger that helps tracking errors as well as a profiler that can help find slow routines.

The return of the command line

But with the advent of many of the new development platforms, Drupal 8 as one of them, but also the many React systems, Python frameworks and other systems, the command line has gotten a renaissance.
Access to a well-functioning Unix command line on the modern developer's favorite machines – Macs – has made even the most hardened MacOS enthusiast forsake the delicious graphical interface and fire up a classic command line prompt.

$ git clone git: //
$ php -r "readfile ('');" > drush
$ composer create-project drupal-composer / drupal-project: 8.x-dev my_site_name_dir --stability dev -no-interaction

Oh, the joy!
The end of banal clicks in easily understandable checkboxes. The end of finding folders with Finder or Explorer. The end of nice colors, round corners and shadows. Now, that's a true step forward.

I'm not a machine stormer

Don't misunderstand me now.
I am not against progress.
Nor do I oppose the development of systems with new and useful features.
I also don't mind using old-fashioned methods when they are better, easier and more effective.

I often use the command line on my machine. I was weened on the command line. I'm an old man who has grown up with it. But I'm not sure that I fully understand why things have to become more complex, more incomprehensible and harder to learn and use, when technology advances in general goes toward controlling everything with a thumb on the screen of a smartphone.

A PS – parallax

I have long wanted to have a so called parallax effect on the large images embedded on some pages. The parallax effect will have a background image scroll a little slower that the foreground, creating a sense of perspective and depth on the page.
My first action when wanting to do something like that in Drupal is to look for a module, and yes, there is one. Scrollmagic. It's a sandbox module, meaning that it's in development, but can be used, although without guarantees.
So I downloaded the module.
It needs the Scrollmagic JavaScript library, which is understandable, so off to find that.
And the story starts all over.
The Scrollmagic module is four files, very common for small Drupal modules.
The JavaScript library is 260 files in 44 folders. Kerboom!
And the Scrollmagic construction the needs the Greensock Drupal module to work. "GSAP is a powerful, high-performance javascript animation library for the web".
Need to fetch that.
Another fairly compact module, but still another 10 files and two subfolders.
And GSAP needs the Greensock JS library, so I'm adding further 71 files in 10 folders – and I need Composer to install it.
And all of this goes nowhere without the Drupal Libraries module, which I already have running, but still.
So four different additions summing up to about 300 files to obtain parallax.
Not on my watch!
The thing is that parallax can be made with no additions and no JavaScript in pure CSS. So I should be able to obtain what I want by adding a few lines of HTML markup and some CSS in my stylesheet, but somewhere someone thinks it's better to pollute my site with two modules and two extra libraries comprising hundreds of files to get the same result.
Sure the force of these many lines of code will allow me to do all kinds of neat things, but you know what? I don't want to do all kinds of neat things! I just want a parallax effect on a few selected images.
I'll be working on the CSS-solution the coming time.


Log in or register to pre-fill name on comments, add videos, user pictures and more.
Read more about why you should register.

Since you got this far …

The GFF money box

… I have a small favor to ask.

Long story short

Support the Global FlyFisher through several different channels, including PayPal.

Long story longer

The Global FlyFisher has been online since the mid-90's and has been free to access for everybody since day one – and will stay free for as long as I run it.
But that doesn't mean that it's free to run.
It costs money to drive a large site like this.

See more details about what you can do to help in this blog post.