Workflow-Engine? Die bauen wir selbst…
Eigene Workflow-Engines zu bauen scheint nach wie vor ein angesagtes Thema zu sein. Auch wir sind mit der Fragestellung gerade bei verschiedenen Kunden konfrontiert. Warum man im Jahr 2009 immer noch eigene Engines baut ist mir ein Rätsel, ich will auch kurz sagen warum.
Denn als ich neulich im Zuge der Wochenendplanung die Zitty durchblätterte viel mir der kleine Cartoon zu unserer Linken in die Hände. Und mir drängte sich sofort der Vergleich zu Workflow-Engines auf, auch wenn dies aus sozial-psychologischer Sicht vielleicht bedenklich ist 😉
Fragt man Projekte warum sie Workflow- bzw. Process-Engines selbst bauen möchten hört man häufig:
- “Wir haben nur ganz einfache Anforderungen, einen ganz simplem Zustandsautomat. Da ist eine Workflow-Engine Overkill.”
- “Wir müssen die Engine in die eigene Anwendung einbauen.”
- “Wir haben Produkt x evaluiert und es passt einfach nicht”
Klingt ja soweit auch ganz plausibel, oder? Ich möchte den Argumente jedoch ganz kurz ein paar Gedanken widmen:
Wir haben nur ganz einfache Anforderungen
Mit jedem eingesetzten Produkt oder Framework steigt natürlich die Komplexität. Auch ist die Lernkurve mancher Workflow-Engines nicht gerade flach, gar keine Frage. Ich habe es jedoch schon so oft gesehen, dass mit einem einfachen Zustandsautomaten gestartet wird, meist dann so irgendwie eine Entät/Tabelle pro “Prozessinstanz” mit einer Spalte, die den Zustand angibt. Denn Persistenz und eine Datenbank braucht man ja sowieso.
Aber Moment, wenn ich Wartezustände habe, brauche ich dann nicht auch Timeouts oder Eskalationen?
Oder möchte ich nicht vielleicht von einem Zustand in einen Folgezustand “gehen”, wobei ich eine Entscheidung treffen muss (also ein datenbasiertes exklusives Gateway in BPMN)?
Naja, ok, das bauen wir schon auch irgendwie in den eigenen Zustandsautomat ein. Die Softwareentwicklung hat ja auch vor der Existenz von Workflow-Engines funktioniert. Werkelt man also weiter vor sich hin, möchte man häufig die Prozesse flexibler haben. Also fix ein XML-Format definiert. Eventuell sogar dem Standard XPDL oder bald BPMN 2.0 bedient, aber eher nicht. Ist ja auch wieder zu komplex. Es soll nur bitte der (Produkt-) Manager nicht mit dem Wunsch nach grafischer Darstellung der Porzesse kommen! Wozu auch, XML ist doch eh prima lesbar.
Okay, geschafft. War doch ganz einfach. Und wir haben keine unnötigen Features in unserer Maschine 🙂
Aber wir haben eben leider auch manch anderes nicht unbedingt in unserer Maschine: Skalierbarkeit? Concurrency bedacht? Versionierung von Prozessen? …?
Brauchen wir doch auch nicht, wir haben ja auch nur einfache Anforderungen. Und das Produkt entwickelt sich ja auch nich weiter, wenn man erstmal Begehrlichkeiten nach Workflows geweckt hat? Oder vielleicht benutzt es mal der Kollege an einer anderen Stelle (Hurra, Wiederverwendung)? In meiner Projekterfahrung habe ich auf jeden Fall schon so viele Engines gesehen, die dann doch nach und nach aufgebohrt wurden/werden mussten und am Schluß auch ganz schön leistungsfähig waren. Und dabei ist es dann nicht nur um die Personentage der Entwicklung schade, sondern vor allem um die Wartung. Und im gegensatz zur Neuentwicklung macht die noch nicht mal Spaß.
Wir müssen die Engine in die eigene Anwendung integrieren
Soll die Engine in das eigene Produkt eingebaut werden gelten in der Tat andere Regeln. Viele BPM Produkte und Workflow-Engines sind hier wirklich ungeeignet, wenn auch nicht generell. Das man Integration mit der eigenen Anwendung nicht mit Webservices realisieren möchte, nun das verstehe ich gut. Auch kommen manche Engines als dicke Server daher, mit entsprechenden Installtions- und Hardware-Anforderungen. Und günstig sind die Produkte auch nicht, schon dreimal nicht wenn man sie ins eigene Produkt integriert und weiterverkaufen möchte.
Aber spätestens seit die Open Source Gemeine Process Engines entdeckt hat, gilt dieses Argument nicht mehr. Mit den verschiedenen Vertretern dieser Zunft (Beispielsweise JBoss jBPM, Nova Bonita oder Enhydra Shark) kann eine meist leichtgewichtige Java Engine in die eigene Anwendung problemlos integriert werden. Oft bieten die Engines entsprechend vielseitige Konfigurationsmöglichkeiten, so dass sie entsprechend dem eigenen Bedarf angepasst werden können. Teilweise kann auch die Workflow-Sprache noch angepasst oder erweitert werden. Konsequent zu Ende gedacht ist dies aktuell auch in der JBoss Process Virtual Machine (PVM), die nur den grundlegenden Zustandsautomat definiert, und keine Sprache. Möchte man also tatsächlich eine eigene Engine bauen, könnte man dies zumindest als Grundlage nehmen um nicht das ganze Rad neu zu erfinden.
Wir haben x evaluiert, es passt nicht
Den Punkt habe ich reserviert, um mir ein bisschen Frust von der Seele zu schreiben 🙂 Evaluieren heißt halt leider mehr, als einen Studi nen Tag ranzusetzen, der das dann auf Anhieb erst mal nicht zum Laufen bekommt. Ich entschuldige mich bei allen, die sich auf den Schlips getreten fühlen (aber wer trägt denn in der IT heute noch Schlips ;-))! Ja, es ist leider wahr, dass gerade die Open Source Engines eine gewisse Einstiegshürde legen. Also mal eben nebenbei aufsetzen ist daher recht schwierig. Man muss sich also ein bisschen Zeit nehmen. Um einmal jBPM als Beispiel zu nehmen: Bisher hatte ich bei keinem Kunden in einem Workshop etwas gefunden, was mit jBPM nicht relativ einfach umgesetzt werden kann. Immerhin sind in die aktuelle Version einige Jahre an Reifeprozess und Erfahrung eingeflossen. Meist erlebt man schon nach einigen Minuten bei der ersten Frage ein “Ah ha”-Erlebnis beim Kunden: “So geht das also. Cool. Ist ja ganz einfach. Zum Glück haben wir das nicht selbst gebaut.”
Natürlich darf man den zweiten Teil des Satzes nicht vergessen: “Das muss man aber wissen”. Ja, stimmt. Da erfordern die Produkte eben leider doch ein bisschen Einarbeitung. Aber aus meiner Sicht ist die Zeit hier deutlich besser investiert als in der eigenen Engine. Denn
- Die Wartung erfolgt extern,
- Das Produkt wird weiter entwickelt,
- Man profitiert von der Erfahrung, die im Produkt steck,
- Man kann Support kaufen bzw. sich Internet-Foren bedienen und
- Man bekommt viele Features, die man zu Anfang vielleicht nicht braucht, später aber wichtig werden können.
Zu guter Letzt
Ich kann also nur immer sagen: Bitte, nicht selbst entwickeln! Die Engines bringen einiges mit, was man nicht mal so eben selbst entwickelt. Es ist die Lernkurve fast immer wert! Und diese Engine ist dann eben kein unkalkulierbares Risiko. Um in der Analogie des Comics vom Anfang zu bleiben: ich glaube sogar, dass es zukünftig für viele Anwendungen wichtiger wird, Prozessorientierung besser zu verinnerlichen. Dies würde vielen Anwendungen auch gut tun. Es ist also ein wichtiger Fortschritt, bei dem ich lieber dabei bin als zuzuschauen. Aber klar, muss ich ja sagen, ist ja mein Job 😉
Kurz gesagt: In einer perfekten Welt wird die Engine also vielleicht sogar eine Art Selbstverständlichkeit. So wie OR-Mapper heute. Und es will doch auch keiner mehr ein zweites Hibernate entwicklen, oder?
P.S.
Sollte jemand anderer Meinung sein oder doch einen guten Grund parat haben, warum die Eigenetwicklug sein musste bzw. Sinn macht, lasst es mich wissen!
Da gibts doch ein einziges Grund die ich leider nicht acceptieren wil aber ja oft muss. Zeit… Mann investiert oft nicht im forne um ein existirender Engine zu lernen. Da bleibt ja nichts anderes ubrich mit ein einfacher gelbst gekunstelter Engine zu starten. Das soll kein Problem sein wenn man ja am selben Moment ein guter ‘PAO’ (process access object) macht un den selbstbau mit den exisitirender Engine austauscht im nachsten release (auf Deutsch?). Oft passiert das leider nicht weil im nachsten release zeit wider ein Problem bekommt. 🙁
Hi Ronald. Kommentar auf deutsch, prima 🙂
Ja, da hast du recht.
Leider dreht sich das dann meist innerhalb des Projektes. Im Endeffekt hat man viel mehr Zeit gebraucht, das PAO selbst zu bauen, zu erweitern und vor allem zu Warten, als das Einlernen in die Engine gekostet hätte.
Und es gibt ja auch Trainings & Workshops von guten Beratern (“hüstel”), die einem bei schnell-Produktiv-werden helfen können 🙂
Ich war vor kurzem in genau dieser Situation. Nachdem ich beinahe zwei Wochen lang prokrastinierte indem ich verschiedene (meist Open-Source) Workflow-Engines ausprobierte, setzte ich mich letztendlich hin und schrieb die paar Dutzend Zeilen Code (inkl Tests) die notwendig sind für eine einfache Petri-Net Implementation.
Ist die Implementation hoch-skalierbar, unterstützt sie Standards und graphische Entwicklungsumgebungen? Nein. Aber ehrlich gesagt wäre nichts von dem wirklich von Nutzen gewesen für uns, und alleine der Code um eine “richtige” Workflow-Engine zu integrieren wäre komplexer (und schwieriger zu testen) gewesen.
Das will nicht heissen dass es sich nicht lohnen kann eine Workflow-Engine zu integrieren, aber eben halt nicht immer (insbesondre solange Engines wie JBoss jBPM als “leichtgewichtig” angesehen werden)…
Hallo Eric.
Vielen Dank für die Meinung. Prinzipiell glaube ich ja auch, dass man nie alles über einen Kamm scheeren kann. Vielleicht habt ihr ja tatsächlich einen Sonderfall vor euch.
Aber ich wäre auch echt gespannt, wie es euch mit dieser “Engine” später im Projekt udn vor allem im Betrieb geht und wie die Sache so in 2-5 Jahren aussieht. Denn wie ich geschrieben habe, der Anfang ist immer leicht und man unterschätzt was da noch alles kommt. Spätestens im Betrieb muss dann doch eben genau sehen, wo ein Prozess steht, vielleicht mal eine Instanz korrigieren usw.
Und sollte euch die Lösung vor die Füße fallen oder die Kernentwickler das Projekt verlassen, naja, dann wirds auch schwierig.
Kurzum: Ich finde das nach wie vor kritisch. Ich möchte ja auch niemandem zu nahe treten, aber ich denke beispielsweise in jbpm hat man nach dem 3 Tage JBoss-Training das notwendigste an der Hand um loszulegen, die wichtigsten Grundlagen vermitteln wir üblicherweise in einem Tag. Also in 2 Wochen sollte da schon ein Prototyp zu machen sein. Vor allem, wenn man stattdessen seine eigene Engine baut, was ja heißt, dass man schon was vom Entwickeln verstehen muss.
Ich denke, meist wird dann auch bei der Evaluierung zu ungezielt vorgegangen. Ich kenne das ja auch selber, man lädt dieses Tool, probiert ein bisschen. Geht nicht gleich, Hmm, naja, dann mal das Tool probiert. Und nach ner Woche ist man eher gefrustet und denkt, keins davon tut wirklich.
Ein bisschen mehr Zeit muss man dann halt dann doch mitbringen. Ich glaube weiterhin das es sich lohnt, lass mich aber auch gerne vom Gegenteil überzeugen. Da wäre zuerst auch mal interessant, für welchen Anwendungsfall die Engine zum Einsatz kommen soll…
Schöne Grüße
Bernd
Schon möglich dass Evaluierungen oft halbherzig gemacht werden (Not-Invented-Here Syndrom)…
Die Anwendung an der ich arbeite basiert auf Eclipse RCP (mit Spring und Hibernate et al). Unter anderem hilft die Anwendung den Benutzer durch ein paar (meist sequentielle) Tasks die zum Teil relative komplex sind (Benutzeroberfläche, Datenverarbeitung etc).
Wie erwähnt stellte sich heraus dass der Code um eine existierende Engine in die Anwendung zu integrieren komplexer gewesen wäre als eine einfache Implementation die genau das tut was benötigt ist. Das ist ein wichtiger Faktor in einem kleinen/agilen Team. Schade dass wir keine leichtgewichtigere Tools gefunden haben (bester Kandidat: Sarasvati).
Wie die Situation in 2-5 Jahren aussieht ist schwer vorauszusagen. Vielleicht stellt es sich heraus dass wir mehr Workflow Features benötigen. Oder vielleicht ist sogar die einfache Lösung Overkill. Oder wir brauchen eine flexiblere Rule-Engine. Was sicher ist: Die einfache Lösung kann einfacher durch eine komplexere Lösung ersetzt werden als umgekehrt!
Der Artikel wird übrigens auch auf InfoQ diskutiert: http://www.infoq.com/news/2009/07/WFEngine
Hi Eric.
> Was sicher ist: Die einfache Lösung kann einfacher durch eine komplexere Lösung ersetzt werden als umgekehrt!
Da gebe ich dir recht. Ich bin nur immer noch ungläubig, dass es so komplex sein soll, eine Java-Workflow-Engine in diese Umgebung zu integrieren. Und das machen wir ja regelmässig in Projekten… Natürlich hat aber schon jedes Produkt eine Lernkurve, klar, aber ich habe ja geschrieben: “Natürlich darf man den zweiten Teil des Satzes nicht vergessen: “Das muss man aber wissen”. Ja, stimmt. ..”
Naja, trotzdem will ich auch nicht abreden, dass es Anwendungsfälle gibt, in dem eine Workflow-Engine nicht geeignet ist, wenn man eben andere Use Cases löst.
Mich würde einfach interessieren, wie es mit eurem Framework weitergeht und wie eure Erfahrungen in ein paar Jahren sind. Da würde ich mich dann gerne davon überzeugen lassen, dass es der richtige Weg war. Auch meine Meinung ist ja nicht in Stein gemeisselt 😉
Interessanter Artikel.
Ich kann gut verstehen, wenn jemand selbst eine Engine bauen möchte, statt eine der etablierten zu verwenden. Insbesondere dann, wenn die Engine eingebettet werden soll, denn dafür finde ich persönlich schon jBPM zu groß/unhandlich.
Bernd, du hast JBoss PVM angesprochen. PVM sieht in der Tat vielversprechend aus. Es scheint sich tatsächlich (fast) auf das nötigste einer Process Engine zu konzentrieren, und sollte sich damit auch leichter an eigene Anforderungen anpassen lassen als die großen Engines. Allerdings ist die letzte offizielle Release auf jboss.org von 2008, und hat Alpha-Status. Die Dokumentation lässt auch noch viel zu wünschen übrig, und Roadmaps scheint es für das Projekt auch nicht zu geben. Somit würde ich selbst es momentan nicht einsetzten, da das Projekt nicht besonders ‘lebendig’ aussieht.
Allerdings würde ich PVM, wenn ich selbst eine Prozess-Engine entwickeln würde, zumindest als Inspiration verwenden, denn da stecken einige gute Ideen drin.
Hallo Rolf.
Kann ich eigentlich nicht ganz nachvollziehen. Ja, jBPM hat eine kleine Lernkurve. Aber auf der anderen Seite finde ich es wirklich sehr leicht integrierbar, und das haben wir bereits in zahlreichen Projekten bei verschiedenen Kunen erfolgreich praktiziert. Ein paar Kniffe sollte man dazu halt kennen oder natürlich einen entsprechenden Berater anheuern (hüstel ;-)).
Der Punkt ist: Eine selbstgebaute Engine läuft fast immer irgendwann aus dem Ruder und verursacht in der Wartung immense Kosten, das kann sich niemand heutzutage mehr ohne Not leisten (mit Not meine ich: Sehr spezielle Anforderungen, die in der Tat nicht abgedeckt sind). Oft braucht es auch lange, bis alle Anforderungen wirklich identifiziert wurden und sich die Engine stabilisiert. Ich finde den Vergleich zum OR-Mapper naheliegend: Hibernate hat auch eine Lernkurve, aber würdest du wirklich einen eigenen OR-Mapper bauen wollen?
Zur Frage JBoss PVM: Die PVM ist inzwischen released und stabil, da sie ja die Grundlage für jBPM 4 bildet. Die Webseite ist da leider inaktuell (trigger ich mal an). Aktuell ist es wohl am besten, einen Blick in die SVN-Sourcen zu werfen. Jaja, ich weiß 😉 Aber hey, es ist ja auch eher das interne Herz, was man nur anfasst, wenn man sich die Finger sowieso mit Java schmutzig machen möchte.
Übrigens: Wenn du dir dort mal anschaust, was mit der jPDL-Sprache noch on top kommt, ist dies wirklich sehr wenig. Wenn du also eine fertige Engine suchst bringt es wenig Vorteile die PVM statt jBPM jPDL zu verwenden. Außer du willst bewußt eine eigene Sprache implementieren (so wie wir aktuell BPMN 2.0 oder Bonita mit XPDL), dafür ist das Konzept der PVM dann ja auch gedacht
Es nachbauen kann ich auch nur noch mal davon abraten, ich habe ja hautnah als Committer miterlebt, wie viel Arbeit und vor allem auch Gehirnschmalz in der PVM stecken. Und da flossen ja bereits viele Erfahrungen aus jBPM 1-3 von verschiedenen klugen Köpfen ein. Spätestens Dinge wie Transaktionssteuerung, Clustering, Multi-Threading sind halt auch nicht easy…
Naja, letztendlich muss es aber jeder selber wissen. Ich schau es mir dann im jBPM-Migrationsprojekt später an ;-)) Nee, quatsch. Also wenn du wirklich ganz konkrete Punkte hast, weswegen jBPM nicht passt und ihr ne eigene Engine braucht, würde mich das wirklich interessieren, kannst du also gerne schreiben.
Weihnachtliche Grüße
Bernd
Hallo Bernd,
danke für deine Antwort.
Ich werde deinen Rat befolgen und mal einen Blick in die Sourcen von jBPM 4 werfen. Ich bin vor allem an den API-Dokus interessiert.
Ich sollte wohl noch ein bisschen genauer auf meinen Standpunkt eingehen. Vielleicht wird dann verständlicher, worauf ich hinaus will.
(Wenn ich im Folgenden über PVM spreche, dann beziehe ich mich auf die Version, die auf der Webseite dokumentiert ist, also die von 2008. Den Stand aus den jBPM 4-Sources kenne ich noch nicht.)
Ich habe nämlich weniger an Business-Anwendungen gedacht, in denen man richtige Geschäftsprozess modellieren und dann abarbeiten möchte. Dafür finde ich jBPM tatsächlich gut geeignet, und auch nicht schwer zu verwenden. Ich dachte aber eher an Verwendungen, bei denen man normalerweise nicht an Geschäftsprozesse denken würde, ohne Application Server, Transaktionsmanager, evtl. auch ohne Datenbank: die Steuerung irgendwelcher programminterner Zustände.
Hier mal ein paar Beispiele (vielleicht nicht die besten, aber was besseres ist mir auf die Schnelle nicht eingefallen):
– Steuerung des Pageflows in einem Wizard in einer GUI-Anwendung
– Steuerung der Zustände in einem Netzwerkkommunikationsprotokoll.
Solche kleinen Zustandsverwaltungen findet man in sehr vielen Programmen. Klassicherweise würde man sowas mit einem switch-Konstrukt in einer Schleife (ein sehr primitiver Zustandsautomat) oder mit einem if-else-Gebirge lösen. Hässlich, aber pragmatisch. In solchen Fällen würde niemand die Zeit investieren, eine komplexe Engine einzubetten, sondern einfach zur klassichen, hässlichen Lösung greifen.
Dabei wären solche Fälle mit einer minimalistischen Prozess-Engine meiner Meinung nach gut bedient, da man den Zustandsautomaten dann nicht selbst schreiben müsste, sondern sich nur um die eigentlichen Aktionen kümmern müsste.
Für genau solche Fälle finde ich einige der Ansätze von PVM passend:
– Definition des Workflows in Code, nicht in XML: Meiner Meinung nach besser zu lesen, schneller zu tippen (dank Intellisense), und der Compiler prüft, ob alles passt. Es muss sowieso der Entwickler ran, wenn etwas geändert werden muss, da es sich um Programminterna handelt, und nicht um abstrakte Geschäftsprozesse.
– Eine einfache API (ProcessFactory), um die Prozesse zusammenzubauen: Noch bequemer und schneller kann man einen Prozess wohl nicht zusammenbauen.
– Austauschbarkeit von Services, um die Engine an die eigene Umgebung anzupassen.
– Lightweight (größtenteils): nur das Notwendigste wird angeboten; speziellere Konzepte (z.B. Taskhandling, Swimlanes), die für den von mir geschilderten Anwendungszweck unnötig wären, kann auf der Basis-Engine aufbauend entwickelt werden.
Nun gibt es aber auch Dinge, die ich auch an PVM schon wieder overblown finde:
– Die Persistenz-API ist auf OR-Mapper ausgelegt (z.B. die Methode save(Object) in der Session-API). Die Abbildung auf JDBC oder textbasierte Dateiformate ist schwierig; die Verwendung eines OR-Mappers stellt aber einen gewissen Overhead dar (auch aus Performancegründen).
– Die Verwendung einer XML-Konfigurationsdatei: wenn die Engine mit ein paar Zeilen Code für einfache Fälle konfiguriert wäre, wäre sie meiner Meinung nach schneller eingebettet.
Ich hoffe, mein Standpunkt ist nun etwas klarer. Für die von mir geschilderten Fälle würde ich wohl dazu tendieren, selbst etwas sehr leichtgewichtiges zu programmieren, während ich das für richtige Geschäftsprozesse in Enterprise-Anwendungen definitiv nicht tun würde.
Ich stimme dir aber zu, dass man den Aufwand nicht unterschätzen sollte. Spästens bei Splits und Subprozessen würde das Ganze wahrscheinlich etwas komplizierter werden.
Gruß
Rolf
Hi Rolf.
Okay, dann sind wir jetzt ja wieder eher beieinander, ich habe ja auch nicht geschrieben “Technischer Zustandsautomat? Den bauen wir selber” 😉 Nee, natürlich ist jBPM nicht die eierlegende Wollmichsau. Der Use Case von dem ich gesprochen habe waren Geschäftsprozesse und Workflows. Wenn man in den tief technischen Bereich vordringt und alles abschneidet, was so eine Process Engine mitbringt (Persistenz, visuelle Modellierung, Vorfertigung im Bereich Task-Management und Serviceanbindung, …), dann ist sie denke ich auch wirklich nicht mehr das Richtige. Wobei gerade das Beispiel des Pageflows grenzwertig ist. JBoss Seam verwendet jBPM erfolgreich als Pageflow Engine. Ohne Persistenz natürlich, aber auch das ist ja kein Problem. Wobei hier ja genau die visuelle Darstellung genutzt werden soll, also zumindest ein Feature der Engine.
Also: Natürlich ist also mit der Process Engine als Hammer nicht jedes Problem ein Nagel! Gerade wenn man in den tief technischen Bereich vordringt würde ich auch nicht mehr unbedingt jBPM einsetzen. Da bestehen andere Anforderungen…
Wobei ich deinen Vergleich mit dem OR-Mapper nicht zählen lassen möchte. Wenn man nicht gerade Batch-Massenverarbeitung macht ist das mitnichten langsamer als Plain-JDBC. Schlussendlich steckt viel Know-How im OR-Mapper zu Optimierung der SQL-Statements. Eine Anmaßung von nicht SQL-Genies wie uns (also zumindest mir), das mal eben im Projekt besser machen zu können 😉
Schöne Grüße
Bernd
Hallo Bernd,
ja, der Spruch mit dem Hammer und dem Nagel passt hier sehr gut 😉
Es ist tatsächlich immer die Frage, wo man her kommt, und was man erreichen möchte. Von daher war die Diskussion für mich sehr interessant. Vielen Dank dafür.
Gruß
Rolf
Hallo Bernd,
prima Artikel.
Ich sehe als Problem, dass diese Prozesse oft von “Programmieren”, ohne Informatik-FH oder Uni Abschluss entwickelt werden sollen.
Der Manager selbst hat auch keine IT studiert. Er sieht, wie schnell die Leute programmieren (wieder etwas mit copy und paste) fertig. Juhu.
Fragt man dann nach, ob sie einem mal den Zustandsautomaten aufmalen könnten, kommen sie bereits ins Schwimmen. Wie soll jemand ohne das Wissen von Zustandsautomaten überhaupt solche Engines entwickeln können?
Cheers,
Stefan
[…] for such an implementation is nearly as high as building a process engine from scratch, which is a bad idea, […]