Code Reuse and the Shrinking Developer Timeline

Table of Contents

    Subscribe for Email Updates

    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.

    Why Timelines Shrink

    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:

    • Responsive CSS - code that takes one html source and alters the layout for the best experience on devices of varying sizes (usually desktop, tablet, and phone).
    • Hi-res, low bandwidth video - mostly used on home pages, this creates a more engaging experience
    • Animated content - content that animates into existence while the user scrolls. This can be fly-ins, fade-ins, counters, and other fancy animations
    • Parallax effect - overlaying background images with content that scrolls faster than the background, creating a sense of depth
    • Social media - integrating with social media sites
    • Page speed - bundling and minifying code, lazy loading, image compression, etc
    • Single Page Sites - sites that have no (or very few) separate pages. These may be long scrolling sites or partially loaded sites
    • SEO - modifications to improve SEO for specific search terms

    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:

    1. Your sales team is up against a large range of varied pricing. From the extraordinarily overpriced custom site to the underpriced template site. Finding the sweet spot for each prospect isn’t easy. An average salesperson will often lower the price in fear of losing the deal. With that price cut comes reductions in dev time.
    2. Many agencies are starting from a template, rather than a fully custom design. The process is different and most of the underlying site structure has already been completed. Estimating scope is harder if the final template selection hasn’t been made.
    3. Communication between sales and the dev team isn’t always open. When there’s no pushback, sales will continue to lower the bar. 
    4. Project managers aren’t reporting on a project’s financial results, like budgeted vs actual hours. Without this insight into projects there’s no accountability to anyone.
    5. Cost overages often fall on developers even when it’s not deserved. Once the budget is set it’s up to developers to figure out how to not exceed it.
    6. It is generally understood that when someone does the same thing over and over, they should become more efficient.

    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.

    Finding Efficiencies

    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.

    CSS Frameworks

    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.

    Javascript Libraries

    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:

    • Use minified versions 
    • You may not need jQuery
    • Do not add libraries to your site header unless you use it on every page. Restrict to only necessary pages
    • Make sure JS libraries are reasonably sized. jQuery is a little over 80Kb. Slick slider is just over 40Kb. Those are pretty large libraries, in my opinion.
    • If you can compile a smaller version of a library with only the features you need, then do it.
    • Don’t write your own if there are many to choose from

    Template Sites

    Template sites come in all sorts of flavors. You can visit (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.

    Partial Templates

    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: 

    • image galleries
    • content cards for blog posts, calendar entries, etc
    • custom navigation and paging 
    • calendars
    • tabs and accordions
    • headers & footers
    • RSS feed
    • search page

    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.

    Package Managers

    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 Considerations

    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:

    • Framework, template setup
    • Primary CSS/styling
    • Individual section/page implementation
    • QA
    • Page speed enhancements

    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.

    Check out the Marketpath CMS Package Manager

    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.

    Learn about Package Manager

    Related Tags:

    About the Author

    Matt Zentz

    Matt Zentz launched Marketpath from a small Broad Ripple bungalow in February 2001 with a focus on custom web application development. He built the first, basic version of a hosted CMS called Webtools and shortly afterward expanded his team and created the first version of Marketpath CMS.

    Matt has worked for a national consulting firm, taught computer programming to high school juniors and seniors , and led the information technology arm of the auxiliary business units at Indiana University.

    Matt graduated from Indiana University in 1999 with a B.S. in Computer Science and has built custom web applications since 1995. Matt is husband to an amazing & supportive wife, has three beautiful children, supreme master to Archimedes (Archie) the dog, and mostly tolerant victim of 2 flying rats (cockateils).

    He coaches various kid sports, enjoys furniture and home renovation projects, and plays guitar and piano. Matt is also active with his church as a parishioner, technical advisor and board member on the festival committee.

    Subscribe for Email Updates