Dev Investment Now, More Features and Speed Later

Over the lifespan of a web-based product, each new feature that gets added will increase the complexity under the hood. This means that working on it and making future updates will most likely become progressively more difficult over time. It’s not uncommon, even in large companies, for this difficulty to eventually become so significant that further development grinds to a halt; this is what developers call technical debt. The good news is that the risk of this happening can be mitigated; it just requires that developers be given the time to set up the proper tools and automation to ensure your web product will scale gracefully.

There are a lot of productivity-boosting tools out there to help your dev team, but to give you a sense of the kinds of purposes they serve and the efficiencies that can be gained, I’ll provide a high-level overview of two of the biggies:

CSS Pre-Processors (Front-End Developers)

A fundamental goal for developers is to make code more re-usable and DRY (don’t repeat yourself). DRY is a coding principle that basically says “if you need to copy and paste some code to do the same thing in more than one place, you should instead create a single function (which acts as a shortcut) and use that function any time that you need that code.” Enter the pre-processor.

Pre-processors can accept variables for things like color, for example, so if your company has a specific blue that it uses for all links, it can be saved as a variable (like a function, this acts as a “shortcut”) — reducing the likelihood of someone say, using the eyedropper tool in Photoshop to try to guess the color of the logo, getting it wrong, and then adding a new (and incorrectly deviated) color to the CSS files of your product. Other examples are functions that lighten or darken colors, helpful because colors can be derivative of a single color. So, those blue links that turn dark blue on hover? If I use a pre-processor to make them darker, and the business team later changes them all to green, all I have to do is change the code once and all other instances (sometimes in hundreds of locations, with a wide array of slightly deviated colors) will be updated automatically. Sounds like a no-brainer, right? You’d be shocked how often hundreds of identical changes are still made manually.

Code Validation & Testing (Front-End & Back-End Developers)

Sometimes referred to as linting, the benefit of this process is that routine/mundane (but crucial) checks that should be done with code can be automated through tools like Grunt, JSHint, Grunt-JSHint , CSS Linting, and many more. These tools will do the boring but critical tasks like checking for missing commas, verifying the correct number of parentheses/brackets, and plenty of others. With Grunt in particular, a “watch task” can be created so that every time code is saved, this check happens automatically. While we do our best not to make mistakes, we’re human after all—but since these are objective tasks that can be done with 100% accuracy by machines, it’s in our best interest to let them have at it.

The Big Leagues

I used two “front-end” automation and workflow enhancement examples previously because it’s typically a bit easier for non-programmers to relate to (link colors are easier to think about than the dichotomy between strong or loosely typed variables). But larger projects often can (and should) require even more automation, courtesy of technologies like Jenkins and Travis, that can test not only CSS and JavaScript, but all programming languages from Ruby to Python to Haskell and beyond. This deeper level of testing is sometimes called unit testing. Every time a developer pushes code to Github, Jenkins or Travis can test it to make sure it has no errors and then report back by adding a comment after the developer’s code to say whether it’s “passed” (thumb’s up) or “failed” (no dice, try again). This prevents fire-drills where bad code gets released to production and developers go into panic mode trying to fix something that could have been prevented with proper unit tests.

The Bottom Line

If your developers don’t already know about these tools, it’s a good idea to make the investment in providing them with the time to get familiar. These tools will not only increase their productivity, but instill a greater sense of confidence in managers as well as the product itself because they take large amounts of cognitive overhead and stress off of the development team.  If your team has process-improvement-minded developers then they will be more than happy to be allocated time to experiment with and learn whichever tools are the best fit for the product they are maintaining. Now that we have these tools at our disposal, bolting awake in the middle of the night thinking “Oh no, did I forget to do step number 483 when I pushed the latest release?!” is less likely than ever before. But I’ll repeat the core message here: development teams are usually being pushed to create new features (and in doing so, increasing cognitive overhead and technical debt) because those features are assigned a higher priority than the “grooming” of a product which ensures that it will remain lean, fast, and efficient as it grows. Don’t make that mistake.

There’s a lot more that could be said on this topic, and I’m happy to spar in the comments or post again on a specific nuance if anyone is interested—but this is meant as an introduction to a principle and an idea, rather than a comprehensive list of all the things you could do to make your team faster (which would be very long, conceptually dense, and subjective). Looking forward to the continuing conversation!