Skip to main content

Low Code and No Code Platform == NOT with VISUAL Everything

It's interesting to read this article: The Evolution of Low-Code: Welcome to the Machine. The content is in my opinion just a marketing for Low Code Platform.

It is not true to say that the RAD tools are not successful. There are a lot of good RAD tools available from 1992 until today e.g. Delphi (Borland and now Embarcadero). No tons of generated code, very precise and works very good.

Using visual coding thing does not mean to have higher abstraction layer. And programming visual for logic like “if-then-else” with “flow chart” or BPMN or UML or other visual tools won’t scale. Therefore we still write textual today and not drawing everything to communicate. Drawing is ancient, exists before you can write and read. Visual and textual representation have their own role today in software.

Letting non-developers clicking visual programming tool means ‘horror” for the TCO (Total Cost of Ownership) of your app. Application development cost is always TCO and not only the first cost of developing it.

Also without the ability to leave such a platform, vendor lock in, I would say, everything is useless, I have seen a lot of such applications, which have to be re-developed. If you want to make the abstraction layer of software development higher, take a look at Spring Framework for Java. It definitely brings higher abstraction layer to compare with Java applications without Spring and no vendor lock-in.

Visual programming for UI is good, BPMN for Business Process modeling is the way to go and UML class model for Business Entities makes talking about the domain with everybody easier. But doing complex fine logic with visual programming won’t scale. Business logic is not just simple ScratchJr programming.

Comments

Popular posts from this blog

Software Development Macro and Micro Process

If you think that in year 2012 all companies which produce software and IT divisions in our world have already their optimized software development process, you are wrong. It seems that we - software architects, software developers or whatever your title is - still need to optimize the software development process in many software companies and IT divisions. So what do you do if you enter a software company or IT division and you see following things: 1. There is a perfect project management process to handle all those development of software but it is a pure project management without a context to software development. So basically you only take care of cost, time, budget and quality factors. In the software development you still use the old fashioned waterfall process. 2. From the tooling point of view: you have a project management planning and controlling tool but you are still in the beginning of Wiki (almost no collaboration tool) and you don't use issues tracking sy

Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?

Last year we saw the launch of a new Web programming language Dart - Structured Web Programming from Google. A very interesting approach to support web application development. Not so long after Go, Groovy, Ruby, Scala, << name your DSL here >> ; we see Dart. Is it a good thing to have at least one programming language to solve one problem? The answer is, like we already know, it depends. Some important backgrounds you should know about the multi programming language paradigm are following: 1. You can read Martin Fowler article about language oriented programming with language workbenches which enables you to write small programming languages easily. In this article I see everyone writing their small languages, everywhere. In this concept we see DSL (Domain Specific Language) as the future of our programming activities. Source: http://martinfowler.com/articles/languageWorkbench.html 2. Neal Ford talked about Polyglot Programming, combining multiple programming language

Creating Spring Bean dynamically in the Runtime

In my training someone asked me whether it is possible to create an object (a Spring Bean) dynamically so you can choose which implementation you want to have  in the runtime . So at the compile time you don't know what object actually should be created yet. The application should decide what object to be created based on a property file . 1. We create an annotation so we can mark the method which should be able to create the object dynamically: ... package your.package; ... @Retention(RetentionPolicy.RUNTIME) public @interface InjectDynamicObject { } ... 2. Use the new created annotation in your method which should be able to create the object dynamically: ... @Named("customerBo") public class CustomerBoImpl implements CustomerBo { ...     @Override   @InjectDynamicObject   public Customer getDynamicCustomer() {         return this.dynamicCustomer; } ... 3. Write an aspect with Pointcut and Advise which change the ob