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.
I’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 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.
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 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".
Like OOP, these have their place and can be useful. But, much more frequently we see developers making some really poor decisions about them.
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 Risk
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.)