In the engineering industry, there are three things that govern the engineering process for every product everywhere. Whether you work on a smaller, mid-sized or enterprise systems you will inevitably run into one or several of these three categories or work with someone who fundamentally believes in them and practice them.

These categories are principles, patterns, and tools. An engineer anywhere must leverage some tools they personally built or were built by someone else to achieve a certain task. For example, a software engineer will use an IDE to write code. IDEs are tools built for a particular purpose and driven by certain patterns and principles.

This article is about outlining the difference between these three categories, and the importance of understanding that difference in order to be able to understand how the tech industry works, and how you can maximize your passion, prosperity and happiness while being a part of it.

Principles

Engineering principles are usually higher-level and intentionally slightly vague ideas that are meant to inspire much more specific and materialized concepts and patterns. For instance, a software engineering principle would be something like: “Use modern engineering practices”. It doesn’t specifically tell you which practices, neither would it tell you which tools to use to follow these very practices.

Principles in general are meant to play the role of a framework. They draw a very fine conceptual line around certain concepts and ideas. They are meant to govern the pattern of thinking for an engineer rather than governing how an engineer develops their software.

These principles are much, much more important than patterns and tools. Engineering teams that are not driven by specific principles are not immune to falling into chaotic patterns where the systems being developed don’t have any rhyme or reason. Engineering principles (when defined properly and agreed upon amongst engineering teams) can play a crucial role in guarding the engineering culture in any organization from producing an incohesive or inconsistent systems. Even if these very teams followed best practices and coding guidelines and standards down to the last minute of detail.

Engineering principles are certain beliefs that engineers carry at heart and apply continuously as they develop new or maintain older systems.

Over a decade ago, I was helping a customer build a massive enterprise system. Despite training engineering teams on following standardization and best practices, it seemed that some of the engineers involved in the project didn’t see the value in ensuring the system is always up to date with the latest and greatest libraries.

This pattern here shows very clearly that having best practices defined and tools available isn’t going to ensure that any given system will continue to live up to a certain level of quality and standardization. I decided to gather the team and discuss with them the importance of ensuring our systems is always up to date to avoid security issues. Working on instilling these values of proactivity and initiative is all about building a culture and a belief system that engineers could follow and respect.

The thing about engineering principles is that they don’t care about your experience in the industry. I’ve seen more dedicated, devoted, and loyal junior engineers than their counterparts on the senior level. In fact, junior engineers are much more likely to have the grit to continuously understand and learn and adhere to these principles than others. At least long enough before having their faith erased by chaotic engineering cultures.

Since principles are not a specific materialization of patterns or tools, they require continuous reminding, education, and learning. It’s faith-building activity that requires engineers to communicate further and discuss the meaning of these principles and whether they are applicable in certain situations or not. It’s quite rare on the internet to find as vicious arguments about engineering principles as much as you would see for certain patterns and certainly a lot less than the arguments around tooling and particular technologies.

Engineering teams that do not follow any particular principles or actively ignoring these principles can be subject to questioning their integrity and true ability to building serious systems that may cause harm if not built according to certain standards and principles.

Engineering teams should make it their top priority to seek, define and follow certain principles. Principles need to be documented, discussions should be recorded and regularly advocated for. Engineering teams should also assign preachers for these principles amongst themselves to go on studying these principles researching them and working within their teams and other teams to advocate these values.

Now, it’s also important to understand that engineering principles are also three different categories. There are principles that care about the core values of the team, some others are about team management and team dynamics, and the last one is about engineering itself. Let’s discuss those here.

Core Values

Core Values are the most generic of them all. They are generic enough that they may apply to even other professions outside of engineering. For instance, a core value is something like: “Alone you can go fast, but together you can go further” – a principle like this enforces the idea of team collaboration despite what may seem as a slow-down to the development.

Core Values are the most important of them all. They build the integrity and faith of the team. These values can be standardized and positive but can also be negative and chaotic. For instance, you may hear things like: “If it works, don’t fix it”. That’s an example of a chaotic core principle that encourages engineers to avoid continuously maintain and evolve the systems they build as long as “it works”.

Team Management

Management principles are more concerned with the processes that govern the team’s development. For instance, the Agile Manifesto is nothing but a collection of team management principles such as: “Businesspeople and developers must work together daily throughout the project.” This principle talks about collaboration between customers and engineers. Staying on the same page is extremely important to ensure the success of any software.

As is the case with other principles, the aforementioned doesn’t mention exactly what pattern to follow to ensure collaboration, neither does it specify tools to leverage to achieve said collaboration.

Operational/Engineering

The last of these types in engineering teams are the operational principles. You may have heard about some of them like: “Separation of concern” and “Single responsibility” and several others. These types of principles focus on the modularity and cleanliness of the systems being built. But they don’t necessarily point out any particular pattern or a tool to implement that very pattern.

Principles may influence each other – there are hybrid principles that may directly point out a particular practice or patterns and sometimes even tools – it all depends on the context and the target audience for every principle.

Principles in general are hard to change. They take a long time to adapt into patterns and materialize into tooling and therefore changing them could be quite harder than patterns and tools. Principles are also purposes spelled out. Their tight attachment to their purposes makes them quite harder to define and even harder to erase.

But Principles on their own don’t really make any visible impact in our world. They are developed to influence the spirit and trigger the mind to think about ways to adapt them and materialize them. Principles are usually certain ideas that inspires hope, prosperity and sometimes even anger to right a wrong or change a chaotic situation on the individual, organizational or global level.

When principles turn into beliefs, culture and a source of motivation, engineering scholars rush to turn them into patterns. Let’s talk about patterns in the software world here.

Patterns

Patterns are a more logical representation of a principle. For instance, if a principle says: “Engineering teams should be agile” a pattern that implements that would be the two-week sprint pattern. Or even mid-sprint shuffle of tasks pattern. All of these are simply just patterns that aims towards achieving agility for an engineering team. You can see how a principle tries to stay vague as of what this agility looks like, while the pattern tries to draw a narrower line without recommending any tools to apply these lines. 

For instance, in the above example, a pattern wouldn’t tell you to use a specific tool like Jira, DevOps or anything else.

Patterns live a lot shorter than their principles, but they certainly live much longer than the tools that materializes them. And just like principles, patterns can influence other patterns – for instance, Inversion of Control pattern in software engineering influences Dependency Injection pattern. Some patterns are nothing, but a collection of other patterns built on top of one another to fulfil a certain principle.

It’s also important to realize that not every pattern out there is standardized or influenced by any given principle. Some patterns are chaotic and rogue – they were merely made for mental entertainment – but they don’t fit into any system or have any actual usage anywhere other than computer science books. It’s important to be able to identify and recognize non-principled chaotic patterns in order to be able to protect teams, systems, and engineers from falling into adopting them and adhering to them.

Patterns also come in all different shapes and forms, they can be influenced by team principles, core values or simply just pure engineering principles. Patterns can also be influenced by other patterns and other principles but never by tools as the figure above shows – it’s a one-dimensional flow.

Patterns are also a step further towards the materialization of a principle or a purpose. They draw more materializable lines for engineers to be able to implement them in whichever tool they choose. For instance, a pattern like Dependency Injection is something that can be implemented in almost any programming language out there – it’s tool-agnostic intentionally so it can live longer than the tools that materialize it.

Let’s talk about the tools that brings principles and patterns into reality.

Tools

Tools are in essence the manifestation of patterns and principles. A simple IoC library like Castle Project allows software engineers to implement a pattern like dependency injection which enables them to fulfill a higher principle or purpose like building high-quality software.

Engineers early in their crafts may get too caught up with the tools. But as they grow more mature in their craft, they start seeing a bit more than just tools – they start seeing patterns and paradigms in code. You may witness some of that on social media every time you see an argument as to whether to use one programming language over another. Or maybe use one IDE over some other text editor and so on. These are all low-level arguments; they don’t fulfill any particular purpose and they don’t seek any specific pattern.

As we grow more mature in the engineering craft, we start seeing a much bigger picture. Principles, purposes, and people! We start realizing how important it is to employ what we build to bring more fulfillment to mankind, more evolution, and a guarantee of survival.

It’s quite important to understand the holistic cohesive vision of what we do on daily basis, especially for a craft as reaching and impactful as software engineering. We can’t spend the rest of our lives fighting over minuscule matters while our world and the big family of humanity needs every bit of our intelligence for its survival, evolution, and fulfillment.

With the rapid evolution of technology, understanding the principles, patterns and purposes that govern the tools that we build becomes more and more crucial – especially in the age of AI where tooling isn’t as simple as it used to be ten or twenty years ago. Embedding our core values, principles and noble purposes into these systems is our guarantee that it may not be used as a tool for devolution of mankind.

The Future

As software engineers, we carry a heavy responsibility in ensuring that the systems we develop are truly driven by our principles. This requires much more diligence in building engineering communities that clearly defines these principles, create corresponding patterns, and develop tools that apply these patterns to fulfill these principles.

The Standardization of software engineering is a great step towards that direction, but we still have a long way to go to ensure that those who follow The Standardization understand which patterns and principles it fulfills, and what purposes it’s trying to drive towards.

Software is a tool that can be used for both good and evil. Therefore it’s important for leaders, mentors and educators out there to embed higher values of goodness into the hearts of learners and followers to ensure software will not be misused.