De-Inventing The Wheel

  • Posted on: 11 June 2014
  • By: Shawn DeWolfe

For the first years of coding, I built most things from scratch. Login systems, e-commerce systems, RSS generators, content management systems-- you name it. After a while, I developed a handy little spellbook of code for use and reuse in Perl, PHP and ASP. Still, that was my spellbook. In 2000, I build Daccor, an ASP driven CMS to handle login, user management, content display and publication. I used it for a number of deployments, but eventually moved on. When I went to work for a local design company, they too had their own ASP CMS built in-house. It was decent and very functional. By the early 2000s, most developers were learning that they didn’t have to re-invent the wheel. They used, reused or found code that worked.

Fast forward a dozen years. I still get requests to make customized versions of very common elements. The must-see hits:

  • an e-commerce system where the user is anonymous beginning to end (I got them to compromise to allow for a name at the payment step).
  • an email notification system where users cannot opt out (CASL kicks in on July 1st, before then, I will either deactivate that kludge; or resign and suggest they deactivate that kludge after I leave so that they don’t get hit with a million dollar per offense charge).
  • an event system that shows every day of the event separated but still in a conjoined event (technically possible, but why do it?)
  • a hierarchical category system that uses 31,000 categories to organize 34,000 listings.
  • and, a number of ideas that will only surface during hypnotherapy.
These ideas had three big problems associated:

Off The Shelf Is Cheap

WordPress, Drupal and many other complete web applications come ready made for deployment. There are development frameworks that take care of many of the complexities of development and design. Off the shelf is massive time and cost savings. These Open Source types don’t know what they’re giving away. It’s estimated that that baseline code base for Drupal is the equivalent of $4,000,000 in development costs. When you install Drupal, you get the first $4,000,000 of the coding for free. Free is good. The modular add-ons are also either free or cheap.

Last week, I worked for many hours to deploy a licensing system. First, I tried to manhandle a WordPress plugin to do my bidding. Second, I tried to build my own. FInally, I said, “here, WooCommerce, take more of my money.” My time is money. If I plunk down $130 for an off-the-shelf solution, that’s less than two hours at my development rate. I knew this going in, but I thought I had to experiment and get to the end of the road of the DIY question.

Custom Built Is Expensive

Custom built applications can be costly. The coding is almost the minority task in a proper project. Development requires planning, specifications, resource management, testing and support. No matter how you cut it, that turns into time and money expenditures. If getting from zero to Drupal is $4,000,000 are you prepared to mimic that much complexity? If so, you’re going to need money and patience. $4M in development is also 500,000 hours of development-- 298 people years of coding1.

Why even contemplate a custom build of something readily available? Sometimes the code doesn’t suit the role. Sometimes there’s a stubbornness that comes into a project-- the short path is like RIGHT THERE but the long custom route is demanded to get some minute detail to be different. Sometimes it’s just plain ignorance: there are conventions and common ways to do things. A proponent without experience will say, “how about this way?” as they have not researched the standardized way to do something. They may vet their own approach and dig in instead of being open to the common, speedy and well accepted approach. A developer should always be able to develop code, but the proponent should always look for speedy and inexpensive ways to achieve their end goals.

Speaka Da English

The good side of repeating common concepts is that you make a visual language. When I go to a login block, I expect to see a username field, a password field, a “forgot password” link and maybe a “register” link. When you improvise, you break with convention. You leave people guessing how things work. When you hand someone an unconventional way to do a conventional thing, you throw them. They may adjust or they may say, “I don’t know how this works” and walk away. Innovation is welcome, but not stretch the attention span of users.

Coders always need to code something. Websites have upped their game. To have a full fledged website or application, you need to have a lot of functionality built-in. I say that you should not re-invent the wheel in a quest to do something different.


Last updated date

Monday, September 30, 2019 - 17:12