Back to Basics

Sometimes we face hard choices, where there’s no clear path or direction. Actually, we might not even have a clear goal.

NOTE: This post was first published in my newsletter. Subscribe to receive my posts a week earlier, right to your inbox 🚀

You’ve probably been there before. Think about it. Situations where the line dividing “the right call” and “a fucked up mess” seems blurry.

On such occasions, the temptation is to take a step back. To go back to a previously known state. Back to safety.

You might end up suggesting things you would not consider given other circumstances.

I’m here to tell you that when things derail, we need to go back to basics.

(Now that I’ve told you so, my job here is done. But since you’re likely locked down at home and quite bored, feel free to keep on reading).

What do I mean by “back to basics”?

Ship working software

Shipping working software in opposition to shipping… shit.

The software should be ready to deploy at the end of every iteration. The fundamental measure of progress is working software.

“Working” software is not an empty word. It means software we agreed upon. Tested. Integrated. Solid.

Welcome changing requirements

Things change. It’s a fact. If you don’t like it, you’ll have a hard time working in the software industry.

The software should be easy to change. Easy to delete.

Thus, software should be simple. Everything should be. Making things complex is making stuff that’s hard to change.

It’s so hard to make things simple. But it’s the only way.

Maintain a constant pace

If you try to go faster and faster, you’ll set unreasonable expectations and eventually burn out. Don’t do that.

To do so, you need to keep the code clean, the architecture clean, the design clean. As clean as possible. Set a constant flow of delivery that you can sustain for a long period of time. That’s the best way we can provide value.

Cover for each other

You and your team are more than a group of individuals.

Help your team stay motivated. Provide the support its members need.

To do so, break knowledge silos.

To do so, help define the purpose of your team, make sure people have the right amount of autonomy and constraints.

That’s mostly it: Back to basics.

Is it easier said than done? Sure it is.

Does it make it any less valid? No, it doesn’t.

When things become harder, try and make everything as straightforward as possible.

We know how to solve small problems, don’t we?

Small teams, frequent releases, delivering value through maintainable, well-tested code.

There is only one way to eat an elephant

You don’t solve big problems by going big.

You solve big problems by breaking them and making them small. Then you simply fix a bunch of small problems.

There is only one way to eat an elephant: a bite at a time.

Originally published at https://afontcu.dev on March 18, 2020.