If you’ve been online for a while, you may have seen this tweet.
This tweet is indicative of an attitude that is all too tempting; the way things work now is the best we can do! If it wasn’t, then that opportunity should have been picked up already! Oof. Nathaniel and I very much reject that premise.
Certainly, there are best practices that should be inherited from existing systems. But we should not rely on the passage of time for people to adopt these best practices. Instead, we should change how these best practices are implemented.
Others in our space keep the same implementation (the spreadsheet) and wonder why users continue to encounter the same errors and frustrations. Worried about fitting every use case, these tools overwhelm users with excessive optionality. These tools think little of their users while simultaneously asking the world of them and necessitating expertise.
We do the opposite. We think highly of our users and remove the distractions of excess optionality. We think that implementations can be changed and that paradigms can be shifted. Entrepreneurs have demonstrated time and time again that users are willing to shift paradigms for how they work if the implementation is familiar enough and simpler than the status quo. For instance, the iPhone overtook the BlackBerry despite concerns about lack of physical keyboard and the GUI overtook the command line despite concerns about limiting optionality. That’s why we’re able to add value that hasn’t already been implemented in a spreadsheet. We have a platform built around incremental changes to what power users already do, but packaged to make powerful usage straightforward and standardized.
Think of the intermodal shipping container or even the jerrycan. Before these inventions, the loading and unloading of goods and fuel was cumbersome, it required many steps, many tools, and boxes and containers of various sizes. The simplification of the break-bulk shipping to that of the shipping container enabled standardization and increased efficiency. Likewise, since TrovBase removes complexity and choice, data pipelines can be standardized, and thus can enjoy increased efficiency.
In this ambition, we are not alone. Now is the right time to build this because, among other reasons, this idea of standardization has already succeeded and is being extended. The scikit-learn
API has made machine learning vastly more accessible and inspired more functionality with the same design in packages such as pomegranate
. The R community's tidyverse
has its grammars of data manipulation and visualization, soon to be extended to modeling with all the work that has gone into tidymodels
. We are not replacing these but building on top of these, in the same way that the shipping container could only be standardized because even measurement and steel already was standardized.
TrovBase exists because we have the audacity to think that we can make things better by building something which we have a vision for. We are building in a space where the capability for such visions to displace existing practice has already been borne out, with the successes as inputs for us. That's why, each day, we get excited about it; we can add functionality, refine the user interface, address bugs in edge cases, and get more people on board. Whether it's for sociology research, pilots for marketing, security/privacy implementations for consulting, or teaching data methods from reshaping to graphing to statistical inference, we're building TrovBase to make users feel like it takes the capabilities of the present to their full potential, and thereby have them feel as excited using it as we are developing it.
Check out TrovBase here (we removed the wait list!).