Nick Scialli

Targeted strategies over dogmatic best practices

If you’re anything like me, you like to understand the best way to accomplish software development tasks. But “best” is a loaded word: it implies there is a true and perfect way to do things. For organizations, best sounds big, risky, and time-consuming.

Best practices are often generalized truisms. They sound something like “implement the testing pyramid” or “use CI/CD.” They’re great big picture ideas when we feel like things could be going better. They’re not real or actionable.

But nothing we have discussed so far is the biggest problem with best practices. The biggest problem is that your organization doesn’t exist to implement best practices. Good code isn’t the objective. If you’re like most of us, your company’s primary objective is to make money. Or perhaps you work for the government and your primary objective is public service. But it’s certainly not to implement best practices.

Don’t implement best practices. Solve problems.

Often when we want to introduce a best practice, what we’re really thinking is, “this software has a problem that a best practice would solve.” We’re doing ourselves a disservice by not explicitly identifying that problem first. Identify it, socialize it, and get buy-in that it’s a real problem. Workshop it with colleagues to really nail down the core problem.

When identifying the problem, quantify it. If you can’t quantify the problem, it’s going to be hard to sell someone on spending time and money to fix it and even harder to demonstrate the fix worked. If you can use metrics to demonstrate the problem is affecting the bottom line, that’s amazing. Often, it’s good enough to choose a metric related to defects, customer satisfaction, or performance.

Once you have a well-defined problem, you can work on a solution. This is the time to pull from your knowledge of best practices—not as the solution itself, but rather as a “North Star” or underlying principle/theme for your solution.

Your proposed solution should ideally be incremental, measurable, and have some escape hatches. Deliver something at least every quarter and give management a way to determine whether the solution is on the right path to fixing the problem.

Once you have all of this, formalize it in a strategy document (or markdown file or whatever your org does). This kind of preparation is a dream for whoever has to make a go/no-go decision and will serve you well when you’re executing the work.

If you enjoyed this article, consider subscribing on Feedly or your favorite RSS consumer. If you'd like to chat, I'm most active on Bluesky.