Single and separated — the way responsibilities should be

This is the first article in the 5 part series, SOLID principles for a solid business. Over the course of this 5 part series, I’ll be diving into each of the S.O.L.I.D. principles, their roots, how they continue to impact software engineering, but most importantly how they translate to guidance for a well organized business.

What is Single Responsibility?

The Single Responsibility Principle (sometimes referred to as separation of responsibility) is the first of five key principles outlined in Robert C. Martin’s book, Agile Software Development, Principles, Patterns, and Practices. In the context of software development, the principle states that a module or class should only have responsibility over a single function performed by a software application, and that function should be encapsulated completely by said module.

A class should have only one reason to change.

The principle itself can seem simple at first, but it’s reduction to practice leaves much to be desired. With the application of the principle left up to the discretion of software architects and contributing developers, applications are often riddled with redundant code. More often than not, the reason for the difficulties of the principle in practice often lie with a mis-understanding as to why the principle is important. After all, it can be difficult to adhere so strictly to guidelines if a developer is unsure as to why they exist.

So why is single responsibility so important to the development of a lasting software application? How much could really go wrong if two or more modules performed the same task?

Problem Prevention

One of the general problems of spaghetti code or other unprincipled development styles is the latent danger that comes with unpredictability. It can be very easy to accidentally expose untested instruction paths through a software application, and any QA professional will be the first to tell you that end-users are experts in finding these holes.

The single responsibility principle isn’t the only way to ensure that these holes are minimized, but it is certainly provides a big bang for it’s buck toward preventing them. By taking this structured approach to software architecture, it becomes far easier to trace through a large application and understand exactly which class or module is responsible for which function. This traceability is a vital step toward trusting the stability of any new software release that developers put their names on.

In addition to the minimization of holes and improvements to release time trust, adherence to the single responsibility principle has extraordinary benefits if (and when) something does go wrong with your production application. No one likes to scramble to deal with fire drills that can cost your company thousands (if not millions) of dollars, and quickly identifying problematic code is crucial when every second counts. By ensuring that every class or module in your application has a single responsibility, it becomes that much easier to determine where infringing code may lie based on the problems shown in the system.

Team Efficiency

Problem prevention alone is a good enough reason to implement a principled approach to software architecture like Single Responsibility, but it certainly doesn’t hurt that this method can also aid in the ability for your team to effectively split up development work. Through the clear definition of application responsibility, it becomes exceedingly easy for development managers to break up and prioritize work amongst their team members.

Now that it’s been stated outright, the teamwork benefits of single responsibility may even seem obvious. Being able to split up work across your team seems strait-forward and practical, but as I said earlier the reduction to practice can lead applications horribly astray when mis-understood.

It’s nearly impossible for any single team member to maintain complete control or understanding of every module, class, or service in a large software application. As such, it’s not enough for a single manager or architect alone to understand the implementation vision for the single responsibility principle. In order to apply the principle and create a structured application, each team member must intrinsically understand the value of single responsibility so that they may share their efforts on system-wide modules and services. It is only through this communication and understanding that teams are able to leverage the single responsibility principle effectively.

Applications in business operations

Now that we’ve gone through the principle and it’s benefits in computing, we can start to make sense of how this principle can be applied to the successful operation of a business. When used effectively, the principle becomes a key part of achieving both of the above mentioned benefits — problem prevention and team efficiency.

The only remaining question is how does one leverage this principle to create a well organized business? To begin formulating this answer, let’s try to think through our own organization the way a software architect would:

1. What product(s) or service(s) does my company offer?
2. What tasks and responsibilities are involved with the production of each of our products and services individually?
3. What tasks or responsibilities are shared across multiple of our product or service offerings?
4. Do these tasks need to be broken down to smaller ones so it can be assigned to a single role?
5. How can these tasks and responsibilities be broken up to form unique roles within the organization such that no role shares the same responsibility?

The last item above is where the importance of the principle needs to be driven home in order to achieve its benefits. We’ve gone through what it means for a class or module in computing to have a single and encapsulated responsibility, but what does that mean for a business role within your organization?

Individual responsibilities are not shared between multiple roles

As your company grows, the needs for a task to be completed are bound to grow as well. Be sure to define your roles such that you simply hire more employees to fill it rather than assigning the responsibility to other roles in tandem. There should never be any confusion as to who is responsible for a given task, and roles that are too abstract are hard to hire for.

Example: If the responsibility of lead generation is assigned to marketing coordinators it should not also be assigned to business development managers.

Responsibilities can depend on the responsibilities of others

The one exception to the idea of single assignment described above is the ability for a responsibility to depend on responsibilities assigned to others. This is especially important for broader responsibilities that are common in management roles.

Example: A CTO is responsible for the creation and maintenance of company technology, but that responsibility is dependent on development responsibilities assigned to software engineers within the organization.

The application of the Single Responsibility Principle can be a great first step toward the operation of a wildly successful and organic business, but the real success comes with the reduction of all S.O.L.I.D. principles to business practice.

Stay tuned for the follow-up post on the Open/Closed principle and how it too provides unique and empowering guidance for business owners and engineers alike.