Hidden foundations

In the first glorious rush of building a new product, it’s unusual for a small team to be too concerned about building stable platforms and foundations for the future.

Almost inevitably, this means early versions of a product are an uneven mish-mash of elegant solutions, filthy hacks and so-so glue code.

The correct response to this is a balance of embarrassment and pride. The embarrassment helps you to think about valuable improvements, and the pride helps you to focus on shipping.

Assuming the product is successful, and your team grows and possibly splits into multiple teams, more and more people will add to this glorious mess. Each of them will bring different concerns and specialisms.

The inevitable result is growing desire to make improvements. Typically these suggested improvement take the form of extracting common concerns, the ‘foundation’ that we’ve been talking about this week.

‘We need a component library to make the design more consistent.’

‘We should create an API client library rather than just write all these Ajax calls everywhere.’

‘We need to refactor and centralise all the CSS to put a stop to all this specificity creep.’

But it’s easy to miss the foundations that are already there, hidden in your product’s code base and assets.

Did one developer use a particular elegant pattern for abstracting API calls somewhere?

Did a designer that has now left the company make a short-lived but noble effort to unify all the form fields across the app?

It’s not always obvious that these unofficial attempts at foundational work have even happened. If you’re new to the product or company, or the product is just too big to keep on top of, they’re easy to miss.

Sometimes, you need to spend the time to do some serious archaeology.

Hit reply and tell me one surprising thing you found in your product’s code recently.

This could be a positive thing, or a negative thing, like the time I discovered we had three separate versions of jQuery loaded on each page.

All the best,

– Jim