OutSystemsDev Zone

This Is How OutSystems Decreases Development Risk

By omitting features, OutSystems decreases development risk. Yes, you read that right. To excise risk from the app delivery process, OutSystems, by design, has carefully excised parts of the development tool ecosystem. I’m going to tell you how that works. 

development risk developerI’ve Grown Accustomed to Your Workflow and Style

The languages that are most popular right now in the world of enterprise development are all C-style languages that support some form of object-oriented programming (OOP). In addition to these languages, developers have come to depend on a wide ecosystem of tools that support a fairly standardized process, from version control to continuous integration to deployment. Developers, especially experienced developers, have become quite accustomed to a particular workflow and style of doing things.

So, when these developers first take a look at OutSystems, they’re often quick to point out a lack of certain features. “You can’t bolt on external tools,” they say. Then, they mention that certain workflows and development processes are not possible. The more experienced the developers, the more vociferous they are on the topic. Ideas pop up regularly to address these “missing features,” and they often generate a fair amount of upvotes and discussion.

It’s About Compromise

All development systems are filled with compromises. OutSystems is a very “opinionated” development tool, with a very specific philosophy of why certain features should or should not be included in the platform. Many times, what someone sees as a “missing feature” is actually a deliberate decision based on the OutSystems design philosophy. What people are overlooking is that the “kitchen sink” development languages and tools that they are currently using are also filled with compromises.

The compromise OutSystems has explicitly made in their design philosophy is to reject features and techniques that some developers can use very well but that most developers tend to misuse, abuse, or not understand when someone else has used them. The objective is to remove as much development risk from the app delivery process as possible.

Let’s take a look at some of these “missing features” to understand why OutSystems has chosen to not implement them.

Code Branching

Code branching is great in a well-run development team, but in practice it is very easy for someone to branch on Monday with a Thursday deadline, make a ton of breaking changes to things, and no one on the team knows until Thursday morning when they merge and nothing works. The deployment gets delayed until the changes can be reconciled. By contrast, the OutSystems single-branch version control forces developers to coordinate breaking changes the moment they happen.

OOP

For every programmer who uses OOP sanely, there are a dozen developers who will start a long argument as they agonize over “should this be an interface or a class? Should this be a concrete class or an abstract class?” Or, they’ll build these disastrous mountains of objects and inheritance making every project look like a biological taxonomy chart.

Null Values

Null values are super useful. They are also one of the most common causes of bugs, right up there with automatic variable initialization:

"=" vs. "==" vs. "===" vs. "eq", and "not (0 or null) == true".

Recursive Structures

Like OOP, these have their place and can be useful. But, much more frequently we see developers making some really poor decisions about them.

Advanced SQL

The advanced SQL system makes it nearly impossible to directly access tables by name. Even if you know the names by reflecting the metamodel, the tool makes it deliberately hard to do this. This ensures that developers have to work super hard to accidentally destroy the database or create security problems.

eval(), Reflection, Callbacks, Delegates, Lambdas/Closures and Other Similar Techniques

As useful as these things are, they can create a true mess in a hurry. And, they make debugging and code maintenance substantially more difficult. As a former Perl slinger, I am all too familiar with “write once, edit never” code.

Deliberate Rejection Pays Off in Terms of Development Riskdevelopment risk

By deliberately rejecting these common techniques that you see in languages such as PHP, C#, Java, Ruby, JavaScript, etc., OutSystems has made a development tool that dramatically decreases the risk of development. Basically, I can hand this tool to someone who is less experienced and trust them to not accidentally create a SQL injection vulnerability in the search screen. But it does sometimes frustrate developers who are used to working with certain patterns like OOP.

High-Quality in a Hurry

And this is one of the things I love about OutSystems. Less experienced developers can use it to develop high-quality code in a hurry because it reduces the effort and time needed to understand existing code. But again, this is due in no small part because OutSystems made deliberate compromises to exclude certain language features and development tools. For me, this is an outstanding tradeoff and one that I have been happy to make. The companies I have worked with, who get a smaller quote and a less expensive project, have also been thrilled.

(Editor’s note: By the way, OutSystems also adds features that speed delivery while reducing development risk. Discover what they’re all about here.)

 

About the author

Justin James, OutSystems Customer at FICO and MVP

A veteran IT professional with experience in network engineering, systems administration, and programming and an OutSystems MVP, Justin specializes in OutSystems Platform, Web development, Windows Server, dynamic and functional programming languages, multithreading/parallel processing, regular expressions (regex), FreeBSD, Perl, VB.Net, and C#.

Comments

Michel Ozzello

One of the best examples of “decrease development risks” I had with the platform was way back in 2004 (on a very early version of the platform).

I was doing a project for a customer and realized I had implemented the solution in the wrong way, duplicating a lot of business logic and flows. So I decided to refactor the whole things, and basically deleted almost half of the business logic and screens, and rewired the whole thing in a couple of hours. When I was done, and corrected some errors caused by the massive pruning, the solution published without any issues and worked perfectly.

Looking back at the days when I used C++ and other lower level programming languages, I would have never done such a refactoring. I would probably have rewritten the whole thing from scratch to avoid breaking it entirely. But with OutSystems I felt I had this huge safety net under me that would not make me fall. And it didn’t!

Leave Your Comment