When I first began learning to program, I spent a tremendous amount of time navigating a massive learning curve, seriously convinced I may never accomplish anything significant. One day, I reached a tipping point in my programming knowledge and had an epiphany: I can do anything! A social network, an e-learning academy, a music player, a Web chat app. Anything! This isn’t to say that I knew everything at this point, but I remained optimistic. With my knowledge combined with my chosen set of Web development tools, I realized I was capable of solving just about any problem imaginable.
It's a very empowering feeling, and this very feeling is what pulls many Web developers out of bed in the morning. Whatever problems or puzzles come my way today, I can solve them. I can build it. Now in the world of professional Web development, where deadlines and budgets are the law of the land, the most important question is not, “can I build it?” but rather “should I?”
This question is especially pertinent when building basic components, such as carousel or image slideshow. These are now practically a cliché, meaning someone has already anticipated this need by building a slideshow and publishing it for reuse. Buttons, dropdowns, pop-ups, tooltips, video players … are countless versions of each Internet tropes promising to save time and are just waiting to be “plugged in” to your project.
Elated at the time you’ll save, you download (or as we prefer, “ bower install”) the slideshow plugin and begin to add your content and special touches to it. Often, it’s not long before you start to run into limitations. What if you want your slideshow to scroll up and down, instead of left and right? What if you want it to have control buttons? What if you want it to have videos instead of images? Maybe the creator of this slideshow built in a feature for that ormaybe felt it wasn’t important. Do you try to reach out to the plugin’s original developer for help? Do you search the Internet for other people using the same plugin and ask for their help? Do you dare dig into someone else’s code and start trying to add your own features? In the meantime, that persistent voice inside your head has grown louder: “I can build it. I can do anything.”
Dismayed at all the time you wasted, you scrap the plugin and begin creating your own slideshow. It’ll be the slideshow of your dreams, and do everything you want it to do, exactly the way you want it to do them. But it’s not long before you start to run into complications. What if a user with a phone wants to swipe to navigate? What about that undocumented bug in Internet Explorer you’re not sure how to handle? What about mobile responsive design? Your dream of building something new has transformed into dread as the deadline nears and you’re pouring hours of time into what could have been a simple slideshow.
This Web development horror story seems to happen time and time again. The urge to do it yourself is so tempting, but also risky when projects and deadlines are at stake. When should you jump in and DIY? When should you just borrow somebody else’s great work? Knowing exactly when to build and when to borrow takes a lot of experience, intuition and expertise. Here are a few tips used at our integrated branding agency to help guide your decision-making process:
First, swallow your pride. It’s easy to think you could solve a problem better than somebody else. Given enough time, you probably could. In reality, someone has already solved this problem. Stop comparing your programming “chops” to theirs, and ask yourself, “is this good enough to use?” If the online plugin solves your problem with a minimum of compromise, then it’s probably worth considering. Efficiency is essential for clients and it’s best to avoid re-inventing the wheel if at all possible.
Second, pick better plugins. If you have any programming knowledge at all, try to find plugins that let you add your own code to the mix, instead of plugins that try to provide some clever “zero-code” solution. A better word for these tools would probably be “libraries” or “frameworks." You really want a tool that lets you write a custom code, while solving all of the tedious and time-consuming problems for you. Unfortunately, finding plugins with these qualities is somewhat of an acquired skill, as you’ll need to download and play with quite a few of them until you find one that really works.
Third, avoid plugin plague. Plugin plague happens when you have multiple plugins doing different things on a website. This plague makes your site susceptible to become brittle and difficult to change without each new plugin negatively affecting one another. Poorly-written plugins can quickly cause plugin plague. These plugins dictate behavior and user interface and provide very little room for customization. It’s only a matter of time before two of these plugins clash and your site suffers. At our integrated agency it’s best practice to be on the lookout for plugins that overstep their bounds or poses a threat to something another plugin is trying to do. Good plugins solve small, individual problems and don’t bother anyone else while they’re doing so.
70kft Integrated Marketing Agency understands that plugins can be tempting at first, because they seem to quickly solve your problems with almost zero effort on your part. In practice, many plugins create "technical debt" that's more costly to fix after the fact than it would have been to build an original solution to begin with.
See this link for technical debt: http://blog.codinghorror.com/paying-down-your-technical-debt/
Finally, be part of the solution. If you’re a developer who’s tired of wading through poorly-made plugins, then let that little voice inside your head (you know, the one telling you “I can build it”) finally take over, and build something! Contributing to existing projects is a great way to share your awesome ideas with the world and avoid having to start from scratch.
Most Web plugins or tools that are even remotely popular are on GitHub, where it’s trivially easy to create your own copy of a project, change what you think should be changed, and then ask the owner of the project to consider your changes. You could also build your own plugin to solve a problem, which is especially helpful if this niche hasn’t been filled just yet.
A formal content management system (CMS) training is best practice at our agency and is always part of our handoff process when we deliver a website to a client. It's critical to document this handoff process. As an example, when 70kft was preparing to hand off an especially complicated CMS to one of our clients, we realized that the best place for CMS documentation is in the CMS itself! We immediately built the Craft Help plugin and have used it for every CMS handoff since. Craft Help: https://github.com/70kft/craft-help
70kft is constantly solving tricky problems for our clients, and sometimes we find that many of our clients (and lots of folks who aren’t our clients yet) have similar problems that could all benefit from an elegant, 70kft-crafted solution. Whenever we get the chance, we publish our plugins on our GitHub page so that anyone in the world can use or borrow our ideas, and hopefully add some ideas of their own!