The truth about best practices.

“We should do it that way because it is best practice!” Does this sentence sound familiar to you? I’ve heard it many times in the context of software development. I don’t know why, but when people say the phrase “best practice”, most of the room agrees with them without hesitation – almost like they’ve cast a spell. The final, superior argument. It sometimes ends the discussion, and there aren’t many people asking what it actually means for something to best practice.

In this article we will explore the true meaning of “best practice.” First, we will find out where it comes from. Then, how IT industry approached it. Finally, we will end with what it means nowadays in the context of software development and how we should respond when we hear such a phrase.

Let’s first check what the dictionary says – like in the old days without LLMs. Here is the Cambridge Dictionary definition [1]:

a working method, or set of working methods, that is officially accepted as being the best to use in a particular business or industry

First of all, the dictionary defines “best practices” as a method or set of methods. What makes these methods “best” is that they are commonly accepted by a community within particular business or industry. The definition is quite vague, so to better understand it, we need to examine a real use case. And there’s no better place to start than the beginning!

To discover when the term “best practice” was first used, we can look again at a dictionary—but this time, the Oxford English Dictionary. According to the OED, the earliest known use is from 1920s, with the earliest evidence appearing in Popular Science in 1927 [2].

We can fairly say the term has been known for about 100 years, perhaps even longer, but without evidence, let’s stick to 100 years. Since we know where it was first used, we need to study the context of that usage to understand it better.

Thanks to the good old dictionary, we know the first recorded usage comes from Popular Science magazine. The magazine made science, technology, and mechanics accessible to the general public, targeting DIY enthusiasts, tradesmen, and homeowners who sought practical technical knowledge for home projects and skill development.

The term “best practice” appears in an advertisement for books aimed at builders. Each book contains “Trade Information”—specialized knowledge, techniques, and insider insights specific to a particular skilled craft. Here is the exact usage [3]:

Every Bricklayer, Cement Worker, Plasterer, Tile Setter and Stone Mason will find the answer to his questions and problems in this series. Inside Trade information on all the latest and best practice. A Study Course and complete reference library covering the Mason’s Trade; including practical outline of steel construction. A helping hand for workmen and constructors.

Fortunately, we have the internet, and we don’t have to pay for the guide. In the book, we can find plenty of good advice. Imagine you want to become a bricklayer: in such a book, you can find information about proper tool handling, such as holding the trowel loosely yet firmly with correct hand positioning. Or if you’re a more experienced bricklayer looking to increase efficiency, you can learn about spreading enough mortar to lay multiple bricks at once [4].

We can see that regardless of industry or profession, people define fundamentals and guidelines that help us improve our daily work. Therefore, this is not unique to the IT industry—such an approach can be seen everywhere. It stems from human nature, where we naturally strive for continuous improvement.

Compared to building construction, IT is a very young profession. However, that doesn’t matter. People notice problems and want to overcome them. From the early days of computing, specialists gathered to discuss potential solutions.

In 1967, the Science Committee established a Study Group on Computer Science to assess software problems. The group recommended a working conference on Software Engineering to discuss current challenges and potential solutions. The following year, computer scientists convened in Garmisch, Germany for the NATO Software Engineering Conference. The conference addressed the apparent software crisis: the world’s growing reliance on software was being undermined by systems that were becoming larger, missing deadlines, exceeding budgets, and proving difficult to change. Attendees discussed these challenges and proposed ways to align software creation with established engineering disciplines [5].

The conference did not result in any strict guidelines defining concrete best practices. However, an extensive report was created, organized by the topics discussed. Attendees shared the problems they had observed and potential solutions [6].

I really encourage you to review the report. You don’t need to read it in its entirety—just scroll through it and you’ll find that the problems discussed sound very familiar, as do the proposed solutions. This raises an important question: were those problems ever overcome?

We move forward 20 years in history. This time, the U.S. Department of Defense faced a critical problem: software projects were routinely over budget, behind schedule, and riddled with defects. In response, the Software Engineering Institute (SEI) at Carnegie Mellon University was established in 1984, specifically funded by the DoD to address these software engineering challenges. The SEI was tasked with creating a framework to assess software development maturity [7].

Maturity was defined as the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. A mature organization could consistently deliver quality software on time and within budget because its processes were stable and repeatable [8]. The model was designed to directly address the DoD’s specific pain points.

Yet another attempt to address software development issues. Can we call it a success? At the time, it certainly seemed to be. But as far as I know, the IT industry still misses deadlines and goes over budget.

Currently, we don’t remember what people did 50 years ago. However, we build new best practices based on their experience. For example, we have concepts that are considered best practices today: Continuous Integration [9], SOLID principles [10], and Domain-Driven Design [11]. Developers are expected to be familiar with these concepts nowadays. But the question remains: will these best practices stay valid and in use forever? History shows this is very unlikely.

You can see that throughout history, we’ve been having the same discussions about the same topics. We create software, and the list of problems remains consistent: difficulties delivering on time, systems that are hard to change, projects that go over budget. These problems were first noticed around 60 years ago at the NATO conference, then again in 1986 by the DoD, and I believe at thousands of other events since—indeed, we seek best practices to improve our process every single day.

Software development is still a very young industry compared to others, but it’s rapidly evolving. How we build software today differs drastically from how we built it 20 years ago. Given recent changes and LLM adoption, it will change again. This means that what we claim as best practice today might be wrong tomorrow.

Therefore, we should know best practices and learn from others’ wins and mistakes, but we should remember two important things:

• Best practices are contextual. What worked for others won’t necessarily work for us.
• We shouldn’t stick to the same best practices indefinitely. We must question them and seek new ones. Software development evolves, and so do best practices.

The next time someone uses the “best practice” argument, don’t follow blindly. Ask for alternatives. That way, we can make an informed decision and choose the truly best option from all available alternatives.

[1] Best Practice Dictionary Definition
[2] Best Practice First Usage
[3] Science Magazine 1927
[4] Audels Masons And Builders Guide
[5] NATO Software Engineering Conference
[6] NATO Software Engineering Conference Report
[7] Software Engineering Institute History
[8] Capability Maturity Model for Software
[9] Continuous Integration
[10] SOLID
[11] Domain Driven Design