That said, we're currently focused on helping people build apps without code, so classic source control methods like git are not part of those near-term plans. There's some richer background on that in this discussion if you're interested in going deeper.
Empowering our users is a REALLY good idea, but the problem is I've had management tell me a few times that I need to learn how to write "code" with these platforms; and honestly, the experience has been highly frustrating. I've had situations where people have told me to write solutions in SharePoint, Power BI or Power Apps when it would be easier and cleaner to use C#/(Classic MVC) and/or SQL Server Reporting Services. That doesn't even begin to address the high potential cost of these user written apps.
Anyway, I applaud Microsoft for trying to make software development easier. I think most "professionals" and business people (even developers) want that, but I still find Power Apps a royal pain to use with a lack of perceived flexibility.
One simple thing Microsoft could do to make this better would be to improve the "code editor" that you use inside PowerApps events. For example, when I try to edit the OnSelect Action of a Button in PowerApps, I'm given this tiny little window to work with. For the kinds of solutions my institution needs, we are going to have to write more than a few lines of code for each action. Over time, this large volume of business rules is going to create a bunch of O365 Spaghetti Code that is very difficult to debug. To make matters worse, we will be stuck without a "debugger" and we will have to edit our code through tiny little "windows"...
Another thing Microsoft could do is maybe offer a client side tool for "development". The online editor is a bit sluggish in my personal opinion even when I'm onsite at the office.
Lastly, farming out Power BI scripting logic to Power Apps may be a simple solution for Microsoft, but it's a pain in the neck for me. While I think Power BI is a reasonably decent product, I'm not a fan of Power Apps. I need a way to call a parameterized REST API from a Slicer Visual on Power BI. R Visual's for Power BI don't tend to do GUI Input so well IMO and I haven't looked at Python yet. I don't really want to mess with writing a JavaScript/ECMAScript custom visual because that's likely going to involve notable work and I'm not a fan of JavaScript anyway. This leaves me with either ditching Power BI altogether and using a Charts.js / MVC or .NET Core [1] type solution with Charts.js just for the rendering or trying to go with a Power Apps solution to call the REST API from inside a Power BI Report. None of these seem easy to me and I ultimately went with Charts.js and .NET Core for reports that use parameterized REST Queries. I use straight Power BI for the "easy stuff" (Non-Parameterized Queries) but wound up doing .NET Core for the situations where the data volume is really high and there seems to be a need for be notable processing on the backend before the data gets to Power BI. Ideally, a Power BI Service report would allow me to easily pass parameters to a backend stored procedure or REST API, but from what I can tell, Power BI doesn't support that too well yet. Instead, Power BI wants you to import massive amounts of data into the system and then do the processing with DAX. I suppose Power BI Direct Query might improve this some, but I still need a good way to pass parameters to stored procedures or a REST API.
BTW: Forgive me if I'm wrong on any of this. I'm just stating my frustration with getting quality non-trivial user focused "apps" out to the user given the tools built into the O365 subscription that my institution provides me.
[1] - SQL Server Reporting Services is another pretty easy option for visualization that is reasonably clean.
