Transition from .Net to OutSystems: the first steps

Transition from .Net to OutSystems: the first steps

After reading the report from Justin James at Tech Republic at
I thought it might be a great idea to get the overall community opinion on:

1. What are the first 10 things we need to tell a .Net developer so that he or she "clicks" into OutSystems easily?

2. Are the 10 top pitfalls or mistakes one does when first experimenting with OutSystems coming from a .Net experience?

3. What are the wow! moments while exploring the Agile Platform, that we say "this is really cool"?

Let me know your opinion!

One possible pitfall:

Most developers coming from the .Net world are used to work with webforms, so they are used to not be able to easily test screens and screen actions, even if they are working in a Model-View Presenter architecture.

But for the rest of the code, they can easily use Visual Studio's support or some kind of framework like NUnit to easily automate unit tests.

That's something that they will not get with the platform.

Then there are somethings that might not be immediately visible. How to add files to an eSpace might be something that is not obvious how to do, and the text-based OmlResources doesn't seem to fit so well with the rest of the visual development tools.

Wow effects: The number of ready to use solutions in the community through the components is the best. ECT, is also great. And the easiness of user management through Enterprise Manager.
André, these are great comments. Thanks.
Do you remember when you started with OutSystems?
What where the specific things you had to understand that are different from .net and which allowed you to proceed?
What about the rest of you?

When I first started with OutSystems, bumped into the following problems:

1 - Edit record having a variable of its own and not affecting the variable it is bound to. This goes against the explicit bindings found in .NET.

2 - Lack of inheritance... Actually, lack of polymorphism. Having to duplicate actions just because they handled different input types (e.g.: Structures) knocked me out. I felt I was duplicating code all over (and was).

3 - Lack of constants or enums to avoid having strings all over.

4 - General lack of power in Service Studio to organize stuff. I was used to think in semantic groups of elements handling the same kind of functionality, and Service Studio wouldn't allow me to place those Screens, Actions, Entities, etc, closed together. Eventually, I found the Add/Remove References and start splitting stuff per different eSpaces, but then I also had no packages or a similar feature to have my artifacts in the form "<eSpace Name>.<Element Name>' when using them.

5 - Having visibility of the datamodel right in the UI level. This felt "dirty". We are driven in school to create abstraction layers so that changes in the internals of one layer won't break other layers. Everything is exposed in OutSystems and there was no obvious way of avoiding this without higher effort than in .NET.

About topic 1, after one discovers how it works, it is simple and not problematic. About topics 2, 3, 4 and 5, I had to "resign" myself to the lack of such functionality and felt going back in terms of engineering. Topics 3 and 4 can be easily solved. Topics 2 and 5, I feel it hard to explain easily and think it will need the "resignation" I mentioned from .NET developers. I understand it avoids dialects, facilitates knowledge transfer, and forces things to be implemented plain vanilla, but explaining this to a newcomer is a challenge. The TrueChange engine that justifies why topic 5 is not a problem, must also be explained to .NET developers since it breaks their best practices rules.

For the reference, I followed no tutorial nor training to start developing with OutSystems. Just got passed the installation (with some problems at the time), opened Service Studio, and started playing around. The new training addresses topic 1 already. Don't know if the old one did.
>> For the reference, I followed no tutorial nor training to start developing with OutSystems. Just got
>> passed the installation (with some problems at the time), opened Service Studio, and started
>> playing around. The new training addresses topic 1 already. Don't know if the old one did.

Related to the training topic: I don't think it's as easy as it was before the 4.2 release to make self-training, as we don't have the express edition with the very easy to install solution that came bundled with the xsp web server. It was a great "starter kit".
Hi there!

Interesting topic ;-)
I have to agree with Rodrigo on the lack of some OO concepts like polymorphism and inheritance. The duplicate code is a true 'bad smell'.

Starting with the pitfalls, here are some other items I found (and some still find) worrying.

1. Copy - paste - modify
The Style Guide, and thus the OutSystems way of working, is all about copy - paste - modify elements from that Style Guide. Every .NET developer knows that this is bad way of reusing code. A true model that supports inheritance (also visual inheritance) and polymorphism would eliminate this.
I furthermore think that it could lead to quite a mess within you application if you have not removed all unwanted elements from the stuff you have copied. Within the maintenance phase of an application this could lead to confusion.
Maybe it would be better if the Style Guide would offer both the working screens and a set of stripped screens without any functionality but with a set of guide lines on how to build the functionality that was ones on that screen.

2. Keyboard shortcuts and IDE usability
As a .NET developer I was annoyed that the F5 key was publishing my eSpace instead of just running it. I'm pretty sure more .NET developers ran into this issue.
A bit more on this topic... I have learned to work pretty fast with keyboard shortcuts in .NET for navigating through the IDE. Yes, OutSystems is a visual development environment, but so is .NET. I found it pretty annoying that I had to do everything by mouse instead of using the keyboard. It did bring up some old RSI issues with me. So if you are looking for .NET developers transitioning into OutSystems, please provide the flexibility for different keyboard mappings.

3. Build what needs to be build
When eSpaces grow, the time it takes to run your eSpace increases too. One of the main things contributing to this is the verify and building process. These processes are surely candidates for improving. If, e.g. I only adjust the contents of a query there is absolutely no need for verifying the entire eSpace again. Restructuring my action flow (repositioning actions etc) is also one of them. If OutSystems claims to be quick in speed in development, please improve these things. Surely you know .NET does have that intelligence for only building that peace of code that has changed and leaving everything else as it is.

But what to tell .NET developers to make 'm interested in OutSystems? This is difficult. Basically because professional .NET developers are truely about coding and patterns and refactoring and fancy libraries and cool techniques and new coding technology like (P)LINQ. In one of my presentations on OutSystems I gave for colleagues, someone addressed OutSystems as 'He, Access is back!'. Yes, in some point it is 'Microsoft Access for web development' and yes I know it is way more than that! But it does show how true developers (who dream in code, patterns and architecture) think about drag 'n drop, think about these generators. So how do you get them 'over the line'?
Maybe by convincing them that application development is shifting more and more from coding to modelling. Even in the .NET world you see that developers are working with more and more designers in the IDE (e.g. class designer, the workflow designer, ...). It abstracts them from the 'basic code' to the real business problem. And so does OutSystems work. It abstracts the basic and dull code from the developer and enables true business development.
Another helpfull thing is having some people that other developers look up to 'spreading the word'. If they are enthusiastic, may be they can inspire people to 'cross that line' too.

To sum up 10 bullets to help .NET developers cross the line is difficult. I was brought to an OutSystems project by luck ;-) and found through experience the true power of the platform. For those developers who weren't so lucky I think lobbying is the issue. Keep pushing the information, keep giving presentations and short demos, keep informing them on the power of abstracting dull and boring code.

As for my 'wow' moments, I think the Ajax stuff is very cool and easy to use, the power of the visual 'If' widget which doesn't exist in .NET and most of all ServiceCenter. This tool gives you so much information 'out of the box', nothing can compete with that!

Finally, I'm wondering why you are targeting at the .NET community only. I understand the .NET thing because of the integration capabilities in Integration Studio. But there is still a whole world of VB programmers out there that may find the step from VB to the Object Oriented world of .NET still very difficult. They would be a very suitable group of OutSystems developers.
First wow moment for me was the big picture of the Agile Platform, the way all things combine together to ease the work of getting an application live, monitoring with Service Center, driving change with ECT, extending functionally with Integration Studio. This is really cool!

When I started to mess around with Service Studio my coding euphoria started as well. Everything was so easy to try with a lot of out-of-the-box things like sms, excel integration, easy email sending. I found that the OutSystems community was a really nice experience as well, people really helped each other out posting clues, samples, components.
This was the second wow effect.

After this first euphoria phase I started to bump on the platform limitations. Everybody wanted to put webblocks inside tablerecords and other webblocks right? I also was struggling to find a MasterPage pattern with no success. As already posted here the lack of OO principles like polymorphism and inheritance can probably be one the strongest objections from .Net developers. Fortunately we can still apply design patterns like Model-View-Controller, etc.

When I started to work on OutSystems I had came from a bad experience in the waterfall methodology. I'd spent months designing a system, a whole load of classes and interfaces and libraries, really good looking stuff but that never really saw the light of day and was constantly outdated in terms of functionality. This experience was in Java but the same principles apply if it was a .Net project.
I think that what really clicked me into OutSystems was the quickness of results, good results.

So how can we convince these developers? Here are my pointers:

1 - OutSystems development is not .Net development. It's a whole new experience.
2 - OutSystems development is very intuitive and easy to learn.
3 - Because it allows quick results it's very addictive and allows you to test your limits.
4 - "I'm not that into user interfaces, I really like server side programming". (I think these are the hardest developers to conquer) OutSystems platform is end-to-end and although it's sometimes difficult to separate user interface from server-side code from data model it is possible to do so. On the other hand OutSystems has the Styleguide that speeds up the user interface development with great results. The ajax widgets are definitely a plus in this matter.

Glad to add my contribution,
These are all great comments. However, the point is that our community is growing by leaps and bounds, we are facing thousands of trials per month and a lot of the questions we are getting are from individuals who have previous experience in other development environments. One of the most common is .Net.

So, what I am looking is not things to improve _ thanks for the feedback, anyway, R&D is all over this feedback.

What I am interested in are the little things that you had to change inside your brain in those initial hours when you were discovering Service Studio and the Agile Platform.

Think about the following: if you had to seat besides a newby colleague (that has .Net experience) mentoring him or her on how to use Service Studio how would would you guide him or her ? What are the things you would explain leveraging the knowledge that you two both share about .Net?

Assuming a store and retrieve application, with a bit of Ajax flair, the main differences I've found when moving from .Net to OutSystems were:
  • Development Paradigm: A major difference is the way you think about the application's architecture. In .Net you start by designing or adapting an architecture or framework. In OutSystems the framework is already there, and the the architectural decisions are basically centered on the data-model and how the application will be split. This means you swiftly move to implementing the application, rather than building a new or learning an existing framework. Cleanup and reuse is done when needed, as the application evolves and grows. OutSystems does have constraints on the way you can do abstractions and reuse, in particular when compared with Net. The good news is that these limitations make understanding and changing applications made by other developers a lot easier than traditional code.
  • Control Databinding: In .Net, control databinding is done either by manually assigning the value of an expression to the control property or by using a datasource. From that moment onward, reads and writes are made directly to the control. In the Agile Platform you don't write directly to the control. Instead, you set the binding between the control and the variable, and you only change the variable.
  • Databind events: Databind in .Net is explicit, i.e. the programmer defines when the databinding occurs and can intercept and customize this event on the controls. In the Agile Platform databinding is implicit and has a well defined behavior. The drawback of the OutSystems approach is the loss of control, the good news is that understanding and changing the application is much easier, since there is no need to check all customized behaviors or fear side effects on changing the application.
  • Validations: In .Net input validation is made by attaching one or more Validators to an input control. The Validators are responsible for checking the input value and, during a postback, you can check if the Page is valid and take action. On the Agile Platform the control itself (e.g. the input) stores information regarding if it is valid or not, and is responsible for showing the validation message. This validation can be made either automatically or in the business logic. The Agile Platform allows and promotes grouping inputs in Edit Records, allowing to check only parts of the page. The main drawback of the OutSystems approach is that you cannot attach multiple Validators to an input. On the other hand, the input validation near the business logic and the fact that validation messages move with the inputs, make understanding and changing the application easier.
  • The Database: .Net gives great relevance to the database, and has some recent technologies that bring the database closer to the code, like LINQ. Nonetheless, the database is still very much detached from the application resulting in some grieve during the definition, configuration, usage and change of the database. In OutSystems, the database is totally integrated with the application, making the configuration step unnecessary, and defining, using, deploying, or changing the database very easy.
  • State maintenance: The postback architecture in .Net relies on the viewstate to maintain state across requests. For controls, the viewstate is managed automatically. If there's something outside the controls that needs to be stored, it is up to the developer to do it. In the Agile Platform , whatever is defined on the page can be accessed by the developer during a postback and all state maintenance is automatic. This can be a bit scary for experienced developers that know that the viewstate can be major performance problem, but the Platform has some very smart rules to optimize the viewstate.
  • Sessions: A session in .Net is essentially an object bag. Developers can add, remove, read, and write objects to and from that bag, although some care must be taken when working in farm environments. Also, in .Net there is a session per application, and you cannot share session information between applications. In the Agile Platform, you define what the session will contain upfront and, from that moment onward, you can read and write values from the session just like any other variables. This applies to single node or farm environments. Another major difference is that the session can be shared among applications that were configured to have this behavior.
  • Security: Security in .Net applications is usually made by editing a central configuration file, where a list of allowed and denied permissions for specific users or roles is set for a given resource. In OutSystems you define a set of permissions or privileges (e.g. permission to edit a customer) and grant a given user these permissions. Screen security is defined in the screen itself, instead of a configuration file, and there are built-in methods to check a user's permissions, to make it easy to customize page content depending on the users' grants. OutSystems provides an application to manage these permissions and roles.
  • Ajax: Ajax in .Net applications is usually made using the UpdatePanel control. The part of the page you want to dynamically refresh is then placed inside of the panel, and you refresh the panel to perform an Ajax refresh. In the Agile Platform you simply state that a request associated to a link or button is Ajax. You can then refresh individual parts of the screen without the need for an extra control. For list controls, like Table Records, you can even choose to refresh individual lines. The underlying architecture is also different. In .Net, an Ajax request behaves exactly as a regular request, recomputing and re-rendering the entire page. In contrast, the Agile Platform only calls the the Ajax action (i.e. skips the preparation) and only recomputes and re-renders what needs to be refreshed.

Hope this helps,

This is really a great topic and I think all this information will help each one of us to be more effective in overcoming the barriers of introducing the power of OutSystems to new developers.

I would like to share with you an idea that I discussed with Justin James when we had the session that led to this interview.

One of the first barriers he struggled with, was the adoption of this NEW visual paradigm based on images and WISIWIG versus the structured code and text logic ingrained in all of us.

This got me thinking of all the objections I had heard and forced me to pay more attention to some of the ones I heard recently like:
- Why can't I see the HTML behind a screen?
- I do not use a mouse to program (some of you mentioned having F5 do something different was annoying)
- Can you send me a manual or can I buy a book that teaches me how to use it?

I believe the one of the greatest barriers for developers is this shift in "Thinking" pattern that you have to go through, in order to start to like OutSystems.

In a way it is like that test with the colors (see ) where two different parts of your brain compete for either the actual color or the words. All the programmers that I know read the words! Maybe the issue is that we are appealing to the wrong side of the brain of our developers.

To all of this there is also the prejudice in thinking that all Visual programming techniques are limited for complex problems. I know myself how prejudiced I am against Mac’s, just because I cannot imagine how I could use a system with a single-button mouse.

I think that all the topics you mentioned are very technically valid and we will need to address them. Still I wonder part of the solution is not simply to give-in to the text paradigm and maybe:
- Create a code editor that represents screens where we could see the "text structure" of a screen and fine tune the little pieces we need. (This would simplify importing HTML for example).
- Allow a pseudo code edit of action’s logic for the people who prefer to think in "words" (thank you to Jon Barcellona for that idea).
- Also represent actions and entities by their procedural text and SQL definition.
- Use some standard way based on XML or any other standard to represent the flows of screens.

We are talking about barriers for a .Net developer or any other coders in adopting OutSystems as a DSL (domain specific language) and I am wondering if the reason for the barrier is NOT the Domain Specific part but REALLY the fact that developers have a hard time considering OutSystems as a coding Language.

Let’s keep up the good discussion!