When you finally receive the order to build a new client website, you know what you’re building and how long it will take. You’ve done it countless times before. Yet why do the allocated hours keep shrinking?
This blog post discusses the art and science of code reuse and how you can continually achieve new development efficiencies.
The standard client website has become more and more complex over the last decade. Here’s a list of improvements all new sites should have:
I’m sure I’ve missed some improvements. The point is that sites are more complex than ever, yet developers are expected to build them in less time. There are a few reasons for this:
I’m not saying that any of these are fair or even that you’ll find all of them in your agency. But I’d bet money you see at least a couple and experience some of the demands for faster implementations.
You might be grumbling under your breath right now and that’s ok. There are changes to the way you and your team work together that can help with the lower time expectations. But you can’t get away from it completely and, as a competent developer, you should always be finding ways to improve your development efficiencies.
Let’s jump into several ways to achieve results faster.
For me, this is the biggest efficiency gain. That may be because I’m slow and hacky with my CSS. But it’s also because there are so many small details to make a site truly responsive.
CSS frameworks, like Zurb Foundation or Bootstrap, handle all the responsive details for you, including browser inconsistencies. Without a framework you’ll spend way too much time tweaking site structure.
One of the greatest achievements of Foundation and Bootstrap is the use of the small, medium, and large column layouts. Small, medium, and large designate the screen widths of a general phone, tablet, and desktop browser. Both are based on a 12 column width, so if you want your content area on a desktop to be one-third of the width you simply add the class large-4 to your cell.
If you’re not using a CSS framework you’ll have a hard time keeping your dev time low.
Image galleries, HTML5 video controllers, content animation, calendars, maps, and more are all standard content found on websites. There is rarely a case to build your own.
Keep these in mind when using javascript libraries:
Template sites come in all sorts of flavors. You can visit themeforest.net (envato market) and pick a perfect template with all the bells and whistles. Or you can start from a bare bones template you know well and can expand for most designs.
My preference is to start with a bare bones template that includes a CSS framework, various pre-built page layouts, critical Javascript libraries, and reusable modules that mesh well with the entire site. Sites from themeforest often carry additional bloat and learning requirements as you familiarize yourself with the original developer’s style.
Reusing your own code, however, can also lead to dev isolation where you don’t experience emerging ways to build sites. As you already know, you have to keep up with user experience trends, browser changes, and SEO requirements.
Still, I prefer a bare bones starter site that provides the underlying fabric to build 80% of the custom designs thrown at you. Familiarity breeds efficiencies.
When you use a bare bones template site that contains your CSS framework of choice, you can quickly and easily leverage partial templates you built for other sites. Partial templates are pre-built modules that include the HTML template, Javascript, and CSS, such as:
Depending on the CMS you use, these partials can be mixed into a site using a simple import tool. Only pull in the modules you need to maintain an optimal page speed.
You’ll want to create and maintain some sort of package update capability for the modules you build and use.
For your own modules, you’ll make updates as you iterate and then push those out to your sites. For code that others have provided, you’ll pull down updates and apply them.
WordPress makes this possible through plugin updates. Just be sure your plugin won’t break a site when you update it. Managing many WordPress sites and their associated updates can be challenging. We recommend using a solution like Infinite WP to perform mass updates.
Plugins aren’t exactly straightforward to build and implement in WordPress, however. There’s a lot of fat to work around. Another option is to use Composer and Packagist to manage your components. Composer is a PHP dependency manager and Packagist is the PHP repository.
If you use Marketpath CMS, you can take advantage of the Package Manager. It allows you to update all your sites from a single login. You don’t need a bunch of separate logins for each client site. When you update a package that you maintain you can set individual sites to automatically update when a new version is available. You don’t want automatic updates for all packages but some could benefit, especially if there are significant browser updates.
Other package managers are also available, depending on your dev environment. NPM if you’re using node.js. Nuget if you’re building in .Net. Pip for Python. And all the old tried and true Linux repositories. The challenge with these is that they are single site dependent and built into a specific dev environment. They don’t allow you to update a large number of managed sites at once.
Page speed is one of those areas, similar to achieving high availability, where you can get lost and spend more time than is budgeted or economical. As you make a site faster the cost can become an exponential hockey stick. Don’t let yourself get lost in page speed purgatory.
Yes, Google search results and the site’s bounce rate will reflect a slowly loaded site. But be careful not to spend another 10 hours trying to drop the page speed from 1.8 to 1.5 seconds. Unless it’s budgeted, that is.
If you’re using a package manager to update your partial code, you can add iterative improvements over time to all of your sites. The benefits of a little improvement here and there can add up more quickly than you’d expect.
Final Thoughts
If you find yourself taking longer than the budgeted time for a project then you may need to have a heart to heart discussion with your team. What factors are leading to this? Is it the sales team underpricing work? Is it a poorly managed project that allows scope creep?
Is the problem your development setup? Are you over-engineering sites? Are you spending too much time in specific areas? Are you reinventing the wheel every time and not reusing code?
If you don’t itemize your time, you may consider doing that for several projects. Once you’re in the habit it’s not that hard to keep it up and the results may surprise you. Break out your time into the following categories:
Or you can break it out based on your own development process. The bottom line is breaking out your time in a way that makes sense. Then, over the course of several projects you can start to evaluate it for trends.
Best of luck gaining development efficiencies. And just remember, it’s not always your fault. Sometimes, but not always.
Marketpath CMS has a Package Manager that helps you maintain reusable code across all your active sites. And the best part is there are no fees to use it.
