There’s a lot to do when starting a new development project. Even assuming you’ve already decided which programming language you’re going to use, have you chosen a framework to build on top of or are you going it alone?

Are you going to generate your HTML server-side, or client-side?

Are you going to create your CSS from scratch or use something like Bootstrap to help you?

Picked a database?

What about a deployment process?

Build tool?

It would seem like a good idea to push a lot of these decisions till later. To concentrate on the app itself, before you decide how you’re going to do things like deploy and scale it. All those technical decisions can easily seem like something you can easily slot in later.

We’re here to suggest that’s a terrible idea.

Instead we suggest you follow three simple words: Make It Real.

Avoid the chewing gum

We’ve seen it over and over again. Everyone is keen to get started, the development team is standing by, so somebody hacks together a basic deployment process to get them all going. Probably just a main git branch for the team to work from, and let everyone develop locally. Database changes done through co-ordination between members and everyone running their own copy, updated libraries sent to each other via URL, and no real processes yet - just a small team who start the project together and know what’s what. It’s all temporary structure, the toothpick and chewing gum version of a house build.

But everyone knows it can’t last, that there needs to be deployment servers, and at some point you’re going to have to introduce a test environment, and somewhere for those shared libraries to live. You can’t go forever without some proper code review and a proper process for people changing your database schema.

The fact is that they’re never as easy to add as you think they’re going to be. People have written real code on top of this toothpick mountain and you don’t want the app to be broken for too long while you reverse engineer these in. Your team have other things to do, like completing the latest feature sprint, or getting ready for a customer UAT process. Those things that seemed easy to skip at the start have now become a huge weight around your neck, weighed down by the decisions made to work around the fact they weren’t there earlier.

From the start

When you put drywall up in a house, it immediately looks better. Everyone wants to reach that stage, because it makes them feel better about project progress. But if you had chosen to leave the electrics and plumbing until the end of the build, rather than doing them when everything was still exposed, you’ll get a shock when you find out how much harder it is to pull cables through walls that have already been sealed up.

This is why you need to make it real as early as possible. Get a proper deployment pipeline up from the start, don’t just let the code sit in Docker containers on each desktop. If you’re going to use something like Sonarqube or CodeGuru for code quality reviews, use them from the beginning and make sure you know what you’re looking for. Make your schema management tool part of your development process, even if you’re more lax over who can edit it and when it’s deployed than you will be later. Give your developers a real feel for what it’s going to be like developing with this codebase.

Make it real doesn’t mean make it perfect, nor does it mean making everything exactly as it will be during full production. The key is understanding the minimum amount you can do for each pillar of your project and realising that nothing is ever set in stone. Nothing needs to be gold plated. You’ll be refining throughout your development process and beyond.

But you can’t refine something that doesn’t exist. Make it real.

Contact us if you want to talk more about the right design decisions for your development project.

Photo by Sigmund on Unsplash