I was recently talking with a friend about Mendix, specifically about the benefits of model-driven development and how easy it is to build applications through modeling instead of writing code. Being a hard core programmer, he was quite skeptical of the capabilities of model-driven development and my claim that new features can be implemented within minutes, not days or weeks.
When he didn’t believe me, I showed him data from external parties who have studied and reviewed the Mendix App Platform. Both Capgemini and Quantitative Software Management (QSM) have evaluated the platform. In the most recent evaluation, QSM analyzed application delivery speed in Mendix versus traditional development methods, and found that Mendix delivers a 6x productivity advantage.
Unfortunately, my friend was still skeptical, having never used the platform himself. We decided to challenge each other to a friendly race. What we found was awesome and I had to share.
We wanted to create something that would be quick to program in Java and allow us to compare notes – something simple that would not take hours to develop. We decided to build a BMI calculator and had another person time us and judge how we developed the application.
While my friend was writing and declaring his values at the beginning of the code (i.e. float height = 0 etc.), I was defining them on the Domain Modeler. What that means is that I was building the underlying variables and data structure.
In this example, we are calculating the BMI for a person. Therefore, we will have a PatientInfo Or Person entity and attributes to track the BMI information. We want to enter the patient weight, height, measurement type (such as kg versus lbs) and for this simple example, we’ll add the calculated BMI value within the same entity.
Mendix Domain Model versus Java declaration of variables
Figure 1 Domain Model Entity Called PatientInfo capturing all the information we need:
Figure 2 Java “equivalent” of defining the variables needed in the program:
While my friend was writing print statements for the users such as System.out.println(“Please enter your weight”), I was designing my UI and ‘Googling’ fun BMI graphs. With Mendix, you can design the user interface and display static or dynamic information to the end users by creating pages.
For this example, we would just need a simple page that allows the patients to enter their weight/height and choose the unit type. Then they can intuitively click on the “What’s my BMI?” button and a pop up of their BMI will appear.
Figure 3 Screenshot of what the users will see when they try to calculate their BMI:
The figure above shows the page that the user will see. What does the developer see? Almost the exact same thing.
Figure 4 Screenshot of the developer’s view within the Mendix Modeler:
In Java, when you have only a couple of minutes to develop, the best you can do for the users is have something like the interface below.
Figure 5 Screenshot of my friend’s Java print out:
The best part of development in Mendix – besides its intuitiveness – is the Microflow visualization. While my friend was busy writing all his calculations and troubleshooting for syntax errors, I was building my logic and visually seeing all the calculations I needed to do.
Figure 6 The Microflow behind the BMI calculation – when the user clicks on “What’s my BMI?” this Microflow is triggered:
The only code I really wrote was the calculation for BMI. And it was fairly simple, requiring one line of code:
The action above takes the patient’s weight and divides it by height squared (it also multiplies it by 703 if it’s in displayed in feet and inches).
It goes without saying that I won the competition, both in time taken to develop (2 minutes vs 10 minutes) and in the end result (a nice UI for users to enter their weight/height and calculate their BMI vs simple print statements).
In addition to speed, I had an easier approach to developing this application. While I focused on the business logic of the application, I was also spared a variety of traditional programming headaches.
For starters, I didn’t need to write any catch statements; the Business Modeler automatically checks if you enter an invalid value. The minute you define an attribute as an integer or float, it checks and gives an error if you try and enter a different value.
Figure 7 Out of the box functionality evaluating the data type integer making sure the user enters a valid integer:
Furthermore, I didn’t have to worry about syntax errors. The Modeler tells you if you are doing anything wrong or if anything is missing. Therefore, I could focus on solving the business problem. The beauty of Mendix is that you spend your time designing the solution and understanding the needs of the user instead of looking at lines of code and trying to decipher the logic or determine the syntactical errors.
I’ve managed to convince my friend – and I work with a variety of customers who are equally as impressed. But what do you think? Have you tried building apps through the Mendix model-driven development platform? If so, tell us what you’ve built! If not, why not start today? Run a test and see what’s possible for yourself.