Whether it’s personally or in public venues, people often ask for the best practices for addressing their problem or pain points. In software engineering, though, there are no best practices.
A best practice is a well-established and accepted technique superior to any alternative. Defining a best practice means seeking, through experience or research, the one best way to carry out an activity or task. Best practices assume a one-size-fits-all approach, ignoring context and complexity.
However, software engineering is highly contextual. Domain constraints, compliance requirements, agreements with stakeholders, team size and structure, availability of knowledge and skills, software criticality, and technical complexity are examples of the context that affects which practices are suitable for a development team. Context varies not only across organizations but even within the same organization.
Beyond contextual differences, software engineering occurs within a complex adaptive system. The complexity comes from the people and their knowledge, skills, and personalities that must come together to build software systems. It also comes from the processes and supporting tools. Emergent behaviors may also arise from the interactions between people, tools, and methods. A change, whether changing the people on the team, deploying a new or upgraded tool, or attempting to improve a process or workflow, may have unknown and unintended consequences. Adaptivity stems from people learning from feedback, self-organizing, and changing themselves and other system elements.
Despite these factors, there are still ways to find practices that make teams effective.
The Just Sharing Principle is a starting point. Sharing anecdotes about a practice or set of interrelated practices that worked for one team, along with the context in which that team operated, can help start the conversation. However, these anecdotes are not recommendations, suggestions, or promises that the practices described will solve problems. Even though they worked for one team in one setting, it does not mean they will have broad applicability across all settings. These anecdotes do not have to be positive, and sharing practices that do not work and their failure modes can be just as helpful. Practicing the Just Sharing Principle can encourage continuous learning and improvement throughout the software engineering community.
The Just Sharing Principle takes many forms. Individuals share their experiences and practices at meetups and conferences, some of which are held virtually or have recordings posted publicly after the event, or by writing posts and articles. Online communities of interest, such as the Stack Exchange network, Reddit, and DEV, unite learners and experts. Companies establish communities of practice and centers of excellence to bring together internal experts from across the organization. The shared practices can also serve as the basis for research, as academics and researchers study them to understand real-world observations and identify underlying principles, then publish their results at conferences or in peer-reviewed journals.
As practices are shared, patterns emerge. Once there is evidence that a practice is effective in various contexts, it may become a good practice. Practices such as test-driven development, trunk-based development, refactoring, continuous delivery, and mob (or ensemble) programming have emerged as some of these good practices, starting with a small number of teams and gaining widespread acceptance. When teams face a problem or desire to improve, they can compare their practices with these known good practices and decide how to change their methods to adopt them. However, practices don’t stand in isolation, and two or more practices are often related. For example, trunk-based development requires version control, and effective trunk-based development is enabled by automated testing, as well as to some extent, test-driven development. However, sometimes good practices offer alternatives or conflict with each other, such as pull requests and pair or mob programming.
As teams develop their practices, they can turn to standardized work. Unlike best practices, which aim to offer universal truths about the best way to work, standardized work captures a team or organization’s best-known and demonstrated method for doing work, based on their context. The defined standardized work changes as the context changes and the team evaluates their practices. In lean methods, standardized work is a cornerstone of continuous improvement. The practices and lessons learned can start a new iteration of sharing and help identify good practices for other teams to build standardized work within their contexts.
Although finding best practices in software engineering may be impossible, we can share and discuss good practices to become more efficient and effective at building high-quality software systems.
Leave a Reply