Think big, start small

February 21, 2022 · 4 minute read

It feels like everything has to ‘scale’ these days.

You can’t build a website for your local church, school, or village hall without feeling like you should be embracing microservices, employing event sourcing, or creating a complex, multi-layered behemoth.

Oh, and you’d better have that all set up and running before you even think about building the home page!

In many, many cases, you don’t need that level of complexity, and even when you do, the risk is you’ll get so caught up in choosing the “right approach” that you’ll run out of steam long before anything finds its way into the hands of a real user.

Choice is paralysing

We live in a world of endless possibilities.

Take a specific subject like Blazor component libraries for example. You only have to spend a few minutes researching the options and, before you know it, you find yourself buried under an avalanche of options.

With options, come possibilities, but also the weight of choosing the “best” one.

The problem is, we often forget to define our specific requirements before we start ‘assessing the options’.

Without a clear picture of what we need a Blazor component library to do, it’s largely impossible to compare them all and settle on the “right” one.

So how exactly do you get a clear picture of what we need?

You need data, and one sure-fire way to get data is to start building your app (or a part of it).

It’s so easy to get dragged into ‘research’, and ‘building up infrastructure’ but unless it’s backed by real data this sort of work is speculative at best.

But where do you find this mythical data?

Meet reality where it is

For me, the best data comes from actually getting into the weeds of the app you’re building, and not just from a technical perspective, but in terms of its actual value.

Here’s what I’d do.

  • Find a first, small, relatively simple, but valuable feature
  • Create a mockup for it (working with the people who know what they need)
  • Set about building it, in the simplest possible way

It’s important to pick something small and simple for this first feature because that way you can create some early momentum and momentum is the secret ingredient to successful projects.

Mockups are really useful because they’re quick to create, and iterate and, crucially, they help to get a dialogue going between the people who know what they want/need and the people who are building it.

But for you, the developer, the real magic comes from that third step; building something.

It’s when you start trying to recreate the mockup in code that you really start to understand what this feature, and ultimately the entire application, is all about.

As you try to build your small feature you’ll uncover clues about the work ahead. Maybe your CSS skills aren’t quite enough to meet the requirements of this project, so a utility library like Tailwind CSS would come in handy.

Or maybe it’s evident that there are going to be a lot of grids and forms in this project, and a component library with pre-built grids would speed up development considerably.

The good news is that now, having started to get “in” to the project, you’re collecting these insights based on reality.

The feedback you’re getting from trying to build the thing is infinitely more insightful than anything you had when you were stabbing around in the dark before you’d built anything.

Plus, if you share this first feature with the business at this early opportunity you get their valuable feedback on what you’re building too.

The aim is to collect as much data as possible, so you can make informed decisions about tools, architecture, and your development approach.

Build a few more features, incrementally adding tools to your toolkit as you go, and you’ll soon have everything you need to deliver the entire application.

Plus, it might turn out you don’t need to take that Pluralsight course on microservices after all :)

Web development should be fun.

Write code, hit F5, view it in the browser and bask in the glory of a job well done.

But you're not basking… Why aren't you basking?!

Cut through all the noise and build better, simpler Blazor web applications with Practical Blazor Components.

Practical Blazor Components Build Better Blazor Web Apps, Faster