I’ve been trying to identify the few basic ingredients that make a software product successful and I think I have the three points your future package cannot go without. These would be:
- some domain knowledge that will help you identify and address a real problem someone working in that domain has to face
- interface that is simple enough to be quickly understood by your future users
- internal system/software design that will render your future package robust, reliable and maintainable
These can be easily elaborated on. For example, the more domain knowledge, the more opportunity to see details others overlook. It is also important to see how to translate the given domain knowledge into an interface that’s simple yet enables various workflows that people might want to employ for their particular problem instances. Another interesting point is decomposing the original problem in a way that servers both the simplicity of the interface and flexibility of workflows.
My favourite example is the dplyr package. On one hand, it’s quite obvious that it follows the way SQL breaks down data processing (let’s call it ETL). On the other hand, there were numerous ETL-like functions available in R and a SQL-like ETL process could have been implemented in R even before dplyr. But the simplicity of the interface, consistency of concepts dplyr is based on, mapping the mental ideas onto specific APIs, all that made the package really popular and greatly contributes to its users’ productivity.
Anyway, even if these three point are not perfectly accurate or there are ways to make your software successful while violating them, that is what I would like to follow in my software development.