Using an Existing System vs Creating One from Scratch

Published by Kathleen Woo,

The question has come up debating if one should use an existing content management system (like Drupal) or widget (like Prototype Window), or create their own custom system from scratch.

First of all, you need to evaluate your website’s feature requests, and your development team. The variables to consider are:

  • Quantity of features
  • Complexity of features
  • Size of development team
  • Diversity and experience of development team

In general, the higher quantity and complexity of features will demand a greater size and diversity in your development team. Although one or two developers could conceivably create a feature rich website, the time it would take to do it would be prohibitive. If your given resources would mean development would be longer than a year and a half, then don’t bother trying. Technology moves too fast and it would be obsolete once it went live. Either that, or you would spend too much valuable time updating the system to new methods and continue to slow down development.

The difference between an existing system and creating a custom system is the rate at which a given set of features demands a growth in the development team. An existing system would enable a smaller development team to add a larger quantity of features in a more timely manner than if that same small team attempted to create each feature from scratch.

But, an existing system has limits. Only so many features can be crammed in before the code becomes, frankly, ass backwards because it simply was not developed with such needs in mind. Additionally, only so many developers can easily work in a distributed development environment within the constraints of the existing system (this especially applies to content management systems).

Why are existing systems great for small development teams?

It’s like having a larger team. You gain all the benefits of having a large, diverse and experienced development team even when you’re working alone.

Whether it’s open source or proprietary, there are people dedicated to solving specific problems. Security gurus are scouring for holes. Javascript ninjas are creating cool stuff. Database wizards are focusing on the optimal schema. Performance experts are tweaking and optimizing the speed. Testers are finding bugs while developers are fixing them and adding new features. Usability experts and graphic designers are… Ok, usability and design is lacking, so thats your team’s job!

While your team is working, sleeping and living their life, there are other people working in the background. Either you can take advantage of someone else’s work that was done before you started, or you can take advantage of that bug fix that was discovered and patched while you were working on something else. These are all the same advantages that larger development teams have when working together.

Unless you have several geniuses in your small development team, you will have holes of expertise. There will be something that none of you know well enough and it will ultimately make your project suffer for it. The smaller your team, the larger the potential holes.

Whats worse? You may not even realize it. You could deploy your site and never realize you left yourself open to a injection attack, or it slows to a crawl due to an unnoticed performance or scaling issue. Taking advantage of an existing system will also take advantage of their experience and help reduce potential problems due to your team’s expertise gap.

Why are existing systems bad for a large development team?

It’s like having a larger team. Yup, for the same reason why it’s great for small teams is why it’s horrible for large teams. Imagine your current (presumably large) development team and multiply them by 10. All of those voices and hands in the code would make it extremely difficult to get anything done efficiently. Communication would hit rock bottom, progress would slow to a crawl and the number of bugs would hit astronomical levels.

Presumably, the size of your team was created because of the vast quantity and complexity of features that are needed. Since your project is already overloaded with features, you do not have the space to be dealing with extra features that an existing system would have in order to accommodate a larger audience. More features equals more potential bugs, so you don’t want to include any more features than you absolutely need.

You have very specific (albeit a large quantity of) needs and you need to be focusing on those features. Besides, you have the team that can handle it! Why install a widget with 10 features when you only need one or two. Why install that same widget when you still have to hack it in order for it to work to your specifications? The assumed “time saving" of installing a 3rd party widget would be lost by the bugs created when integrating it into your feature rich application.

I mentioned it earlier, but I’ll mention it again: Existing content management systems especially will have difficulty in scaling a distributed development environment to a large team. Many existing systems are designed for a general audience and have general needs. The general audience doesn’t have a large development team! Drupal, for example, stores the vast amount of it’s configuration settings in the database, making distributed development amungst a larger team quite difficult.

So what should you do?

Small teams should seriously consider using existing systems, while large teams should start from scratch. If you’re in that in between state where you have a medium sized team and need to figure out how to proceed, here’s a method to figure out which way to go:

  • What is your time span? Your maximum time span should fit within one year (so you have another 6 months of “oops" before you hit the dreaded year and a half mark)
  • Gather as much information as possible for feature specifications
  • Create an estimate of how much time it would take to develop from scratch
  • Research on the different existing systems out there that also meet your needs, and decide which ones would be best
  • Create an estimate of how much time it would take to develop using the existing system(s)

Once you’ve gathered that information, you can then weigh the pros and cons of each method. In addition to evaluating time, also consider your team’s expertise, learning curves, development team growth, potential feature creep, version control, development environment, etc.

What if you’re a small team with a small amount of features? In general, you should not use an existing system if it provides more features than you would possibly use. More features equals more bugs and more maintenance. You do not want to spend the time on supporting too many useless features.

For example, I had originally developed the Public Display website in Drupal envisioning that it would make it easier for people in the company to change the text as needed. However, it turned out to be too many features than was worth maintaining. Version control was awkward because of the database, and the team balked at the idea of being restricted to an input form that was confined to effecting a small section of the page when making modifications.

Ultimately, I redid the Public Display website as just static . The site is small and so it’s still easy to maintain with static, and everyone working with it has an expertise with to tweak it as they need. Reducing the amount of features and simply creating the site from scratch was good in this case.

Choosing your development path is not a simple answer, but this discussion may help guide which way your team should go.