• 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

Website Redesign v11

....

I've once again updated my personal website, this time powered by my own RSC framework and a custom CMS solution as well!

Onboarding Your New AI Teammate

....

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

....

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

....

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

....

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

....

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

Podcasting By Hand

....

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

....

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

On File-System Routing Conventions

....

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

You're Building Software Wrong

....

Slicing software: why vertical is better than horizontal.

Single File Web Apps

....

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

Resetting Controlled Components in Forms

....

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

A Quick Look at Import Maps

....

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

Recommended Tech Talks

....

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

Request for a (minimal) RSC Framework

....

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

Bluesky Tips and Tools

....

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

The Bookkeeping Pattern

....

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

TSLite

....

A proposal for a minimal variant of TypeScript!

Monorepo Tips and Tricks

....

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

Next.js with Deno v2

....

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

Don't Break the Implicit Prop Contract

....

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

A Better useSSR Implementation

....

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

My Current Dev Setup

....

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

Abstract Your API

....

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

Tip: Request and Response Headers

....

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

Using Feature Toggles to De-risk Refactors

....

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

....

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

Custom Favicon Recipes

....

Two neat tricks for enhancing your site's favicon!

Corporate Sponsored OSS

....

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

The Library-Docs Monorepo Template

....

A monorepo template for managing a library and documentation together.

Building Better Beacon

....

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

Project Deep Dive: Tails

....

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

Churn Anxiety

....

When did semver major changes become so scary?

Service Monitors and Observability

....

Leveraging service monitors properly to improve service observability.

On Adopting CSS-in-JS

....

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

....

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

Pair Programming

....

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

Suspense Plus GraphQL

....

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

You've Launched, Now What?

....

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

Taking a Break

....

A few quick thoughts on burn out and taking a break

Managing Complex UI Component State

....

A few thoughts on managing complex UI component state within React

Understanding React 16.3 Updates

....

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

CSS in JS

....

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

Redesign v6

....

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

JavaScript Weirdness

....

A few weird things about JavaScript

Calendar

....

Building a calendar web application