AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
3rd Mar 2017
Traditional vs visual programming; are they really that different?
Mendix is an all-encompassing development platform for business process solutions, and while it allows for the creation of Java actions, the majority of logic is built via visual programming in microflows. The ease of use and apparent simplicity often causes traditional programmers to view visual programming as weak and unworthy of their time. I’d like to challenge this view.
Good programming comes down to three main skills; solving a problem logically, implementing a solution efficiently and applying that implementation in an understandable and maintainable way. With these skills, one can learn to use essentially any programming language as many core concepts and standards are universal, with the main differences being in syntax (essentially a programming languages vocabulary). There are exceptions of course, one would not approach a procedural programming language in quite the same way as an object-oriented one but there are more similarities than differences. Visual programming, particularly in the case of Mendix microflows, simply eliminate, or at the very least lessen the need to learn a new syntax.
When it comes to the previously mentioned skills, Mendix microflows are no exception. The implementation is often slightly different in Mendix but the concepts remain identical.
Planning an implementation in Mendix is similar to planning an application in Object Oriented Programming (OOP). One of the first steps in OOP is identifying what objects will come into play, both tangible and intangible. For example with an expense claims application one can identify the users, such as a ‘Claimant, Approver and Payer’, and the actual components of a claim such as the overall claim, individual expense etc.
The next step is to identify what information on these objects needs to be stored, such as an expense description, price, date etc.
Finally what do these objects do? The user creates a claim, adds an expense to it, saves and submits the claim, an approver approves or rejects etc.
In OOP this is accomplished via the creation of classes, defining their variables and coding their methods. In Mendix this is accomplished by creating entities in the Domain Model and assigning attributes and creating the associated microflows.
So, what makes an implementation efficient? In the simplest of definitions, it is implementing the solution in the fewest actions possible. Whether these actions are lines of code or Action Activities is irrelevant. One’s understanding of a database is a separate skillset entirely that can have an even bigger impact on performance on a Mendix application, and if one knows when to pull from a database and when to commit they’re already on the right track for an efficient well performing application.
Efficient code doesn’t always refer to runtime efficiency, it can also refer to the developer’s time as well. In other words, efficient code is more maintainable. For example, a general rule I try to stick by as a programmer is to never copy/paste code. If a piece of code can be reused in multiple places, then it can be better served in a function to be recalled where needed. The main advantage to this is that if the logic ever needs to change, it only ever needs to be changed in one place. This applies to Mendix just the same, with sub microflows in place of functions. Similarly any time a piece of data is repeated, be it a common phrase such as a company name or motto, or an unchanging number such as the hours of a working day, it should be set to a constant. Again should this ever change (such as a company rebranding) there is one handy place to change it rather than having to search for every
single use of the phrase. Or should the application be licensed out, these constants can be changed quickly.
I started writing this blog post having already decided to conclude that Mendix isn’t likely to make you a better programmer, instead providing an environment in which a programmer can bring their skillset to the table and use and refine these skills in a way that would allow them to focus on other aspects of software development such as the actual development lifecycle, database efficiency and management, UX design and so much more.
However. Many days have passed since starting this blog, and claiming that in that time I haven’t picked up new skills from more experienced Mendix developers, or that I haven’t improved my logical problem solving and efficiency skills would be simply untrue. The truth is, the more I use Mendix the more the discrepancies between traditional and visual programming fade away, and I can instead focus on making good, efficient applications while appreciating the sped up workflow provided by Mendix’s many features.
Related Blogs
Drag