cool tech graphics

Websites Don't Use Carburetors Anymore

It used to be that cars were simple. If your car broke down, a guy could pop the hood, check a few wires, hit things with a hammer and actually get things to go again. Modern car engines have come a long way, and now are a complex system of 500+ components. Gone are the days of carburetors. Now we have fuel injectors.

Modern websites are essentially the same. It used to be, if you needed to change something on a website, you'd FTP in, find the file you were looking for and make the change. All it took to be a web expert back in the day, was a working knowledge of HTML and some computer skills. These days these simple websites have been replaced by content management systems and frameworks. Troubleshooting, repairing and boosting performance on these systems is not simple, and that's lead to the rise of cartoons like this:

learning curve of a CMS


This illustration is simultaneously funny and true... and irrelevant. If the primary mission of your website is to make sure that the CEO can "get into the code and fix things", you're company is probably on the wrong path. Conversely, if you are paying professional to build, host and maintain your website, who cares what it's built in?

When it comes to your website what really matters is:

  1. Are you locked into a single vendor?
  2. What kind of licensing fees do you have to pay?
  3. Are you on a platform that continues to bring value?

Ultimately, I don't need a car with a carburetor, because for better or worse I rely on other people to make it go for me. The same should be true of your website.

Date posted: March 14, 2011


I agree, Drupal is succeeding at providing a sound foundation for website development by professionals. If doing that means it is hard to use for people who either lack the developer skills or are unwilling to invest the time to learn then I think that is okay. A system that is to work with for a non-technical or semi-skilled person is unlikely to meet the demands of top of class commercial web sites. What we should do though, is make sure the documentation is not only complete but also well refined and that additional support is organized in a manner consistent with the needs of learners. There might also be room for additional documentation standards for contributed modules. Ever installed a new module in 10 seconds and then spent 10 minutes trying to find out where it is? Ever had to look at the hook_menu() function to see which admin pages are created because there is no mention of this in any documentation? When you have to read code just to find out basic things about how a module works, I think maybe there should be a standard that says that module is not accepted until it provides that information, or it gets listed as a "non-documented, developers-only" module.

I completely disagree with the above comment. It is completely not-ok to accept unnecessary complexity, and the complexity in Drupal is working in the Drupal ecosystem is not necessary in my opinion. People complain ocPortal is hard to use all the time and we take that as a signal to make it easier, we don't just bury our head and say "well, only pros should get powerful tools". The primary mission of the last 4 major ocPortal releases has been in improving ease of use, but we define it as ease of use for people to create the complex stuff they want to create. If things match a pattern then you can make that pattern relatively easy by implementing the UI/lexicon in the terms that people already understand ("nodes" aargh). Users have these complex ideas in their head, the software just needs to talk their language, and 80% of what most people are trying to do is really common anyway.
We've loads more work to do in ocPortal:
- we need to get to the point where people can just do a few clicks to install a choice of theme for a gallery, set to their own colour scheme
- we need to make theme editing as easy as it was to change layouts in Microsoft Frontpage back in the day
- we need to make it so you can modify all your content in your favourite tools (e.g. articles in word, databases as CSVs in excel) just by browsing the website from Windows explorer (Webdav...)
As web development standards raise I think it is absolutely crucial to make things easier. Could we write web sites in assembly language? I don't think so, it is increased usability of programming tools and languages that has made it viable to make complex software.
This said, people do need to either set some reasonable limits on either not being able to implement things that do 100% of what they want the way they want it, or have budgets that can pay the salaries of good experienced programmers (all too often we see people wanting really complex custom websites done by a proper agency for a weeks wages for one member of staff).

I'd say the first few days looking at Drupal is even more challenging that the occasional disappearing module (although I've totally been there!). I'm really excited about the #snowman initiative headed by @eaton to get a Drupal install profile that actually does something right out of the box. I think making the core experience better is absolutely within our grasp - though cataloging and documenting the entire ecosystem of modules may be too big a task.

I've spent 5+ years developing and supporting a custom built CMS in a corporate environment for a team of 3-6 content writers and many thousands of readers.

This may seem like overkill but the payoff was the huge increate in productivity, consistency and quality for the writers. It was a relatively rigid system, but its what the writers wanted, and needed, to get the job done.

There were numerous occasions where I had a choice:

1) to do it the easy way programmatically and make things easy for myself but not so intuitive for the writers

or 2) make it easy for the writers but a pain-in-the-neck for myself to implement.

On almost all occasions, the writers won because that's where the greatest productivity gains were.

You don't want to alienate your user base by making the CMS difficult or frustrating to use. It needs to be largely intuitive, as simple as possible, and only introduce complexity/difficulty where it is really warranted.

Just how much time do you expect users to "invest" in learning a product just to do the basics?

And even just deciding on what CMS product to choose, are you expecting users to read every products manual just so that they can decide?

It's also worth noting that Drupal is difficult for developers, but if setup properly can be very intuitive for an administrative user. It's actually the most flexible CMS (in terms of workflow) that I've ever worked with. I'm all about getting administrators to fall in love with their CMS.

5+ years is a lot of time (and money) for a company to invest in building a CMS. I'm not going to question the overall integrity and extensibility of the CMS you built, but if we assume a salary of even a humble $50k annually, that's an investment of $250k+ and more importantly 5 years for something that you could probably get these days in a few months at a quarter of the price. 5 years ago when you started this, it may have been the best approach, but if you haven't reevaluated your approach since the start, you're really missing a tremendous opportunity. Communities will always outlast and outperform individuals. Not to mention, what happens to your employer if you quit? Will they see the return on 5 years of investment or will they be crippled because they are unable to find a developer who wants to take on another developers homegrown code?

If you disagree with this post, you'll probably also disagree with my top 5 reasons to choose Drupal as your CMS and also the declaration that the framework is dead. It's up to us as service providers to do investigation and make better choices about where we spend other people's money. Hopping on the Drupal/CMS bandwagon may be tough at first, but it's well worth it in the end.

The project was started in the early 90's when CMS prices were really scary. The ROI was definitely there, but that is not the focus here.

You have completely ignored the main thrust of my post which is the need to make the CMS, or any software, as simple and intuitive to use as possible. Keep the focus on the user, reduce their frustration, keep them productive and lower the entry barrier for new users.

While your "top 5 reasons to choose Drupal as your CMS" are indeed good reasons, the notable lack of any user focus (admins are not your largest user base), I think speaks volumes.

The requirements of general site users is almost always top priority. I've almost never run into any issues with front-end experience with Drupal - you just have to have the experience. What almost always is forgotten in how users manage data in the system, people always try to cut corners here.

Simple and intuitive is great if you have the time and money to commit to perfection. However, even if you have the money is it really worth the hundreds of thousands of dollars and years of time to reinvent what's already available?

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Metal Toad is an Advanced AWS Consulting Partner. Learn more about our AWS Managed Services

About the Author

Joaquin Lippincott, CEO

Joaquin is a 20+ year technology veteran helping to lead businesses in the move to the Cloud. He frequently speaks on panels about the future of tech ranging from IoT and Machine Learning to the latest innovation in the entertainment industry.  He has helped to modernize software for industry leaders like Sony, Daimler, Intel, the Golden Globes, Siemens Wind Power, ABC, NBC, DC Comics, Warner Brothers & the Linux Foundation.

As the CEO and Founder of Metal Toad, an AWS Advanced Consulting Partner, his primary job is to "get the right people in the room".  This one responsibility is cross-functional and includes both external business development functions as well as internal delegation and leadership development.

A UCLA alumni, he also serves in the community as a Board Member for the Los Angeles Area Chamber of Commerce, the Beverly Hills Chamber of Commerce, and Stand for Children Oregon - a public education political advocacy group. As an outspoken advocate for entry-level job creation in tech he helped found the non-profit, P4TH, an organization dedicated to increasing the number of entry-level jobs in the tech industry, and is in the process of organizing an Advisory Board for the Bixel Exchange, a Los Angeles non-profit that provides almost 200 tech internships every year.


Have questions?