• Home
  • Blog
  • Projects
  • Bookshelf
  • About
← Back to all posts

Maintenance Costs

Published 📅: ....
Last modified 📝: ....

Share this post on BlueskySee discussion on Bluesky

One of the first large-scale projects I worked on at Wayfair as a software engineer was on our first ever desktop Grid system. It was late 2016, maybe early 2017 at that point, we had a shared mobile grid system that was using Flexbox for alignment and spacing, however we did not yet have a layout system for desktop browsers. Because we are an e-commerce company we still had to support IE8 and other IE browsers, so we couldn't just use the same mobile grid we were using elsewhere.

I don't remember exactly what made me do it, but I decided to pick up that work to create a shared global grid system for our desktop web experiences. We decided to use a progressive enhancement methodology and start with an inline-block system for the grid and then enhance to using Flexbox for the browsers that supported it. At the time this was a big step forward for us, many of our features were not using Flexbox for layouts, floats were the most common solutions that other frontend developers were using.

Setting the scene a bit, in early 2017 Wayfair was still using two separate codebases for our mobile web and desktop web experiences, responsive design was still questioned heavily by design, engineering and product. Our styles, authored in scss, were authored in two separate files for the mobile web and desktop features. Our bundler would then determine the user agent and serve up the appropriate styles to the customers browser.

When we started work on the desktop grid system, we aimed to fit the same model that mobile web was using as future looking development for teams to begin building responsive layouts using the same grid systems. So we started from the mobile web grid, using Flexbox as the backbone and then added in an inline-block + font-size 0 fallback system for older IE. We actually even started by wrapping our flexbox system behind an @supports "barrier", so even browsers like IE10 and IE11 wouldn't get the Flexbox based grid. This was a mechanism to avoid common flex-bugs that existed within these browsers at the time. At this time, we also added support for responsive column widths, meaning some columns could take up half the width of the grid on mobile and then take up a third or a fourth of the grid on desktop.

Over the two years since we first released the universal grid system for our frontend at Wayfair, we have slowly been adopting new technologies and patterns. During that time we shifted from using mustache templates to writing our code using React and components. We ported the Grid system over to a set of reusable components that developers can build layouts with, we pulled out useful parts of the grid into smaller atomic components for building simpler layouts as well (what we call the Block and Flex components for adding spacing and flexbox layout support).

Through these past two years the majority of the fundamentals of the Grid have remained solid, we haven't rewritten the whole grid system just yet, but we have slowly been adding to the system. Adding new features, all the while keeping the existing API working for those really old pages still using the initial versions of the Grid for their layout. Over time this has made the code more and more unmaintainable for engineers, often when we find a ticket to add a new feature to the Grid we find ourselves putting that work off. Hoping that we will come up with an elegant solution to this mess of code.

Its gotten to the point that a change to our grid system, will cause a 1-2 minute scss compile for the grid styles alone 😱. Putting that into scale, the Grid is currently around 500 total lines of scss code. That code uses a lot of maps, loops, variables, conditionals, dynamic classname construction and many other scss language features that we don't use elsewhere within our massive codebase.

I think a pessimistic takeaway from this is that all code becomes tech debt over time, maintenance costs on code increase as time grows. While this code has accrued its fare share of technical debt, it has also stood the test of time. It's largely the same API as it was when we first implemented it, and for the most part has held the test of time.

As software engineers, we aim to write code that has the lowest maintenance cost as possible, often we do this because we will end up maintaining that system in the future. However, its difficult to find the right abstraction the when you first write the code for the feature. It takes time to understand how the system will work, to evaluate how consumers of the API will expect it to work, and to also see how the systems around that change.

Accepting maintenance costs for authored code is the first step to understanding that you don't need the perfect abstraction. The beauty of software is that it continuously evolves over time, the patterns we use today to architect a solution will most likely not be the same as the ones we use next year, or 10 years from now.

Tags:

Web Development

Loading...

Related Posts

Web Development

Onboarding Your New AI Teammate

Published: ....

Are we reinventing the wheel when it comes to onboarding new AI agents to a codebase, when we already have primitives available for onboarding humans?

Quick Tip - Theme Aware Images

Published: ....

Have you ever found the need to change the image you render on a web page based on the current preferred color scheme of your theme?

Async Class Creation In JavaScript

Published: ....

Have you ever wanted to create a class in JavaScript or TypeScript but also have the initialization be async? Here's a quick tip on a pattern that I've used in the past!

Website Redesign v10

Published: ....

I recently launched a rewrite and redesign of this personal website, I figured I'd talk a bit about the changes and new features that I added along the way!

Server Side Rendering Compatible CSS Theming

Published: ....

A quick tip to implementing CSS theming that's compatible with Server Side Rendered applications!

Podcasting By Hand

Published: ....

A brief overview on how we launched The Bikeshed Podcast, including a deep dive in our recording and distribution workflows!

Quick Tip - Specific Local Module Declarations

Published: ....

A quick tip outlining how to provide specific TypeScript type definitions for a local module!

On File-System Routing Conventions

Published: ....

Some rough thoughts on building a file-system routing based web application

You're Building Software Wrong

Published: ....

Slicing software: why vertical is better than horizontal.

Single File Web Apps

Published: ....

What if you could author an entire web application in a single file?

Resetting Controlled Components in Forms

Published: ....

A quick way to handle resetting internal state in components when a parent form is submitted!

A Quick Look at Import Maps

Published: ....

A brief look at Import Maps and package.json#imports to support isomorphic JavaScript applications!

Recommended Tech Talks

Published: ....

A collection of tech talks that I regularly re-watch and also recommend to everyone!

Request for a (minimal) RSC Framework

Published: ....

Some features and functionality that I'd like within a React Server Component compatible framework.

Bluesky Tips and Tools

Published: ....

A (running) collection of Bluesky tips, tools, packages, and other misc things!

The Bookkeeping Pattern

Published: ....

A quick look at a small but powerful pattern I've been leveraging as of late!

TSLite

Published: ....

A proposal for a minimal variant of TypeScript!

Monorepo Tips and Tricks

Published: ....

Sharing a few core recommendations when working within monorepos to make your life easier!

Next.js with Deno v2

Published: ....

This is a quick post noting that Next.js should now work with Deno v2!

Don't Break the Implicit Prop Contract

Published: ....

React components have a fundamental contract that is often unstated in their implementation, and you should know about it!

A Better useSSR Implementation

Published: ....

Replace that old useState and useEffect combo for a new and better option!

My Current Dev Setup

Published: ....

A quick look at the applications and tools that I (generally) use day to day for web development!

There Is No Standard Markdown

Published: ....

There are a variety of different markdown "standards" out there, and sometimes they're not all that consistent

Abstract Your API

Published: ....

Proposing a solution for sharing core "business" logic across services!

Tip: Request and Response Headers

Published: ....

There's a common gotcha when creating Web Request and Response instances with Headers!

Using Feature Toggles to De-risk Refactors

Published: ....

Feature toggles are often underused by most software development teams, and yet offer so much value during not only feature development but also refactors

Hohoro

Published: ....

A quick introduction to my new side project, hohoro. An incremental JS/TS library build tool!

Custom Favicon Recipes

Published: ....

Two neat tricks for enhancing your site's favicon!

Corporate Sponsored OSS

Published: ....

The various risks and pitfalls of open source software run by corporations.

The Library-Docs Monorepo Template

Published: ....

A monorepo template for managing a library and documentation together.

Building Better Beacon

Published: ....

How we solved an almost show-stopping production bug, and how you can avoid it in your own projects.

Project Deep Dive: Tails

Published: ....

A(nother) deep dive into one of my recent side projects; tails - a plain and simple cocktail recipe app.

Churn Anxiety

Published: ....

When did semver major changes become so scary?

Service Monitors and Observability

Published: ....

Leveraging service monitors properly to improve service observability.

On Adopting CSS-in-JS

Published: ....

A brief recap of how Wayfair changed it's CSS approach not once but twice in the span of 5 years!

Project Deep Dive: Microfibre

Published: ....

A deep dive into one of my recent side projects; microfibre - a minimal text posting application

Pair Programming

Published: ....

Pair programming can be good sometimes - but not all the time

Suspense Plus GraphQL

Published: ....

A few thoughts on using Suspense with GraphQL to optimize application data loading

You've Launched, Now What?

Published: ....

A few thoughts on what to do after you launch a new project

Taking a Break

Published: ....

A few quick thoughts on burn out and taking a break

Managing Complex UI Component State

Published: ....

A few thoughts on managing complex UI component state within React

Understanding React 16.3 Updates

Published: ....

A quick overview of the new lifecycle methods introduced in React 16.3

CSS in JS

Published: ....

A few thoughts and patterns for using styled-jsx or other CSS-in-JS solutions

Redesign v6

Published: ....

A few thoughts on the redesign of my personal site, adopting Next.js and deploying via Now

JavaScript Weirdness

Published: ....

A few weird things about JavaScript

Calendar

Published: ....

Building a calendar web application