Mendix kann man nicht ernst nehmen, oder?
Eine Sache die mir immer wieder auffällt seit ich mit Mendix arbeite ist, wie unterschiedlich Menschen darauf reagieren wenn man ihnen sagt, dass man LowCode Entwicklung mit Mendix macht. Im Wesentlichen gibt es drei Typen von Reaktionen.
- Der andere Mendix/LowCode Entwickler
Andere Mendix entwickler sind mit der Materie vertraut. Sie wissen wovon ich rede wenn ich über Mendix und LowCode spreche. Die Reaktionen sind dementsprechend vorhersehbar. - Personen ohne Entwicklungserfahrung
Menschen die keine eigenen Erfahrungen mit Softwareentwicklung gemacht haben sind meist wenig an der Technik sondern vielmehr an den Lösungen interessiert. Ihnen ist es im ersten Moment egal wie ein Problem gelöst wird, so lange es in ihrem Sinne gelöst wird. - High Code Entwickler
High Code Entwickler sind „echte“ Entwickler. Sie haben gelernt mit Programmiersprachen wie C, Java, Python, JavaScript,… (Die Liste lässt sich beliebig erweitern) zu entwickeln. Erzählt man einem High Code Entwickler von Mendix ist die Reaktion oft zunächst ablehnend.
Nun, ich weiß, dass ich hier mit Stereotypen spiele und dass selbstverständlich nicht alle Menschen gleich sind. Es gibt Schnittmengen zwischen den Gruppen und es gibt selbstverständlich auch ganz andere Reaktionen. Dies hier soll aber kein soziologischer Aufsatz werden. Ich möchte diese Stereotypen nutzen um auf etwas anderes einzugehen. Hierbei interessieren mich insbesondere High Code Entwickler und Personen ohne Entwicklungserfahrung.
Mendix ist ein Evolutionsschritt
Etwas was ich immer wieder beobachte und was ich zu Beginn meiner Arbeit mit Mendix bei mir selbst beobachten konnte ist die Einteilung in „Echte Programmierung“ (High Code Programmiersprachen) und „Nette Spielerei“ (Low Code Programmiersprachen). Ich selbst war nicht frei von Vorurteilen. Mein erster Eindruck von Mendix war, dass es ein ganz nettes Tool ist mit dem man kleine Anwendungen und Mockups bauen kann. Mehr aber auch nicht.
Wie falsch ich lag.
Nach Jahren der Arbeit mit Mendix betrachte ich es als der logische nächste Schritt in der Art wie wir Entwickler mit Computern interagieren. Um das zu erklären muss ich ein paar Jahre zurück gehen. Das folgende wird keine Enzyklopädie der Computergeschichte und beansprucht nicht vollständig zu sein, aber ich möchte kurz darüber reden wie sich Softwareentwicklung verändert hat.
Die Evolution der Computerprogrammierung
Es gibt zwei Dinge die man über Computer sagen kann.
- Computer sind dumm
- Moderne Computer (Quantencomputer mal ausgenommen) funktionieren im Grunde nach dem gleichen Prinzip wie Computer in den 60ern (oder davor)
Um einen Computer zu Programmieren muss man ihm Befehle erteilen. Diese Befehle müssen dem Computer binär vorliegen. Dies ist natürlich ein sehr mühsames und zeitaufwändiges vorgehen. Der Umgang mit einem Computer in Binärcode erschließt sich nur einigen wenigen Spezialisten. Es liegt auf der Hand. dass eine praktikablere Lösung notwendig war.
Der nächste Schritt in der Evolution stellen Assemblersprachen dar. Jeder Prozessortyp hat einen eigenen Befehlssatz der in Assembler dargestellt werden kann. Diese Sprache ist für Menschen leichter zu lesen und es ist damit leichter in ihr zu entwickeln. Assembler ist also eine Abstraktionsschicht die den Binärcode vor dem Menschen verbirgt. Wer jedoch schonmal mit Assemblersprachen gearbeitet hat weiß, dass auch das sehr mühsam ist. Grundlegende Komfortfunktionen von moderneren Sprachen fehlen und müssen jedes mal neu entwickelt werden. Zudem muss ein Programm für einen neuen Prozessortyp neu geschrieben werden weil ein anderer Prozessortyp einen anderen Assembler Befehlssatz mit bringt.
Die Lösung für diese Unannehmlichkeiten sind höhere (High Code) Programmiersprachen. Populäre Beispiele hierfür sind C, Java,… Diese Sprachen haben den Vorteil, dass ihre Syntax sich noch mehr an menschlicher Lesbarkeit orientiert, sie bringen Komfortfunktionen wie Schleifen mit, sie kümmern sich um Speichermanagement und durch die Verwendung von Compilern oder Interpretern sind die darin entwickelten Programme portabel. Diese Sprachen sind eine weiter Abstraktionsschicht welche die Komplexität von Binärcode oder Assembler vor dem Entwickler versteckt.
Aber auch die Verwendung von High Code Sprachen hat natürlich ihre Nachteile. Ein Entwickler verliert die direkte Kontrolle über die Vorgänge im Computer. Die Syntax der Sprache fasst Befehle der Maschinensprache so zusammen, dass einfach zu verwendende Actions daraus werden (Spätestens hier dürften die Mendix Entwickler unter meinen Lesern merken worauf ich hinaus will ????).
Dieser Verlust der direkten Kontrolle ist der Preis den man zahlt um schneller zum gewünschten Ergebnis zu kommen und um die Sprache einer größeren Gruppe von Entwicklern zugänglich zu machen.
Aber was hat das alles mit Mendix zu tun?
Die Kritik die man oft hört ist, dass man mit Mendix keine direkte Kontrolle über den Code hätte und dass die Reduzierung auf einige wenige Actions eine Einschränkung darstellen. Schaut man sich die Evolution der Programmiersprachen jedoch an stellt man fest, dass diese Argumente so alt sind wie Computer selbst.
Mendix und LowCode sind die nächste Stufe in der Evolution. Mendix ist eine weitere Abstraktionsschicht mit der die Komplexität von High Code, Assembler und Maschinensprache vor dem Entwickler versteckt wird. Der Entwickler gibt einen Teil seiner direkten Kontrolle ab, ist dadurch aber in der Lage Anwendungen schneller zu entwickeln. Außerdem ist die verwendete Enticklungsumgebung ein weiteres mal für eine größere Gruppe zugänglich.
Fällt euch etwas auf? Genau. Es sind die exakt gleichen Argumente die schon für High Code sprachen welche jetzt für LowCode sprechen. Jede Evolutionsstufe hatte eine Verbesserung der Entwicklungsgeschwindigkeit sowie eine demokratisierung des Entwicklungsprozesses zur Folge.
Was ist jetzt die beste Lösung?
Die Antwort auf diese Frage ist einfach: Es gibt nicht die eine beste Lösung. Die existenz von Mendix macht die Verwendung von High Code nicht überflüssig. High Code hat in vielen Bereichen seine Daseinsberechtigung (Sogar Mendix kann mit Java und JavaScript erweitert werden). Ebenso gibt es immer noch Bereiche in denen Assembler und Maschinencode das Mittel der Wahl sind. Es muss aber anerkannt werden, dass LowCode die Konsequenz einer Evolution ist die vermutlich immer weiter gehen wird.
Also, probiert es einfach mal aus. Wenn ihr breits Mendix Entwickler seid muss ich euch das alles ja nicht sagen. Falls nicht, probiert es mal aus. Schaut nicht nur auf die Einschränkungen sondern schaut auf die Möglichkeiten die sich dadurch auf tun. Genau so wie es in der Evolution der Softwareentwicklung schon immer war.
Wollt ihr mehr wissen? Schreibt mich einfach an. Wir können alle nur voneinander lernen.
Ich hoffe euch hat es gefallen. Ich freue mich wie immer auf Feedback!