In December 2008, I wrote about OutSystems' Agile Platform. Since then, I took a much closer look at the IDE and actually used the system. I can now confirm that many of my first impressions of the Agile Platform were on the money. The Agile Platform tool is so good that I wish I had it 10 years ago.
A dream (basically) come true
A few years ago, I was discussing my "fantasy IDE" with someone, and the Agile Platform comes really close. For one thing, it uses a richer metaphor for code than source code. In addition, it treats an application as an ecosystem of data, actions, workflows, etc. rather than simply a collection of related files that may or may not refer to each other at the time of compilation.
Meeting with Miguel
In the process of learning how to use the system hands on, I spent half a day with Miguel Baltazar, the OutSystems Solutions Delivery Manager in the United States (the company is based in Portugal). Miguel and I discussed how various programmers react to the system, and he told me that the "hackers" -- the people who really like to have ultimate control over the code -- never really cotton to the system too much.
I can believe it; when I first sat down with the toolset, I was lost. I watched the tutorials, but I kept double-clicking the controls in my design and hoping to get to a code view of them. Instead, each double-click got me drilled down a bit deeper in the visual workflow designer (the Service Studio). This is not to say that you can't edit actual source code, but let's just say that you should not need to spend much time working on actual source code, and it is not the focus of the Agile Platform.
In fact, one thing that really stood out is that it is rather difficult to put together examples of the system because it is so visual; the vast majority of the resources that OutSystems provides are video tutorials. The video tutorials are exceptionally good; the software the company uses adds visual cues so that you understand what is being done with the mouse, and they zoom in when relevant. These are probably the best online training videos I've ever seen.
Some up-front frustrations...
I had some difficulties installing the tools on my Windows Vista machine. The development tools installed fine, but the servers were a bit less cooperative. After fiddling around, I was able to get them to work. Additionally, I found that some of the tools needed me to do Run as Administrator for them to work right. Miguel said they're aware that Windows Vista users have encountered a few issues, and it is being worked on.
Another minor problem I had was some confusion regarding the default password for the local server. Miguel made a note of that, and I bet they'll make that more clear in the future.
When I was with Miguel, we reviewed many typical scenarios of things I would do in ASP.NET, and he showed me how to do them with the Agile Platform. While I had tried to work with it on my own before my meeting with Miguel, I had a number of personal issues arise between the time I installed it and my meeting with Miguel, so unfortunately, I did not have much time to properly try to learn it.
We started with a simple example: When the user clicks the OK button, set a label's text equal to the text in a text box and add some validation and error messages. I had struggled with this on my own. Miguel showed me what I had been missing, which was the order that things were done and some terminology. I was looking to have code that forced the text value to change. The right way to do it is actually quite natural: You set the label to draw its value from an expression, and the expression operates on the text box. It's essentially a reversal of the logic I am used to because the value pulls from instead of being pushed to.
...quickly lead to victory
After that initial example, subsequent examples went much more smoothly. Within a few minutes, I felt confident enough to work on my own with Miguel giving me pointers. It only took a few minutes for me to "rewire" my brain to cooperate with the declarative, visual model of development. When I got rolling with it, I got better and better and, within a short period of time, I no longer felt frustrated. I actually began to really enjoy working with the system.
Miguel also showed me how to use the Integration Studio; this tool allows you to code up custom actions, expressions that are too complex for the Service Studio, and other tasks where you need more fine-grained control. It opens up Visual Studio and points it at some on-the-fly created code so it can take that code and bring it back in. Along the way, we worked with a Web service, and the system made short work of consuming a WSDL and creating the appropriate actions in the system.
Data models and control binding done right
One of my biggest gripes with ASP.NET is that the data binding really is too simplistic to be useful. To make matters worse, there are what feels like 54 layers over the DB now; stored procedures to views to ODBC to LINQ to ORM systems to Entity Framework... there is a ton of abstraction in the .NET data model now. It would not be so bad, but the developer needs to be involved at every step of the way. When I wrote about OutSystems in December 2008, a number of readers expressed concern and doubt about this end of the Agile Platform based on the fact that we've all been burned so many times by various tools that promised to make this easy.
The typical sequence for a data-driven "Hello World" application is something like this:
- Create a database, create a table, and create stored procedures (four per table at the very least for each CRUD action) for accessing the data. Maybe create a view or two along the way. Set security permissions so the only way to access the data is through the stored procedure.
- Create a database connection in your project.
- Create a data schema.
- Drag a data view onto the page and connect it to the schema.
- Drag a data set into the page and connect it to the data view.
- Connect the onscreen controls to the data set.
Add an ORM or entity system into the mix, and you'll end up with at least three more steps. All in all, you're looking at 15 - 30 minutes for a very basic data-driven app, and it gets rather complex if you want a master/detail system in there at some point.
In the Agile Platform, this is really quite simple. Here's where folks start getting edgy: The database design is out of your hands for the most part. You create entities and their relationships to each other, and the platform handles the implementation details. From there, you just hook onscreen controls to entities. Done, end of story. It takes less than five minutes to put together that same data-driven application and to have the master/detail view.
When I did this, it really blew my socks off. Of course, I was concerned about the DB design; then I remembered a few things. First, developers tend to not be great DBAs; their DB designs are adequate most of the time, if that. The tool's DB design isn't any worse (and is actually much better) than most of the developer-created DBs I've experienced. The other thing is this is all very standard work. It's not like you need anything super complex for probably 95% of data-driven applications anyway; you'll only need a dozen or two dozen tables unless you go absolutely insane with the relational DB concepts. So it's really not a big deal for the tool to generate the DB design and access anyway. Also, the generated SQL is pretty smart; it only pulls the data needed at any given time.
The data binding was really slick overall; it "knew" what data sources were available and appropriate (based on data types exposed) for each circumstance, and let me do exactly what I wanted. And "data sources" also included Web services. It was extremely easy to mix and match data bound controls that worked with databases and Web services.
More complex work
For work that is more complex than what the Service Studio allows, you can open up the Integration Studio and conjure up code as needed. And, if all else fails, you can do your work via a Web service and consume it within the Agile Platform.
One thing I really like is that Web services are treated like any of the built-in actions. This is a refreshing change of pace from my (admittedly limited) experience doing the same in Visual Studio. The last project I worked on in Visual Studio with Web services, I spent more time trying to figure out what was going wrong with my proxy helpers than I actually did writing the rest of the application.Find out about some miscellaneous items of note.
Justin James is the Lead Architect for Conigent.