Update: Corrected some minor errors based on feedback from chx and Tim Plunkett. Thanks!

I saw that Jen Lampton wrote a post discussing about the Backdrop CMS over at Introducing Backdrop CMS, a Drupal fork. Jen is someone I respect for the work she's done in Drupal, and given her involvement with the Backdrop fork, I was very interested to read her take on the issue. While I think Jen has made some very good points made in her article concerning how the two projects can work together and be mutually-supporting, I felt a need to disagree on one point.

Drupal isn't intuitive

In her post, Jen makes some remarks that seem to position the old procedural Drupal 7 and new Object-Oriented Drupal 8 architectures along the lines of 'hackable / intuitive' vs. 'academic / software architects only / non-intuitive':

'We realized that somehow in Drupal 7's development, we'd crossed a threshold. Drupal had suddenly become too hard to learn. I experienced this pain first hand as the Director of Training at Chapter Three, I trained hundreds of people on building sites with Drupal, building Drupal themes, and building Drupal modules. I realized that the problem was not lack of documentation (or even a lack of good documentation) the problem was that Drupal was not intuitive enough. I love Drupal, and I want it to succeed, so I devoted myself to making Drupal easier to learn ("learnability") and easier to use ("usability").'

'At the start of Drupal 8 development, a decision was made. Drupal would shift all its concepts and design patterns towards professional computer-engineers, and in doing so attract a "higher tier of developer".'

Jen is correct that Drupal 7 was not intuitive enough for a programmer new to Drupal. However, while Drupal 8 is a difficult platform currently, it will be far more intuitive that Drupal 7 ever was once it has reached its final polished state.

Drupal 8 solves existing issues by building on established principles

Object Oriented Programming and the various design patterns used in Drupal 8 are not 'professional computer-engineers'-only concepts dreamed up by blue sky academics and tested out in Drupal 8. These are tried-and-tested programming practices that have all been around for decades already, and are used extensively in millions of projects around the world with great success.

I think the issues that prompted this change in architecture have been well-documented, though perhaps poorly communicated. To summarize, the problem is that Drupal has been holding on to an architecture that, while viable for earlier (smaller) versions of Drupal and still viable in general for smaller projects, has long been outgrown by later Drupal releases. Maintenance doesn't scale linearly with the codebase size under the current architecture. The current mess of procedural 'spaghetti code' makes it more difficult for Drupal to react to changing needs and usage trends the modern internet. Finally, it has led to an increasingly large number of Drupal WTFs as creative solutions have been invented to solve difficult problems within the constraints of the legacy architecture. This has been an ongoing problem for years now.

Since PHP 5.3.0 was released in 2009, the option has been there (via better OOP support in PHP) to finally modernize Drupal into a much more modular, flexible, and maintainable codebase that uses established and common design patterns rather than its own Drupalisms.

The move to the new OO architecture is simply moving Drupal 8 into line with common, modern (decades-old) programming practices what will scale with Drupal as it grows into the future, and leaving behind a massive, bloated architecture that is no longer suitable for it.

Adding Symfony components into the mix was primarily a shortcut; by using stable, well-tested libraries that meshed with the community needs, we have cut down on the amount of Drupal-specific code in core while helping to achieve the goals for D8.

But where does that leave the community?

The controversy surrounding Drupal's re-architecture and the impetus behind its recent form lays to a degree in the fact that Drupal has held on to its procedural architecture for so long. Drupal has grown an exceptionally dedicated community of developers of whom a non-trivial segment do not have much experience with platforms outside of Drupal. These developers have not had reason to use OOP and many design patterns despite their wide popularity in other platforms and CMSs. This is the segment of users we stand to lose with the architecture shift in Drupal 8.

"Drupal mud" slide representing interwoven procedural code of Drupal 7, from Larry 'Crell' Garfield's DrupalCon San Francisco presentation in 2010.

At this point, the question becomes 'Do we refuse to modernize Drupal and deal with ever-increasing issues created by the legacy architecture to protect a segment of the community that doesn't wish to or can't invest the time to learn modern (decades-old) programming practices?'

It also begs the question - provided that Drupal will have to do this some day, when would it be an appropriate time? Next year? Perhaps the year after?

These are tough questions to answer. Nobody wants to give up on a segment on the Drupal community who can't or won't step up to learn an OO flavour of Drupal. But I do believe these changes will be necessary to allow Drupal to remain a competitive and attractive CMS option going forward.

In my mind, the best time to modernize Drupal would have been in 2009, early in the Drupal 7 development cycle. At this time, PHP 5.3.0 was released with its much improved OOP support, and our community was smaller. We would have had these same difficult questions, but the stakes would have been much lower.

Drupal 8 is hard... in Alpha3

I am not blind to the fact the current Drupal 8 alpha-3 DX is difficult to grasp. I haven't coded or thought about OO programming in almost a decade since university, and I have been very skeptical about the changes in D8.

While I was somewhat active in core during the D6 and D7 development cycles, I've only recently gotten active in Drupal 8. About two weeks ago, I decided to help out on some smaller patches as part of beginning to learn about the new platform, and I've encountered many places where the new processes appeared to be... inexplicable. I've only come to really grasp how all the new parts of Drupal 8 work together after asking many questions on IRC and getting very patient answers.

There are a lot of awesome changes coming with Drupal 8 that are going to make the DX much, much better. Some of my favourites:

1. The new plugin architecture. For example, Blocks are now a plugin type. A new block is contained in a single file as part of its own class.
2. Dependency injection will offer a huge amount of flexibility in what can be done in contrib!
3. Better Multilingual / Internationalization support (and there was much rejoicing!)
4. New routing system needs some DX improvement, but Access Checks as services and better handling of non-HTML content thanks to the Web Services Initiative is going to be a major win.
5. The CMI changes allowing config to be stored in files subject to version control is going to make every Drupal shop's life easier.

While these features (and more) are already mostly implemented in core, they aren't yet well documented. There are still rough patches in the implementation which make them hard to use from a DX perspective.

I think everyone agrees that the biggest challenge with Drupal 8 is to improve the current DX situation via better documentation and cleaning up some remaining architectural rough patches to make it much easier than it currently is for the existing community to transition to Drupal 8.

If you want to be part of the solution, the best way to start is to visit the D8DX handbook page: http://drupal.org/node/2081777

Back to talking about being intuitive

To bring this all full circle, I agree with Jen Lampton that Drupal 7 was not intuitive. It was a mess of Drupal-specific code organized in Drupal-specific patterns chock full of Drupal-specific oddities.

Drupal 8, on the other hand, is going to have a much more standardized architecture built upon commonly used architectural patterns. It's going to play nicely with other projects and components that use the standard PSR-0 namespacing conventions. The new dependency injection code will allow you to replace entire subsystems in Drupal with your own or somebody else's alternatives if they don't suit you.

In short, provided that it is properly documented and the remaining implementation issues are dealt with prior to launch, I think Drupal 8 has the potential to be the most intuitive version of Drupal yet.

Drupal 8 is going to be awesome!

After spending most of the development cycle of D8 so far alternating from being wary of it to being downright concerned, I am now fully on board with it. While Drupal 7 has been a solid building platform to accomplish both personal and client projects, the benefits Drupal 8 will bring to the table will push our capabilities to the next level.