Software Principle 4: You can't have everything

Your time is limited, and because of this, you have limited things - whether that is money, achievement or in the case of software: features, documentation, tests, etc.  

You must pick what is important to you and work on that. This means choosing the most needed features, the most impactful tech debt, and the most critical tests.

Your time is limited, and because of this, you have limited things - whether that is money, achievement or in the case of software: features, documentation, tests, etc.  

You must pick what is important to you and work on that. This means choosing the most needed features, the most impactful tech debt, and the most critical tests.

As an organization, you can “purchase” time by hiring people to help work on these essential factors. However, this is not a panacea to the problem as obtaining time also creates problems. For example, there are best practices that work well at three developers on a team that falls apart at ten developers.  

It is caused by the amount of time you can spend on any given thing: if you have three developers and a massive backlog of features you can’t have one of them merely managing a caching system unless that is core to your business.  

For enterprise-sized teams, it’s normal to see entire teams dedicated to ensuring that the systems like caching surrounding the primary system are maintained and are in good health.  

Even at the scale of enterprises, with more time created by hiring thousands of people spread across more teams and people, you can’t have everything. At that point, time ceases to be the blocker and limiting factor, but rather coordination of that time and system complexity become the throttle point.  

Major refactors can take years because of system complexity and lack of knowledge about the system. Technical debt is usually significant, onerous and littered about the codebase; in addition to being prohibitive to getting work done.  

In many cases, there are several tests within the codebase, and it can take hours to build the system and test the changes.  

Knowing this, how does a person decide what is most important to work on first? Life is based on feelings and what that person values. It isn’t very measurable but usually clear to an individual what is important and what isn’t.  

In business, it gets murkier.  

As a business, you can decide which outcomes you desire: more revenue, more customers, more brand recognition, etc.  Once you have the desired result (s) identified, you can create measurements against those outcomes, and then an evaluation of each development activity is possible.

If positive brand recognition is your goal, bugs may rate higher than features as a buggy system can hurt your brand. These measurements provide some clarity, but it’s hard to pick what’s most important to a business.  

The leadership team must stack rank these outcomes and regularly ensure that they are reviewing them. Usually, the technical team is left out of this conversation but should be included to provide context to how they might achieve the outcome given their current systems and their state.  

Switching directions, in open source, how is the decision of what is most important made?  There are a few commonly used metrics: industry trends, community feedback and if the library or system is open sourced from a company, business needs. While the last one pertains to the measurement-based approach, the first two are a little different.

You can solve both with measurement by assessing the most critical trends and solving for those. However, industry trends shouldn’t always be followed nor does a community always know what it needs, just what it wants.

Ultimately, some factors can be measured as well for open source that would produce more desired outcomes: community adoption, contributor count growth, awareness, and feature completeness.

Metrics like this can help drive desired feedback from the community and provide focus to the contributors. There will always be off-metric contributions that can be weighed by the community and decided upon, but the metric provides a shared lens on those types of decisions.

Ensuring that we’re focused on the most important things will reduce waste, increase cohesion across teams and businesses, and maximizes value for users and stakeholders alike.  

Knowing you can only have a limited number of desired things at any given time creates a hunger to maximize the value and quality of the things we can have. This mentality will carry throughout your organization and generate a drive towards excellence and making do with what you have already – use that to your advantage.  


Build Thoughtful Software
March 8, 2019
Andrew Wolfe
Written by

Andrew Wolfe

Andrew has an M.S. in Computer Science from Georgia Tech University. But he prides himself over 10 years of experience working in the software industry for well-known companies such as Diebold, Tableau, Explorys, and Onshift. After years in the corporate and startup worlds as well as running his own consulting firm, Andrew realized he had to do more to improve software products and practices. From that, Skiplist was born. Skiplist is the opportunity to focus on thoughtful, quality software and change the software consulting industry.