Best Practices Don't Exist

The best engineers look for the best solutions.
Unfortunately, there is rarely a single right answer.

These occurrences happen often in daily life.

Should you buy smooth or chunky peanut butter?
Should you run in the morning or evening?

These questions may not have a perfect answer.
And yet engineering is much more complicated.
And much more prone to having no single right answer.

So why does the community act like they have the right answer?
And why do they fight over each of these “best practices”?
And how do you sift through the noise?

If more communities were open to ideas and critical thinking, perhaps there would be more unity.

As for your project, you can decide with the SLICE technique.

One Size Does Not Fit All

Have you ever bought a well-tailored piece of clothing?
Have you ever bought a one-size-fits-all shirt?

The differences are staggering.

One is a nice, clean fit that suits your form from head to toe.
The other is a messy fit that vaguely resembles the average size of the population.

It’s too big for the trim population.
It’s a fit for those in the middle.
It’s a bit small for the rest.

Not to mention differences in height.

Software is no different.

Apps come in all shapes and sizes.
Apps all work to solve different problems.

Best practices need to be based on intuition and a deep understanding of what problems you need to solve.

Moving Targets

Best practices change all of the time.

Tools evolve.
New patterns emerge.
Community change their minds.

A best practice from 20 years ago likely wouldn’t serve any team well today.

That is to be expected.

For instance, Android has at least 4 different ways of getting access to elements on a screen so you can manipulate their properties:

• findViewById(): The original name in town.

• Butter Knife: Let a tool save you just a few letters of typing.

• View Binding: Let a different tool analyze your code and do it for you.

• Kotlin Synthetics: Same as view binding, but with less setup.

Ironically, today’s cutting-edge apps use a fifth technique to accomplish the same goal.

That is to say, “best practices” can be short-lived and very specific to the mentality of a certain era.

Herd Mentality

X (formerly Twitter) is one of the best platforms for developers to share their ideas and work.

Unfortunately, in today’s world of plentiful soapboxes and large digital audiences, poor ideas proliferate.

Fancy influencers recommend an idea.
Their idea worked for one of their projects.
Their idea often isn’t vetted but is posted anyway.
Their idea is eaten by their followers like tested, sound advice.

What’s the goal?

Accolades.

Not stability.
Not time-tested truths.
Not hard work to fix any of its shortcomings.

These ideas are adopted and further spread by people following the crowd of influencers with a brand and their software suffers the consequences of these poor decisions.

At best, these ideas are short-lived and relatively unknown.
At worst, the flaws in these recommendations can derail a project.

Don’t follow the herd just because someone recommends a practice. Research it with unbiased eyes and see if you agree.

SLICE: Find Your Best Practice

There is no right answer.
The target is always moving.
People are taken in by influencers.

The landscape sounds bleak.

However, I have a technique for finding the best practices for the current era of my projects. I call it the SLICE technique.

What It Does

Its outcome doesn’t give you a magical answer or even any formal recommendations, but it helps you ask the right questions, do the right research, and get the right answer for your project.

Nothing is future-proof, but it answers an essential question: does this practice help or hinder my team when solving a specific problem?

Best practices don’t revolve around tech; they revolve around people.

What It Solves

You need a break from the noise.
You need micro and macro clarity.

SLICE gives it to you.

You can use this guide as you consider:

• What to keep in mind as you write your code to solve your problems.

• What application architecture to use.

• What tools to adopt.

The Blueprint

Here is the guide in detail:

• Stand out: There is rarely a problem in software that is solved by a single tool or idea. What draws you to this one? An influencer? A common industry convention? Simply put, it is hype or healthy thinking that brought you here?

• Longevity: How long has this concept been around? Will the health of this tool or idea keep it around for 3 or more years? Who developed it? Can this organization or community continue to invest resources into its future?

• Intent: What was the intent of the idea or tool? For instance, MVC is a good general-purpose architecture but isn’t well-suited for applications with frequent updates to the UI, like stock trading or social media applications. Redux or Flux are often better suited to these applications. Once again, there is no single right answer, but keeping the original problem it solves in mind helps you frame your decision.

• Community: This is similar to the longevity question. How large is the community? Why is there a community? Was it because of hype or real problems that it solved? Are they willing to help see the continued success of this concept? Can you get your questions answered by said community, or is it too small and immature to have a good knowledge base?

• Ease-of-use: How simple is this tool or idea to adopt? Does it have a large overhead to use or a steep learning curve? If so, is this investment justified?

This approach is a three-pronged solution.

Use SLICE when you are considering the philosophical aspects of your code.
Use SLICE as you write your code that others will eventually consume.
Use SLICE when you want to invest in a new tool or framework.

In this article, I make no formal recommendations.

This all boils down to two ideas: critical thinking and a good understanding of what your project is expected to achieve.