Simplicity vs. Transparency in Software Design

This letter is about a design challenge that I believe all products face over time: The tradeoff between simplicity (catering to beginners) and complexity (catering to experienced users): 

At Jovo, we're currently working on version 2 of our open source framework. The goal of v2 is to make it more modular and easier to extend for professionals. This, however, comes with a price: it might not be as easy to understand for new users, as it used to be.
 

How many decisions should I take away from the user?

Software design paradigms like convention over configuration focus heavily on reducing the number of decisions a user has to make to get started. This makes adoption very easy, but can lead to distrust when most of the magic happens under the hood.

With Jovo v1, we wanted to make it as easy as possible for developers to get started with voice apps. We took away many decisions from developers and stored them into default configurations deep in the core code. This resulted in a great initial user experience, but made it more difficult for professional teams to adapt the tools to their needs.

We try to solve this by giving our users easier access to certain configurations, and making it easier to add their own plugins to the framework without cluttering the code for beginners.
 

Complex does not mean complicated

We believe that you can cater to more experienced users while still being simple enough for new users by increasing transparency in the right places, in the right amounts.

People want to know what's going on under the hood, or at least know where to look to see what's happening. If, however, too much information is added, the software quickly seems complicated.