It’s weird to call a process a perk, but our focus on reusable code is one of my favorite things about working at Table XI. Limiting ourselves to the absolute fewest number of components to build software is a challenge, and it’s one that’s made me a better developer.
It’s also a challenge that makes our products better
The more reusable your code, the more efficient your coding — and the more efficient your design and your software. By editing our design down to the functionality an application really needs, then coding those designs into reusable modules, we’re able to make better software. A simpler design is easier to navigate, a smaller codebase is easier to maintain, and the two together create an end-product that’s more coherent, that loads faster and that optimizes your performance.
See how we handle a full code audit — frontend, backend and infrastructure
The benefits of code reuse are catching on, but the best practices behind it definitely haven’t spread to every development team. Our frontend audits can catch opportunities to switch to reusable code, optimizing your website’s performance now and giving you a better sense of the benefits a full redesign would offer.
The many, many benefits of reusing code
In development, there’s a motto that “every line of code is a liability,” based loosely on the work of scientist Edsger Dijkstra. The more code you write, the more opportunities there are for errors, bugs that can muck up your software and waste your time.
That’s basically the meaning behind why reusable code is so important. If we can limit the code, we can limit the opportunities for things to go wrong. But that’s like the least exciting of the code reuse benefits. It doesn’t just make it easier to avoid mistakes — it makes it easier to grow.
A reusable code repository is a scalable code repository. Choose from the same elements, and you have a new page that fits right in with all your others. Bring on new people, and they can very quickly learn how to build within you system. Hand the code off to an entirely new team (like we did with LandscapeHub), and all you need is a little documentation for them to run with it.
Then there’s the speed. Smaller codebases load quicker, so reusing code is a direct way to optimize your site performance. Though the code is only part of it, that performance improvement is also thanks to reusing design elements — and all the benefits that come along with that.
Need help making your site even faster? An infrastructure audit can help.
How code reuse best practices support design best practices
The idea that there’s a code reuse vs. design reuse fight is kind of ridiculous. Design and development aren’t opponents — at Table XI we’re part of the same team. We both need to deliver our best, and so we work side-by side. Our UX designers can bounce ideas off of our frontend developers and see what’s possible, and our frontend developers get insight into the design. I personally enjoy collaborating with the designers, because it allows me to internalize their decisions. I know why they used certain colors and typography, and I can structure the frontend code to honor those objectives.
When we work like this, neither side has to compromise. One of the benefits of reusing code is that it also reinforces design best practices. Users can navigate a site better when there are repeatable elements that always do the same thing — like a button always using the same color. It creates a more cohesive, navigable site.
… And how code reuse helps developers stick to the design
This process also makes it much, much easier for a team to stick to a design. Writing reusable code for design elements is essentially like building a custom version of Bootstrap, a CSS, HTML and Javascript library of reusable styles people can use to build a site. The code itself guides you to follow the design rules, allowing you to grow pretty far before you need a designer to add new elements to the visual system.
Like I mentioned above, this is basically what we did for LandscapeHub. We knew the marketplace startup wanted to build an internal development team, so we made sure everything we designed was as ready to hand off as possible. When it was time to migrate to the new team, all we had to do was create a round of documentation on the benefits of the style guide and how to use it. Their developers loved it. They immediately felt confident about understanding the code. Everything was organized and reusable, so they could take ownership and start building.
A code reuse example to illustrate what we’re talking about (and maybe make your brain hurt)
If it’s hard for you to fully see the advantages of code reuse, it’s pretty easy to see the downsides of not doing it. For one of our frontend audits, I walked through a client’s design looking for one simple thing — error messages.
The client had a fair amount of forms for signing up, signing in and using the service, and pretty much each one used a different style to tell you when something was wrong. This isn’t just different font-sizes — we’re talking totally different colors, styles and locations. If you’re a user, there’s no consistency. Every time there’s an error, you have to search to find the message, instead of being able to rely on the visual shortcut of repeatable design.
How we define reusable code — and how we audit for it
When we’re trying to define code reusability, it’s not just about having elements repeat. In a frontend audit, we’re definitely looking at the actual UI to see how reusable the design system is. But on the other end, we’re going to be looking for whether that code is built in a reusable way. It’s totally possible — it’s actually pretty common — to have a reusable UI, but not code that takes advantage of it. You have to structure and organize your code to be reusable and scalable if that’s your goal. A simple site alone won’t get you there.
During a code audit, there are a few things that right away will let us know if your software supports code reuse. We look at how the stylesheets are organized, how they are included in the application and in what order they are pulled. The organization and order of the stylesheets are both good indicators of how the styles work together and whether they were written with reuse in mind.
We also look at individual styles within each stylesheet, paying attention to things like styling elements using IDs, nesting, variable usage and !important;. Styling elements using IDs is inherently not reusable, as IDs need to be unique. Each element can have only one ID and each page can have only one element with that ID. Using classes to style elements instead of IDs allows us to really optimize for reusable components and reduce the amount of specificity in our stylesheets.
