Something Is Easier to Change Than It Is to Create

There is a sentence I've found myself using more and more over the years:

Something is easier to change than it is to create.

I don't remember when I started saying it.

It wasn't something I learned from a book or a methodology. It gradually became part of how I work because, in my experience, it works surprisingly often.

Especially when working with senior leadership.

Their time is usually limited. If I get 30 minutes with someone, I don't want to spend the first 20 minutes collectively staring at an empty page.

I want to bring something we can disagree with.

Never bring an empty page

I learned this particularly well during my time at BCG.

At one point, I was asked to develop an idea around dropshipping that could eventually be presented to a client.

I didn't have a finished briefing. There were no numbers yet, no research and certainly no finished presentation.

But I knew roughly what we were trying to achieve, and I knew I had a meeting with a Partner coming up.

BCG teaches people extensively how to structure presentations and tell stories. We also had plenty of existing templates and patterns to work from.

So instead of waiting for the meeting, I created a version 1.

I built the agenda, created empty slides and wrote a headline for each one.

There wasn't much content.

But if the headlines are good, you can already read the story of the presentation without seeing any of the details underneath them.

That changed the conversation completely.

Instead of asking:

we could discuss something concrete:

The Partner didn't have to create the story with me. They could use their experience to improve one that already existed.

And I could leave the meeting with an approved direction and a pretty clear idea of what needed to happen next.

That saves round-trips.

More importantly, it makes much better use of everyone's time.

The worst case is surprisingly harmless

There is an obvious risk to working this way:

What if version 1 is completely wrong?

Then you throw it away.

You start from zero and do the work you would have had to do anyway.

That's the worst case.

In practice, I've rarely experienced it.

Usually, you know enough about the goal before a meeting to at least get the direction roughly right.

And even when parts of your proposal are wrong, they can still be useful.

It's easier to explain why something doesn't work when you can point at it.

It's easier to discover what you want when you can react to something you don't want.

And bringing an opinion creates another opportunity: it allows other people to build on your thinking.

I've often brought a viewpoint into a discussion that a more senior person hadn't considered. They could then combine it with their own experience and turn it into something much better than either of us would have created alone.

Version 1 isn't supposed to prove that you already know the answer.

It's there to give everyone something to think with.

This isn't really about presentations

The same principle works in engineering.

Imagine a team needs to make a technology decision.

You could invite five engineers into a room and ask:

And then start collecting opinions.

Or someone could prepare the discussion.

That doesn't necessarily mean arriving with the decision already made.

A version 1 might simply be a list of criteria, the current pros and cons of both options, and perhaps a scoring system based on what matters to the product.

The team can challenge the criteria first.

Add missing ones.

Remove irrelevant ones.

Challenge the scores.

And then make a decision.

The important part isn't whether the artifact is a presentation, an architecture proposal, a domain model or a technical evaluation.

Good preparation moves the conversation away from creation and towards improvement.

And improvement is usually much easier.

But doesn't this anchor everyone on your opinion?

There is a legitimate problem with bringing version 1 into a discussion.

The first proposal can become the default.

Especially if it comes from the most senior person in the room.

That's not something you can solve with a document format or another process.

You need the right team culture.

Whenever I lead a team, I try to make something clear from the beginning:

I have strong opinions about some things.

I have no opinion at all about many others.

And everything is open for discussion.

If someone has a strong opinion, I expect them to bring it into the team and make the argument.

If someone disagrees with my version 1, that's useful information.

As a lead, you also have a responsibility to notice when this isn't happening.

Sometimes that means directly asking someone what they think.

Sometimes it means deliberately challenging your own proposal.

Sometimes I'll construct an absurd scenario in which my own idea obviously falls apart just to demonstrate that the thing on the screen isn't sacred.

The proposal is there to start the discussion.

Not to end it.

Not every version 1 should be cheap

There is an important limitation to this principle.

Not all decisions are equally reversible.

If we're discussing the wording of a button, I don't need two days of research before making a decision.

If we're choosing the identifier strategy for the entire backend, I might.

Imagine building a large system around ULIDs and deciding much later that you actually want UUIDs.

That decision can spread everywhere.

Database fields.

Types.

Backend classes.

Tests.

Fixtures.

APIs.

Migrations.

Potentially external integrations.

Changing it might take weeks.

The same is true for parts of your domain model.

If hundreds of features are eventually going to build on a fundamental concept, understanding that concept early is worth the investment.

So "we can always change it later" isn't an excuse to avoid thinking.

The question is:

How expensive will it be to learn that we were wrong?

The higher that cost, the more confidence I want before committing to version 1.

For smaller decisions, the equation is very different.

If changing something takes an hour, spending three days trying to make the perfect decision in advance makes very little sense.

You can't design version 5

The other extreme is trying to anticipate every possible future.

Maybe we'll have multiple clients one day, so let's introduce GraphQL now.

Maybe we'll become huge, so let's start with microservices.

Maybe this feature will eventually need six different variants, so let's create an abstraction for all of them before the second one exists.

The problem is that we can only make informed decisions based on what we know today.

Everything else is a prediction.

And products have an annoying habit of not developing exactly the way we imagined.

That doesn't mean ignoring experience.

If I've built a similar product before and know that SEO will be critical on practically every page, that is useful information.

If we're building a shop or a price comparison product, for example, choosing an architecture that makes server-side rendering straightforward might be entirely reasonable from day one.

There is a difference between using experience to anticipate a known problem and building an architecture for an imaginary future.

I want to prepare for things I have good reasons to expect.

Not every future I can imagine.

Build for change, not for an imaginary future

This changes what I optimize for in a codebase.

I don't want to predict every requirement the product will ever have.

I want the codebase to remain understandable enough that we can change it when new requirements actually appear.

That sounds simple.

It isn't.

A lot of it comes down to discipline and clean code, and humans aren't particularly good at consistently choosing what's best for the future.

The easiest solution today is very tempting.

Tomorrow's maintenance problem belongs to tomorrow's developer.

That's one reason I like automation.

It doesn't eliminate inconsistency, but it can reduce the number of opportunities to create it.

If the same kind of component, API, store or other recurring structure always starts from the same generator, the easiest path and the consistent path become the same path.

But there is another thing that has probably helped me even more over the years:

I like boring codebases.

Boring is a feature

I don't want every new trend in a production codebase.

If something has worked well for three or more years, that's usually a positive signal to me.

It has matured.

People understand its problems.

Documentation exists.

Others have already discovered the weird edge cases.

The same applies to architectural patterns.

Most of the patterns I rely on aren't innovative. Many of them have existed for decades.

That's intentional.

Because most products aren't innovative everywhere either.

Maybe 5–10% of a product contains the thing that actually makes it special.

The rest is authentication, forms, permissions, APIs, data storage, navigation, tables, validation, deployment, testing and hundreds of other problems people have solved before.

I don't want my team spending most of its energy innovating there.

The less attention the boring 90% requires, the more attention we can spend on the 10% that actually differentiates the product.

That's also why I care so much about established conventions.

They don't make change impossible.

They make change more predictable.

Vuesion is a version 1

This is also how I think about Vuesion.

Vuesion isn't a claim that I've found the one correct architecture for every web product.

That would be ridiculous.

Every team is different.

Every product has different requirements.

And every company develops its own preferences over time.

Vuesion is a coherent version 1.

It uses established technologies, patterns and industry standards to make a large number of common decisions upfront.

Then you decide which ones don't fit your product.

If your team doesn't want to use CSS and prefers Tailwind, change it.

You'll have to remove the existing styling, configure Tailwind and adapt the component markup.

That's work.

But if you started from zero, you would have had to configure Tailwind and build all of those components anyway.

If your team wants GraphQL instead of REST, the same principle applies.

Change that part.

You don't need to recreate everything else around it.

Even if you eventually replace 20% of Vuesion, there are still 80% you didn't have to create.

And that's the point.

The interesting question isn't:

I think a much more useful question is:

Now you have something concrete to disagree with.

Version 1 creates information

For a long time, I thought the biggest advantage of this way of working was speed.

You get started faster.

Meetings are shorter.

Teams spend less time staring at empty pages.

And all of that is true.

But I think the more interesting advantage is what happens next.

Version 1 lets you test your assumptions.

Someone sees the presentation.

A customer uses the feature.

An engineer works with the architecture.

A designer tries to extend the component.

Real information starts replacing speculation.

Now you know something you didn't know before.

And that brings you to version 2.

The goal is version 2

Version 1 doesn't need to contain the final answer.

It needs to be good enough to create the information required for the next one.

After that, your job is to make sure version 3 doesn't require starting over again.

That's why I care about consistency.

That's why I care about tests.

That's why I prefer established technologies.

That's why I automate recurring patterns.

And that's why I try not to build abstractions for futures that haven't happened yet.

All of those things make learning cheaper.

The goal isn't to make a perfect first decision.

It's to make a reasonable decision with the information you have, learn what was wrong about it, and keep the system easy enough to change when reality gives you better information.

So when I say:

Something is easier to change than it is to create.

I'm not really arguing for moving faster.

I'm arguing for giving yourself something concrete to learn from.

Because the important question isn't how quickly you can create version 1.

It's how easily version 1 can teach you what version 2 should be.

This is how I build Vuesion

These aren't just ideas I write about. They're principles I've been building into Vuesion for more than eight years.

See how Vuesion works →