Adaptation in software development processes: Learn, detach and transcend.

In the world of building software, best practices are considered a field-proven technique for solving a known problem. They should be a guide. A mechanism that sets boundaries and establishes clear roles, process and measurements. As software professionals, we want these processes, practices and methodologies to tell us how to get big teams to work together effectively, how to measure (and report) progress and how to collectively deliver great quality software. This sounds right, however, best practices should not be used as a prescriptive, singular approach. At some point, every problem becomes unique and common sense offers additional value.

Voltaire famously said in 1764 that “Common sense is not so common”. This just indicates that we can’t rely on common sense to make decisions as perspectives are not always shared. Instead, we should foster a shared understanding, a consensus on a position and perception which allows groups of people to reach the same conclusion.

Looking at the two concepts, there is a clear relationship. It seems that we go about creating and documenting practices in this endless desire to pen down common sense, to articulate things that we often feel are obvious with retrospect, the Agile revolution is a stand-out example of this. Perhaps the real goal is to know how to sequence and blend practices to service a specific software development scenario - a cocktail of experience, maturity, structure, influence and intent.

I’m regularly confronted by frustrated software engineers who are baffled by the seeming absence of common sense being applied in their development environments. The frustration of engineers and development managers share an interesting degree of overlap. The developer is confused at either the lack or excess of process, and the development manager is frustrated at the lack of adoption of the processes, or the uncertainty of which process to use. Dealing with these situations takes some insight.

I like to think of best practices, or strict methodologies as a set of rules to get you going. First we need to learn and master these rules and their application, this is experience, thereafter we can experiment. An opinion with experience carries a lot more weight. People aren't naturally good at using common sense in complex and quickly developing areas, so it feels intuitive to start with a documented approach, and not rely on our own individual sense.

Intention is also important. Identify the actual objective of the practice. For example, a strict process that govern changes to a software product could feel encumbered and unnecessary, but the intention is to protect the company and the users, which makes sense. In this example my argument would be to first master the process, and prove beyond a doubt that you’re capable of adhering to it, and then start a process of change from your position of proven knowledge.

With the application of experience and mastery, we can know when and how to break, or evolve, the rules to better suit the people, the product or the objectives. This is the ‘common sense’ many will rush to claim prematurely.

Given this understanding, it stands to reason that industries current set of best practices are the combination of experience from experts who have come before us, but also that once we reach a level of experience and mastery, our own common sense can inspire adaptation.

There is a Japanese martial arts concept called ‘Shuhari’ which roughly translates to “first learn, then detach, and finally transcend” which is an enlightening approach to developing best practice that is relevant every time.

At Entelect we’re constantly selecting, applying and measuring development practices to find what works. As engineers, processes are important to us and the development of rules helps streamline problem-solving to some degree. But that doesn’t mean we operate SCRUM by-the-book on every project. Every problem really is unique, mostly because of the people! Part of successfully applying best practice requires establishing a consensus on a position and perception between development managers and engineers. At which point, the team can ‘learn, detach and transcend’ and the resulting application of common sense can add real value to best practice solutions.