New project? Start at the edges

Finally that mytical creature is right in front of your eyes.

The one you've been hearing about through your entire career.

The one you started wondering whether it even existed in the real world.

This is it.

A Greenfield project appeared.

You are very excited and eager to sink your teeth into it.

Everything is there to be defined. You get a chance to shape it to your liking.

Let's add a couple of clouds to this clear blue sky, just enough to make it real.

There are some neighbours already there and your app, as the new kid on the block, better play nice with them, right?

Your best chance of success? Start by drawing a clear line.

Why?

Because, once you got these parts solved you can go back to focusing on your bussiness.

It's like when you were a kid and you had to color the picture:

How could you make sure you stayed within the borders?

A nice technique my mother told me back then was to start drawing a new border of my own, right beside the pre-existing one, once I was done I was supposed to draw yet another one, closer to the center and repeat the procedure until the whole thing was done.

The same principle applies here.

The key is to realize that the closer you get to the center the more control you have.

Let me bring this down to earth with a software example:

Say you have to build some sort of middleware... An API Gateway will do.

The idea is simple:

• On one end there's a bunch of vendors who have created their own standard to perform X (Buy airtime top-ups, giftcards, process payments... you name it).
• On the other end there's a group of users who need to solve Y leveraging any (or many) of the vendor's APIs

Your project is right in the middle. The knight in shinning armor who will kill the complexity dragon once and for all.

So basically, your job is to create a multiplexor:

You might be tempted to start working from the inside, putting together a lot of complex logic to transform the input into the expected calls to the specific vendors and that's fine but I suggest you do just the opposite.

Start by focusing on solving the communication between your client application and, at least, the first vendor you'll integrate with.

Once you're done with that, refrain from going deeper. Instead, try to deploy a dummy version which will simply echo what it got without doing any transformation whatsoever.

Sounds boring? Well... that's because it is. My advice is: if you want entertainment or adrenaline, go to an amusement park. In a software project boring is king.

The point is, there's so much you don't know when you first start that reducing complexity is what you want. And the places where most complexity lies are the parts out of your control.

So again, start with the most annoying parts. Get them out of the way as soon as possible and then enjoy the rest of your journey.

Final note: combine this approach with Acceptance TDD and you'll get a real powerful thing going on.