A huge part of effective software development in 2017 is effectively choosing tools and services to bring into a project. Any sufficiently complicated project should make use of other peoples' code. There are so many great open source projects and a growing number of wonderful commercial software products available, and being skilled at effectively relying on the work of others is critical. This an acknowledgement of tendencies I have observed and some suggestions for taking on a more systematic approach.

We are only human and we often ourselves relying on the wrong heuristics for choosing the right dependencies. Sometimes the choice is obvious and simple, but we often make decisions too quickly based on the wrong cues. There are a lot of signals at play, but most likely to steer us off course is an expectation of great design and effective marketing for every project. The skills and dedication needed to create great software do not go hand-in-hand with design and marketing skills, and because a lot of great software is developed by individuals, for free, it is often silly to rely on these signals.

I have a feeling that more experienced developers, especially those around before the web got so beautiful, are less likely to fall into this trap, but everyone can use the reminder. A lot of great software is built by people with a terrible sense for design and marketing. There are a lot of databases with better logos and websites than SQLite, but you are not going to find a lot of software that has faced more challenges and been more relied on like that one has.

If you do release software for other developers, it is worth embracing the importance of design to the best of your abilities. For better or worse, people do take this stuff into account. But if you are searching for software, it pays to acknowledge the lack of correlation between aesthetics and quality of software. Use it when the project is about design or marketing, and perhaps as a subtle cue for how much the developer cares about the project. It is ultimately about having empathy for the skill sets of other developers. Left to unconscious bias, design and marketing will play too big a role in your decisions.

Sites like GitHub and and package registry sites the npmjs.org help by creating some uniformity, but it is still on the searcher to dig past the presentation layer and choose software for the right reasons. So what are the right reasons? Of course, it depends, but if we have a solid checklist of questions to ask when evaluating a project, we are less likely to rely too heavily on false cues.

Here are some questions we might ask

Do the features fit our needs now and in the future?

Does it lock us into making other choices we might regret in the future?

Are we confident in the project's dependencies?

Do we trust the direction of the project

Is the project stable?

Is the project overly ambitious?

Are the maintainers dedicated to the project now?

Are the maintainers organized?

Are the maintainers good communicators?

Does the project have (or will have) enough traction to keep the maintainers motivated in the future?

The spirit of these questions applies to free open source as well as commercial software. In any case, we can never truly know the answers, but making quick judgments instead of taking extra time to evaluate projects on deeper merits is something to avoid. Every dependency we take on is an implicit partnership we are taking on. If we do deeper research and meditate on our choices, we will take on better dependencies and build better software.