Software Principle #8: Buying is Focus

There is a common thought in entrepreneur circles that greatness isn’t defined by what you say yes to, but what you say no to. This rings true in many domains but in software it can become a way of life.

In software, the build vs buy challenge is fraught with strong opinions either way.

There are a lot of incredibly smart engineers that can build almost anything given the right resources. But you should always ask yourself: is this the most valuable thing to build today?

Building something just to build it is the mediocre way of inheriting complexity. Buying off the shelf components or adopting an open source framework and using those in our architectures allows us to focus on the things that truly matter to software development in terms of the system and context.

Buy vs. Build

This is why buying is focus. How should we decide what to buy as it pertains to our particular system and context?

When building a system, the context you operate in dictates that it has certain core competencies. These core competencies are the reason customers purchase the system or people adopt the open source library.

Unfortunately, they tend not to exist yet or aren’t available for reference.

These typically are built by the developer or team of developers working on the system. There are other requirements built around these competencies required to make the system work; commodity features like sign-in, email, account management, etc.

These features tend to be the ones that should be purchased or lean heavily on an existing open source system — allowing developers to spend more time expanding and supporting on the core reason the system exists.

This work usually lands between the levels of scaffolding and core which is where technical debt occurs most often.

Core features are surrounded with tests to ensure the system doesn’t break and get the most attention to begin with; scaffolding is off the shelf libraries or components and are already tested and managed.

Ensure that these modules are treated with care, so it doesn’t become a source of pain for the developer or team.

As it pertains to the system, factors such as requirements, costs, ease of integration, completeness for potential future requirements, etc. play into buying a component. Some developers choose to not purchase a system because it does not meet every requirement that they have. If a component doesn’t meet every need, you can always wrap the third-party software using code controlled by the developer or team and extend it with your own features to solve for those requirements.

If this isn’t possible, it’s likely the component is hard to integrate and that should be a sign to look for another option.

Another reason systems are often bought instead of built is cost. Between the cost of development, support, hosting, and others associated with building software, it is usually more economical to purchase a component.

The biggest cost that might be incurred with purchasing is flexibility of the system. As mentioned in the context section, flexibility might be incredibly important for a particular component.

If it is required at some point, but the system can’t provide it, it can be expensive to replace. Although you should always earn your complexity, looking to the future when purchasing a component or using a library is wise.

Knowing system capabilities can assist in making decisions in the future. Systems also change, so you can watch how the component changed overtime to see if it is trending in a direction that you and your team desires.

Developer Concerns

In my experience, developers think buying or adopting libraries demonstrates a lack of capability. However, it should be considered the opposite: a show of focus on what’s truly important.

While there are trivial domains that exist in the world, focusing on most domains long enough will uncover complex problems that require deep thinking and work to solve.

When these problems are solved, real value is added to the world and to the lives of people around us.

If the developer or team is focused on building and supporting commodity components, they are not focused on the domain and thus will never reach these problems; missing an opportunity to improve the world.

Regards,

Andrew Wolfe, CEO @Skiplist

Originally posted on https://www.skiplist.com/