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.
Top comments (3)
Great post, I particularly enjoyed;
One thing I would add to the list of things to consider. I've noticed a tendency for care to be taken at the start of a project, but as a project requires more and more dependencies the bar for caring seems to drop.
Sometimes it pays to consider if an additional dependency is required at all, a lot of gems and NPM packages I've seen are little more than 12 line helper methods, but when you already have 30 specified dependencies what is one more!
One thing I've done on longer running projects before is ask a more junior member of staff (who is well aware of the codebase) what each dependency does. Any they can't give a solid answer to should be evaluated for their usefulness.
Yeah. It sometimes goes in the other direction for me as well. Like, since the project has already been mostly written without dependencies, I won't even think to look for a good solution to the problem before unnecessarily doing it myself. If it's based on a pre-determined logic, that's one thing, but sometimes we just like to match previous patterns as an instinct.
In my experience, the ecosystems make up the developers mind most of the time. The Java ecosystem makes adding dependencies to a project cheap and very convenient. For example adding dependencies to a maven project is really simple but in most cases your maybe only using a small subset of that dependencies code and when you build a fat jar you end up wondering why it's 100mb plus. A rule I have found very useful recently is to favour libraries over frameworks. I know from experience I can back away from libraries much easier if that decision turns out to be a disaster.