How many times have you looked at someone’s code and stated:
I’m not using this because it doesn’t look well-written.
And in this case, “look well-written” might either be a substitute for:
- “look like how I would write it,”
- “seem to make sense to me.”
Sure – there are times where using open source code is risky. We know this from the various software and services that show up with vulnerabilities. But, at least for this post, treat those as the exception – not the rule.
This means we’re left with looking at something we may use but opt not to use because it doesn’t seem to be written in a way that we think it should be written.
Prioritizing Peers Over Users
Development is tricky because there are several tradeoffs that we – or another developer – have to make whenever they are building something.
Looking Inside Out
We have to consider:
- constraints of time and budget,
- what paradigm will help us deliver a solid within said constraints,
- does the final solution truly solve the core problem,
- will there be maintenance costs associated with how we’ve put something together?
And the list could go on.
Considering the various aspects of development and debating the philosophies of how something should be built is not at all uncommon in our industry
But it’s also a time-consuming, and it may prove to be an exercise that yields a net zero result because nothing comes of it. (Yes, it can often be a learning experience, but not always.)
Looking Outside In
Practically speaking though:
- Does the paradigm use to build the solution impact your use of the software?
- Does the software in question solve the problem?
- If you weren’t able to see how the project was assembled, what conclusion would you draw about the software?
And the last point may be the most critical as it relates to open source software.
I’ve worked in the industry long enough to know that often people want a functional solution that solves their problem and they assume it’s securely built.
Developers, on the other hand, will scrutinize the code more than the solution it provides and the problem it solves.
If you’re a developer, there’s absolutely a time and a place for both. But if you let the latter prevent you from shipping the former, then you may never get something out for others to use because you’re too concerned about what your peers may think.
And when you’re solving a problem for other people, they should be the one who matters more than your peers.