Video by Variant Studios

There's been a huge push in this community to "Design for the 80%". The idea is that you want to make Drupal really easy for 80 percent of the people who use it. This usually involves setting sensible defaults in form values, and putting things where most people would expect to find them. It means focusing on the usability problems that will affect 80% of the people who use Drupal, and ignoring (or at least setting as a lower priority) the crazy edge cases.

I want to suggest that we start engineering for the 80%, too.

What I mean by this is two fold.

1) I don't want Drupal to be engineered for edge cases.

Example: at least 80% of Drupal 7 sites will be running on MySQL, MariaDB, or comparable systems, but Drupal's new database abstraction layer (though awesome) was engineered for that other 20%. This is great for everyone who has been unable to try Drupal due to internal policies, infrastructure limitations, or other political matters. But what about Drupal's loyal followers? Is it really any better for any of us? What about the little guys - the non-profits and mom and pops who now can't run Drupal 7 because their shared hosting account can't support it?

2) I don't want Drupal to contain so many layers of abstraction that the barrier to entry becomes too high.

With every release of Drupal, we introduce a new layer of abstraction. In Drupal 6 we got a fancy new theme layer. In Drupal 7 we have a fancy new DB abstraction layer, we have the page-render drill-down, and who the heck really understands the menu system anymore?!

When I first started working with Drupal most of the code was written in plain logic. This means that anyone (programmer or not) could open a file and read it. They could see what was going on, catch bugs, and propose changes.

Today, there are a lot of smart people who have opened up a file to read it, seen a lot of stuff they didn't understand, closed it, and moved on. The more sophisticated our code gets - the more object oriented, the fancier, the more powerful, the faster - the fewer people who can read or understand it. This means our potential pool of contributors is shrinking.

Drupal didn't get to where it is today because it had the best code of any CMS - it got to where it is today because of the size, diversity, and involvement of it's awesome community (that's you!). Is improving our code worth loosing that edge? Is there any way we can continue to improve the code, without loosing potential contributors? Is there any way we can keep the code manageable for the 80% while building our layers of complexity behind the scenes?

Do you think better code is really better for Drupal?