First Principle Thinking in Software Development

First principle thinking is the scientific questioning of various preconceived statements, which are generally assumed to be scientific. It does not assume preconceptions and biasness in its approach. It allows one to construct a solution bottoms-up, starting with the fundamental pieces.

For instance, there is a common conception that most people cannot afford electric cars as they are expensive. First principle thinking refutes this notion as battery of electric cars can be made from cost efficient resources.

Likewise, many budding entrepreneurs tend to believe that all the best start up ideas are taken. First principle challenges this biasness in concrete terms to give it a wider dimension. Many of the products that we hail as innovative today actually piggybacked on existing ideas.

The line of reasoning must be to “find the missing pieces” in the market to make an idea work.

What about first principle thinking in software engineering? The short answer is that we practice it often but in bits and pieces!

Modelling a complex problem in software is challenging. Software engineers have used Object oriented programming since 1960s. And guess what, first principle thinking in software development is based on object orientation. This object orientation encompasses the aspects of encapsulation, abstraction etc help us model parts of the real world. Other programming paradigms like functional and reactive programming also help us break a niche problem into simple building blocks.

Widely used machine learning and data mining algorithms have strong roots in Mathematics viz algebra, probability and optimisation. Although first principle thinking has its merits, software engineers have not fully benefitted from it for various reasons.

We are habituated to relating problems to something that we may have solved in the past. Software engineers tend to spend more time writing code, fixing bugs and less time on “think-time”.

Further, software systems employ well established architectural and design patterns which significantly reduces time-to-market. Libraries, frameworks and cloud-based solutions have been well designed to hide the internal complexities. All that’s needed is to utilize the right patterns, tools and software at the right places. Reasoning by analogy is fast, simple and ready to deploy!

Learning by example makes us prone to accept the status-quo and inhibits personal growth. So, how do we practice this line of thinking in software domain?

Many software companies hire engineers through technical interviews wherein candidates are asked to find suitable data structures and algorithms and design systems. Questions are designed to test candidates’ approach to “First principle thinking”. Solution starts from a broad purview, digging all the way down, and at each step, various trade-offs are discussed.

Peer discussions and design review meetings can effectively help us reason about the design choices and the associated trade-offs. Thought diversity in a team and the ability to dive deep will set an engineering team for success.

Root cause analysis (RCA) is another methodology wherein engineering teams have tried to reason about the cause of failure.

The 5 Whys unravel the mystery layer by layer.

However, there is a certain irony that exists. At places, we have blindly accepted and followed “First principle thinking” hidden in various disguises. And at other places, we overlook critical thinking in pursuit of economic goals. Layers of abstraction and pre-packaged software, lack of time for investigation and research, and information overload have not helped.

First principle thinking is about human curiosity creating “atomic” ideas, leading to creativity and innovation. To end it poetically, we must pause and smell the roses, ask the basic questions and simplify things!