SOLID principles for a solid business
Want your business to run like a well oiled machine? Learn from those who build them.
Business owners, managers, and operators alike spend countless hours striving for organizational excellence within their businesses. The ability to encourage continued growth organically through process, culture, and structure, is the key to creating a business that will survive economic waves and grow to astronomical heights.
Organizational excellence refers to ongoing efforts to establish an internal framework of standards and processes intended to engage and motivate employees to deliver products and services that fulfill customer requirements within business expectations.
— American Society for Quality (ASQ)
What many businesses don’t know is that the task of creating this excellence is assigned to both business operators as well as engineering leads. The only difference is that business operators structure and hire people and employees, while engineering leads structure and build software services.
It may not seem it at first, but there’s a lot that business operators can learn from the habits and practices of a well organized engineering team. Though they work with different raw materials, engineers and software architects spend their lives designing stable systems that will grow and scale to handle tremendous load. In doing so, they’ve created several principles that help refine their efforts, and in many cases those principles inadvertently translate seamlessly toward the operation of people instead of machines.
One such principle has been popularly referred to as S.O.L.I.D., and has been a driving influence in software development for well over a decade. This acronym is based on the “first five principles” published by Robert C. Martin in his book, Agile Software Development, Principles, Patterns, and Practices. These principles were defined so as to aid software developers in the creation of systems that would be easier to maintain and extend over time, and as it so happens they can provide the same benefits toward the operation of a business.
Though these principles were designed with a technical context in mind, many of them are quite easy to digest. I’ll be diving into each of the principles in greater depth as part of the impending 5 part series, but I’ll start by providing a brief overview of each principle and a taste of how it becomes relevant toward business operations:
Single responsibility
The single responsibility principle states that every class or module should have responsibility over a single function of an application, and that function should be completed in it’s entirety by said class.
This can be one of the more powerful principles when used correctly, and it’s benefits become clear simply by replacing the words module and class with the word role, indicating that the principle applies to each position available within your business.
Open/closed
The open/closed principle states that a class should be open for extension, but closed for modification. Adhering to this principle allows applications to continue to grow and evolve, but ensures that classes can also be depended on for stability over time.
The same values are easily translated to the roles within an organization. Ensuring that roles and teams can have responsibilities added to them is an important means of growth, but its just as important to ensure that the rest of the organization can depend on the continued completion of tasks and responsibilities the role already had.
Post coming November 17th, 2016
Liskov substitution
The Liskov substitution principle outlines the notion that subtypes of a class should be substitutable with their parents without altering any of the desirable functions of the program.
Adhering to this principle in operational practice ensures that tasks performed by a role can be completed the role’s manager and vice versa. This can be an important safety measure to ensure business continuity, especially for task-oriented positions in your organization.
Post coming December 1st, 2016
Interface segregation
The interface segregation principle states that no client should be forced to depend on methods it does not use, and the driving goal is to ensure that the responsibilities of classes are clear and concise. As software starts to take shape and classes get used by different parts of the application, it can get very hard to read through and determine what the responsibilities of a class really are.
The same conciseness is just as necessary when defining roles within your organization. Its exceedingly important for the responsibilities of teams and individuals to be easily understood by those managing them as well as other teams in the organization. Doing so vastly improves communication as it inherently alleviates role confusion.
Post coming December 15th, 2016
Dependency inversion
The dependency inversion principle refers to a specific form of decoupling software modules that inverts some of the traditional ways people thought about object oriented design. Rather than high level objects depending on low level ones, both high and low level objects should depend on abstractions.
For those of you familiar with larger organizations, the practice of this principle is comparable to the creation of a “middle-management” layer. Though it can sometimes seem like an unnecessary hurdle in a strung out organization, when done correctly it can become an important means of creating easily understood and functional communication channels.
Post coming January 5th, 2016
The interpretation of these principles and their translation to applicable business practices are my own, but the intention of sharing them is to provoke thoughts in others and encourage their continued development. The operational and cultural expectations in businesses are changing as the market demands a more talented workforce, and the influence of engineering practices can make great strides toward accommodating that change.