Genau so ein Projekt habe ich auch verzapft, aber ohne Druck von nem C-Level und mit Anlauf :D Wir haben das Projekt von Anfang an so designed, dass wir damit diverse Fälle abdecken können (Input-Module mit Flags, geteilte Logik mit wenigen Settings, Output-Module mit Flags), aber mit jedem weiteren Fall kamen auch einige Sonderfälle mit rein, die wir dann versucht haben in unser modulares System rein zu quetschen. Das ist aber ein generelles Problem bei vielen Projekten. Die Domäne des Kunden lernt man erst über die Zeit wirklich kennen und in dem Moment wo man diese vollständig durchblickt hat, ist es oftmals schon viel zu spät, deswegen ist gutes Anforderungsmanagement das wichtigste und muss aktiv passieren, denn der Kunde hat in den allermeisten Fällen selbst keine Ahnung was er will, das fällt ihm ein wenn das Projekt abgeschlossen ist.
Oh ja mit Anforderungsmanagement haben wir total gute Erfahrungen gemacht. Da wurde extra ein Anforderungsanalytiker eingestellt. Der hat dann die Aufgabe bekommen, zu analysieren, ob wir die Anforderungen erfüllen. Hat dann etliche Monate damit verbracht, die (Tausenden) Anforderungen einfach als Frage zu formulieren. Also so richtig stur durchgezogen, zb die Anforderung "Dateisysteme müssen ein Journal verwenden" wurde dann "verwenden Dateisysteme ein Journal?" Also, natürlich erst noch mal ganz ernst und nachdenklich kucken und dann erst aufschreiben. Das hat er über ein Jahr lang gemacht, dann fertig gemeldet. Alle haben sich auf die Schulter geklopft dass wir endlich das Anforderungsmanagement im Griff haben 😂 Die offenen Fragen (also alle Tausende) sollten dann nur noch vom Entwickler eben beantwortet werden 😂
Das nennt man dann wohl Bottom-Up Requirements Engineering und reiht sich neben dem Obstkorb in der flachen Hierarchie ein :D Das passiert wenn man auf solche Positionen Leute setzt, die eigentlich keine Ahnung haben, was ihre Aufgabe ist und diese sich dann ne Beschäftigung ausdenken. Besonders gut finde ich Consultants, die ohne Berufserfahrung oder sonstige Qualifikation frisch aus dem Studium kommen und dann Leute mit deutlich mehr Berufserfahrung beraten sollen oder Strukturen & Prozesse aufbauen sollen, die sie selbst noch nie gelebt haben.
Hui ja mir kommt da auch ein Projekt in meiner Ex-Firma in Erinnerung. YAGNI haben sie dort nie gehört, alles auf maximale Flexibilität und Anpassbarkeit designed ohne guten Grund und es war dann ein wahnsinniger Krampf, irgendwas sinnvolles damit zu machen.
@@JanBebendorf das sind auch die, die es nie besser konnten und dann oben sitzen und keine Ahnung in echt haben. Aber es gibt auch die laten hasen, die Ahnung haben. Und irgendwann schläg die eigene Uhr 12 und man sitzt auf den Stuhl in der mitte... Erfahrungen sich nacher, die zählen und die Rechnungen zahlen. Wissen ist relativ...
Starkes Video! Extrem verständlich erklärt und sehr nachvollziehbar. Welche architekturellen Mittel und Frameworks meinst du bei 11:43 um solche hoch konfigurierbaren Anwendungen einigermaßen stabil zu halten?
Das größte Problem ist, wenn die Anwendung ein großer amorpher Haufen ist. Wenn ich 1000 konfigurierbare Optionen habe, die sich potentiell alle gegenseitig beeinflussen können, ist das Projekt tot. Wenn ich aber 32 klar voneinander getrennte orthogonale Komponenten mit je 32 konfigurierbaren Optionen habe, dann ist das zwar auch schon sehr komplex, aber durchaus noch managebar.
Ich denke, dass Software sogar besser werden kann, dadurch, dass man sie anpassen kann. Man muss das dann halt alles mit sehr wenig Kopplung arbeiten. Das bedeutet führt dann natürlich zu mehr Arbeitsaufwand beim Testen aber man muss sich das halt sehr gut bezahlen lassen.
Die 32 Komponenten muss man aber auch erst mal planen und implementieren, es ist ein Kampf Abhängigkeiten zu verhindern und am Ende hat man wenn man nicht höllisch aufpasst doch nur wieder ein Wollkneul von Abhängigkeiten.Und außerdem hat man dann eh nicht 32 Komponenten mit 32 Optionen, sondern eine Komponente mit 900 Optionen und 24 mit null.
Meistens ist leider zu Anfang nicht absehbar, welche Varianten man brauchen wird. Oft werden im Lauf der Zeit auch Änderungen durch Rechtsverordnungen o.ä. erforderlich.
@@343max Dass alle einzelnen Komponenten exakt gleich viele Abhängigkeiten haben, ist natürlich sehr unwahrscheinlich. Es wird sich ziemlich sicher eine Pareto-Verteilung ergeben. Aber auch dann gilt: wenn die Config-Optionen sich über die Interfacegrenzen hinaus auswirken, müssen benachbarte Komponenten theoretisch auch immer mit jeder Kombination an Optionen integrativ getestet werden. Das wird sehr sehr schnell zu aufwändig. Wenn Config-Optionen nur einen lokalen Effekt haben, reichen "Unit Tests" für die Komponenten und sehr wenige integrative Smoke-Tests, die sicherstellen, dass die Interfaces nicht auseinanderdriften. Und man muss nicht alles an Tag 1 planen. Man muss nur genügend erfahrene Leute im Team haben, die es rechtzeitig erkennen und laut schreien, wenn Dinge zu stark gekoppelt sind. Und dann muss man diesen Leuten die Zeit geben, aufzuräumen und Sachen wieder zu entwirren. Und wenn man das lange genug nicht macht, hat man irgendwann so viele Edge cases und hacky Features eingebaut, für die sich immer jeweils exakt 1 Kunde finden lässt, für den das unverzichtbar ist, dass man es nie wieder aufgeräumt bekommt.
Hallo David, vielen Dank für das Video. Was mich interessieren würde, wie konntet ihr das Problem lösen? Mich würde ebenfalls interessieren, wie du die Analyse und die Ergebnisse dem Kunden aufbereitest hast? Vielen Dank fürs teilen.
Meiner Meinung nach gibt es 3 Möglichkeiten. 1. Du gibst dich mit deinem Kundenstamm zufrieden und fügst nicht für jeden einzelnen Kunden für sie spezifische Funktionen hinzu sondern nur, wenn einige Kunden diese Funktion haben wollen/brauchen 2. Du implementierst eine Art Plugin-System (Je nach Möglichkeit) um neue Funktionalitäten bzw. Komponenten für die jeweiligen Kunden hinzuzufügen 3. Du gehst nach Robert C. Martin vor und schreibst für jede neue Funktion auch wirklich eine neue Funktion und erweiterst nicht immer die gleiche bzw. baust diese noch schlimmer um. Auch nicht die schönste Lösung, gerade wenn man einen Bug in der Hauptfunktion findet und man alle Funktionen anpassen darf aber so behält man wenigstens den Überblick welche Funktion wofür sind (Wenn es gut Dokumentiert wird)
Solang der Vertrieb, bevor er was verkauft, noch mit der Entwicklung redet und klärt was das bedeutet, ist das doch OK, und auch mal nein sagt wenn er die Infos hat. Ein Problem ist es nur dann, wenn es verkauft wird ohne auch einmal Rücksprache darüber zu halten, das so gar nicht mal möglich ist oder nur dahin geschustert werden kann bzw. mehr Probleme macht als es soll.
Ich würd ja glatt sagen Du warst bei mir in der Firma, aber wir haben keinen Architekten. Die Prämisse meiner Firma ist, der Kunde ist König und es wird jede gewünschte Anpassung umgesetzt. Ergebnis kann man sich denken 😄
Interessant, was du hier erzählst, trifft genau die Probleme in dem letzten Projekt, in dem ich gearbeitet habe. Da frage ich mich nun, auf wie viele Projekte genau dieses Problem anteilsmäßig zutrifft.
Das kommt drauf wie genau du die Projekte definierst, es ist ja nicht jedes Projekt finanziell so stark von Anpassungen und konfiguration abhängig. Aber sobald Anpassungen und Konfiguration reinkommen, wächst diese gefährliche Komponente.
Ich habe in den letzten 10 Jahren in verschiedenen SaaS-Unternehmen gearbeitet, die alle auch vorher das alte Lizenzmodell gefahren haben und zumindest für diesen Unternehmenstyp würde ich die Quote auf 80% oder mehr schätzen. Bei Unternehmen die als SaaS gestartet sind, gibt es das Problem auch, aber in meinen persönlichen Erfahrungen nicht so krass. Dort wird oft von Anfang an mehr Zeit in Schulung investiert, so dass der Kunde teilweise auch seine Prozesse an die Software anpasst und nicht nur umgekehrt.
Verückterweise kenne ich das Problem aus der umgekehrten Perspektive. Ich bin ein "normaler" Entwickler und hatte zeitweise die Angewohnheit, Konfigurationseinstellungen hinzuzufügen, die einfach unnötig waren, ungefähr nach dem Motto "wenn man das einstellen kann, brauchen wir nachher kein Update/Release, wenn wir das ändern wollen". Es war dann der Architekt, der gemeint hat, das brauchen wir nicht, setz einen default Wert und entferne die Konfiguration. Zum Glück hatten es diese unnötigen Änderungen (fast) nie über einen orphaned feature branch hinaus geschafft. 😅
Meistens ist der Vertriebler näher an der Geschäftsführung als die Entwicklung. Das schlimmste was ich mal erlebt habe war dass die Entwickler anfingen für jede Kundenanpassung einen eigenen Branch zu machen und man aus den Branches dann die Deployments gebaut hat. Natürlich wurden die Branches dann irgendwann nicht mehr in den master zurückgeführt weil die Mergeaufwände zu hoch wurden. So hatte man dann irgendwann x Stände von der Software und jede etwas anders. War dann bei der Versionierung die Hölle. Weil Version 1.0.5 bei Kunde X war halt nicht Version 1.0.5 bei Kunde Y :D. Herrlich war das.
Ich bin der Meinung, dass das Problem bei dem Design und der Architektur liegt. Wenn das Hauptunterscheidungsmerkmal die Konfigurierbarkeit ist, dann muss die Software das unterstützen. Ich vermute aber, dass die Konfigurierbarkeit kein ursprüngliches Feature war, sonder erst nach und nach dazu gebaut wurde.
Jain, wie im Video gesagt gibt es natürlich architekturelle Mittel um das abzufedern, aber das hat halt alles seine Grenzen - ein System was nur darauf aufbaut, ist fast unmöglich über lange zeit wirtschaftlich zu betreiben.
@@DavidTielke Lösungen wie SAP und andere ERP/CRM Lösungen usw. beweisen durchaus, dass Software konfigurierbar programmiert werden kann, wenn man sie dafür auslegt.
Ich glaub auch. Allerdings muss man diese Art der Programmierung und Architektur usw erst mal kennen und dann auch noch können. Ich kann ein wenig fühlen wie man das machen könnte aber wenn ich die herkömmliche Programmierung hernehme dann sollte es sehr schwer bzw. fast unmöglich sein komplexe Konfigurierungen mittels DEV umzusetzen. Vl. ein wenig Described programming mit Function programming gemixt. dann könnte es vl. gut gehen.
Ein Problem entsteht doch erst, wenn man 3-10 Consultants braucht, weil keiner allein mehr alle Customizingmöglichkeiten überblickt. Klassische ERP Software halt und umgekehrt scheint es ja eine Art Jobmotor zu sein :)
Wir haben genau dieses problem und es treibt mich noch in den Wahnsinn. Nicht nur ist der branch für den wichtigsten kunden komplett nicht mehr ohne bestimmte daten vom kunden in der datenbank testbar, sondern es wurden hunderte changes auf dem production server gemacht die nicht commited wurden. Und wie auch in dem video besprochen wurden dutzende konfigurierbare features rein gepackt die dann nur für den kunden aktiviert werden. Das arbeiten an dieser Software ist der reinste alptraum...
das kommt davon wenn man programmieren sagt, weil software entwicklen, etwas anderes ist. Das sollte man richtig machen oder es in andere Hände geben lassen.
Ich fühle 100% mit dir. Wir haben im vergangenen Jahr eine Umstellung auf AWS gemacht, nachdem es vorher viele einzelne Installationen waren, bei denen es auch Sonderlösungen in Unterordnern und "Spezialeinträge" in der Datenbank gab. Ich würde sagen wir haben so 95% davon eliminiert und der Rest kommt sicher irgendwann noch als Zombie hoch, wenn jemand den falschen Knopf drückt. Es ist mühselig ... sehr mühselig soetwas aufzuräumen ... aber ich verspreche dir es lohnt sich. Es ist ein gutes Gefühl, wenn man so einen Dämon bezwingen kann, auch wenn man dafür eine dicke Rüstung und viel Ausdauer benötigt. Ich drücke die Daumen, dass ihr das in dem Projekt noch in den Griff bekommt. :)
Trigger auf der Datenbank, die dann Felder missbrauchen, sind auch spitze. Oder Erweiterungen von Datenbanken um Felder, die nur der Projektierer kennt. Auch die Projektierung kann Software zum Platzen bringen und für Service wie auch Entwicklung nicht nachvollziehbares Verhalten erzeugen.
@@MasterBoyZs Ja, irgendwann wird der große Knall kommen. Vielleicht merkt die Firma ja dann mal dass es so nicht weiter gehen kann. Aber am Ende leiden vermutlich wieder die Entwickler darunter...
Danke dir wirklich vom Herzen. Der Kommentar ist natürlich out of Kontext, aber durch das ganze KI Drama und den negativen Input, den man oftmals von anderen Leuten hört, war ich doch hin und wieder am Zweifeln wie lange ich das, was ich liebe tatsächlich noch mit Gewinn ausführen kann. Das Video hat mir wieder gezeigt, das eine KI nie und nimmer einen Entwickler mit Erfahrung ersetzen kann :)
Sehr gutes Video. Werde ich demnächst mal meinen Kollegen schicken, wenn sie wieder die nächste Spezial-Konfiguration einführen wollen... :-) Ich kämpfe tatsächlich schon lange darum, genau diese Probleme zu vermeiden, und stoße dabei nicht selten auf totales Unverständnis.
Die Komplexität entsteht ja durch die Kombinatorik. Um diese einigermaßen in den Griff zu bekommen haben wir uns dazu entschieden eine Art Präprozessor einzusetzen der im Build integriert ist. Im Quellcode sind dann alle Varianten enthalten, aber nicht mehr alle Kombinationen möglich. Unerlaubte Kombinationen fallen sofort beim Build auf (fail early) und nicht erst beim Kunden. Dies hilft schon viel auch wenn der Quellcode unübersichtlicher bleibt und der Build aufwändiger wird, aber diese Nachteile wachsen nun linear und nicht exponentiell. Wünschte dies wäre nativ in die Programmiersprache und Compiler (bei uns Java und Kotlin) integriert.
Man muss zu einem Kunden auch mal nein sagen können. Es gibt Kunden, auf deren Umsätze ich im Nachhinein verzichten würde, nur wegen des angerichteten Chaos. Heute lehne ich alles ab, was nicht auch für alle anderen Kunden einen Mehrwert hat. Damit bin ich unterm Strich weitaus erfolgreicher.
Das Problem hatten wir auch vor ca. 5 Jahren (die Software ist ca. 20 Jahre alt). Mittlerweile haben das Problem sehr gut in den Griff bekommen. 1. durch automatisierte Testsysteme beim Kunden, damit der Kunde oder Consultant Test's erstellen und damit auch das Release welches eingespielt werden sollte vorher getestet werden kann. Bei einem Kunden sind es sogar ca. 1,5 Millionen Integrationstests. 2. durch ca. tausend UnitTests in der CI/CD in der Entwicklung, da das aber aber nicht gereicht hatte wurden noch 3. IntegrationsTest die Nächtlich auf den 3 wichtigen Branch'n laufen. 4. Wir haben nach und nach Features die Entwickler mal eingebaut zurück gebaut und Migrationen machen müssen.
@31redorange08 der Vertrieb hat dieses Test-Feature sogar verkauft, 1 Jahr später war es natürlich Kostenlos. Denn der Kunde konnte damit die Software und ihren Output selber testen. Zur deiner Frage: die Software hat Dokumente für z.b. ein Auftragsdokument, Fertigungsdokument oder Maschinendaten erzeugt. Das hab ich einfach als PDF in einer Datenbank abgespeichert und danach dann in nächtlichen Lauf erneut erstellt und gegen das Original mittels PDF Vergleich abgeglichen. Von diesen Daten hat der Kunde dank kleinem Tool ca. 26 Tausend generiert. Als nächstes kann die App Bilder generieren, also wurden auch hier Bilder einfach in einer Datenbank abgespeichert und mittels Bildvergleich kann dann abgeglichen werden, ob es noch genauso ist wie vorher. Das sind aktuell ca. 4 Tausend Tests. Merkmalsvergleich ca. 5 Tausend Test, RestApi sage und schreibe 7 Tests und dann kommt noch der Stammdaten Test. Der Kunde hat in seiner Datenbank Daten. Bewegungsdaten sowie Stammdaten z.b. ein Artikel. Belege sind erstmal egal. Aber Stammdaten wie z.B. Artikel, Gruppen, etc. kann man super testen und damit kommen die restlichen Tests zustande. z.B. ein einfacher Test war: hat der Artikel eine korrekte ArtikelNr, oder eine deutsche Beschreibung. Dann kommt man schnell auf solche Zahlen.
@@31redorange08vielleicht greift dir DSVGO nicht, und man lässt einfach die Historie immer wieder durch laufen? Aber alle 5 Jahre im Schnitt ändern sich ja die gewünschten Testresultate .
@@svenbuckbesch3959 1. Schreibe schlechte Software, damit der Kunde genervt davon ist 2. Verkaufe teure Test-Software zu deiner schlechten Software, um die schlechte Software vom Kunden testen zu lassen => Profit
@ lach, na ich bin zu 100% im HO, und bei uns wirst Du leider nicht gewesen sein. Aber diese Story passt leider. Ich kämpfe die ganze Zeit für Besserung. Aber immer kommen die gleichen Antworten👍👍
Es gibt sehr anpassungsfähige Software, zum Beispiel: Betriebssysteme und Hardware: Treiber sind eine Art Plugin Linux Distributionen: User Interface kann aus verschiedenen Bausteinen kombiniert werden, aber der Linux Kernel ist derselbe Excel: Mehrere mehr oder weniger kleine Programmiersprachen für Erweiterungen Wenn das Management oder der Vertrieb solche Software kennt hilft das auch bei der Kommunikation.
Wo ich ergänzen würde: Transparenz seitens der Entwicklung, was ein neues Feature wirklich kostet (Wartung, Erweiterung, längerfristige Kosten) ist nicht gerade einfach. Hier liegt wahrscheinlich der Hund begraben. Mit genug Transparenz könnte korrekt gesteuert werden. Nur kann die keiner liefern. Support weiss nicht, wieviel mehr Bugs reinkommen. Vertrieb weiss nicht wieviel mehr support gebraucht wird. usw... denke die Kette lässt sich ganz schön weit fortführen. Erfahrung kann hier etwas helfen, aber eben nicht komplett abdecken. Metriken wären da toll. Aber welche ist die Richitge, und wird sie richtig gefüttert? Das klingt für mich nach einem spannenden Gespräch!
Ja da ist schon etwas wahres dran, aber als Architekt sollte ich bei der menge des Anpassung schon Aussagen treffen können, was das für die Qualitätsattribute bedeutet, die ich zu verantworten habe.
@@DavidTielke hm... wenn man als Architekt aber in die Rolle "gerutscht" ist, dann klappt das nicht so. vor allem bei über Jahre gewachsenen Teams. Ich bin gerade dran bei meinem Chef ein Coaching von dir für ihn zu bekommen. Mal schauen ob ich genug Überzeugungsarbeit leisten kann. ;-)
Transparenz kann nicht nur keiner liefern, die will auch keiner hören. Da stellst du ja direkt das ganze business model der Firma in Frage wenn du mit realistischen zahlen kommst.
Ich empfehle: Konsolidierung der config und die toggles wieder ausbauen, wenn xie configuration lange nicht gewechselt wurde oder 80/90% identisch ist..
David, das kommt mir alles so bekannt vor. In der Vergangenheit war bei uns dann die Lösung, dass man den Kunden dann gleich noch Consulting mit verkaufen kann, das das Produkt dann konfiguriert. Da skaliert dann aber irgendwann nicht mehr, da schließlich die Anzahl der Consultants begrenzt ist. So 100%ig hat man auch leider nicht daraus gelernt. Es wird aber heute mehr einheitliche Konfiguration verwendet. Das “Lustige” ist, ich habe von Bekannten gehört, dass die Konkurrenzprodukte wohl noch schlimmer sind, so dass wir tatsächlich gar nicht so schlecht dastehen.
Das Problem sind die Varianten. Jede Konfiguration ist eine Potenz x^y. Tue es einfach nicht, sondern a) überzeuge den Kunden vom Standard oder b) biete allen Kunden mehr aber gleich an. Du kannst auch aus jeder Konfiguration ein eigenes Produkt machen. Aber auch diese muss man testen. Vielleicht mit Libraries arbeiten. Aber jede Änderung kann die "eigenen Produkte" instabil machen. Das zu testen ist auch sehr aufwendig und mit einfachen Tests nicht umsetzbar. Jedoch möglich. Stell dir mal vor Microsoft würde Outlook für jeden Kunden individuell zuschneiden. Eher nicht. Da ist "friss oder stirb" die wirtschaftlichere Variante. Also besser lernen nein zu sagen.
Die Geschäftsführung muss die Interessen von Vertrieb, Design, Entwickler, Management, ... gegeneinander abwägen, sodass am Ende alle klar kommen und Gewinn erwirtschaftet wird. Hier wurde eindeutig Vertrieb zu sehr priorisiert, zum Nachteil von allen anderen.
Ich sehe hier kein Problem. Respektive, dass ist einfach zu lösen. Pro Kunde ein Konfigurationsfile. Pro Kunde ein branch. Per Git die Kundenbranches regelmässig zusammenführen und testen (bei jeder aktiven Kombination der Konfigurationsoptionen). Checkliste der Cross-Cutting-Concerns einführen und Entwickler schulen diese mit in Betracht zu ziehen. Der Kunden zahlt dann das Feature, die Integration in den Restlichen Code (Merge & Testing). Ein Newsletter informiert Kunden über neue Features. Kunden auf did guten Features umsteigen lassen. So handhaben wir das. Entwickler müssen einfach wissen wie Abkängigkeiten zu vermeiden.
Ich hätte das Video gerne bei uns geteilt aber sicher nicht mit dem unseriösen Thumbnail als ersten Eindruck. Ich verstehe nicht warum du einmal mehr ein so schreckliches AI generiertes Bild wählst, schade :(
Ich denke (aber so ein Projekt hatte ich noch nicht), dass Metriken der Nutzung bei den Kunden wichtig wären, um zu wissen, welche Konfigurationsmöglichkeiten überhaupt genutzt werden und welche man zurückbauen kann. Außerdem würde ich versuchen, Konfigurationen, die exklusiv oder fast exklusiv zusammen genutzt werden, auch im Cluster zu testen. Aber ja, 'nein' sagen wäre eine gute Prävention.
Vielen Dank für dieses großartige Video. Ich muss an der Stelle aber auch meistens von Kunden- oder Anwendersicht problematisch, wenn man eine Software bedienen muss, die nicht wirklich zu dem passt, was man eigentlich braucht und man bestimmte Workarounts benötigt. Da ist es oft verständlich, dass der Vertrieb besonders auf Kundenwünsche Wert legt. Vor der Seite aus betrachtet ist das Problem oft eigentlich sogar noch größer.
Das Problem ist, dass du eine perfekte Software nur für einem Kunden schreiben kannst. Danach ist alles nur noch ein Kompromiss. Jeder Mensch/Kunde hat andere Vorlieben. Wenn du Glück als Entwickler hast, ist ein Großteil der Funktionalität beim Beginn der Entwicklung klar. Sonst wird es meistens lustig. Als User und Kunde weißt du nicht was technisch möglich ist. Wenn es der Vertrieb es auch nicht weiß, und ohne Rückfrage entscheidet, wird es lustig. Häufig gibt es bei Scrum ein Kontakt zwischen Kunde und Entwickler, wenn das bestellte Feature in der Entwicklung ist. Aber da ist es schon lange zu spät, weil man besser das Feature nie an den Kunde verkauft hätte. Softwareentwicklung ist wie ein Hausbau. Nur das die Planung und Vertrieb von Fachfremden durchgeführt werden. Da wird bildliche eine Tiefgarage im Dachgeschoss geplant, und die Zufahrt soll durch das Wohnzimmer oder durch das Badezimmer. Am besten konfigurierbar. Der nächste Kund möchte gerne eine normale Gerage, welche über das Dach erreichbar ist. Optional soll es aber eine Tiefgarage sein. Wobei das Wohnzimmer nur eine Tür haben darf. Da das Entwicklerteam meist nicht über alles Bescheid weißt, fängt es einfach an. Am Anfang ist alles rosa rot, aber auch jeder Entwickler hat seine Vorstellung, wie der Code auszusehen hat. Wenn die Entwickler dann noch Fälle abfangen, die nie bestellt werden, wird es lustig. Und am besten alles mit minimaler Dokumentation. Den Rest kannst du dir vorstellen. Als Kunde sieht man nur die Fassade. Aber häufig entwickeln sich Projekte zum Albtraum für alle Beteiligten. Und irgendwann kann die Fassade nicht mehr alle Katastrophen perfekt abdecken.
@MarvinDuck Vielen Dank für die Erklärung. Das ist mir soweit auch klar. Ich denke hier geht es um das Problem, dass man ein Produkt hat, dass für mehrere Kunden konzipiert ist. Und es klingt für mich so, als wollte man die Software so flexibel halten, dass jeder seine Wunschsoftware bekommt. Ich verstehe total, warum das schief gehen musste, muss aber auch sagen, dass es als Kunde mit unter ein Problem ist, wenn es nicht so ist. Für mich ist dieser Kompromiss, das das Softwareunternehmen da machen muss, ein Dilemma. Das natürlich noch weitere Dinge reinkommen, wie zusätzliche Features oder Minimaldokumentation, kommt ja noch zusätzlich hinzu.
@@saschafrankel9220 Der Kunde ist normalerweise kein Teil der Firma. Es ist Auflage des Vertrieb nicht nur zu verkaufen, sondern es muss auch geklärt werden, was die Entwickler leisten können. Schon das funktioniert meist nicht. Aber auch die meisten Entwickler entwickeln meist ohne Absprache vor sich her. Und zusätzlicher Zeitdruck, verhindert spätere Korrekturen im Code. Srum ist dafür berühmt. Aber das meiste ist kein Problem. Aber wenn wegen den ganzen Ungewissheiten noch Angst dazu kommt, wird es toxisch. Wenn das Team, die Software neu entwickelt, wird es meist besser. Die Entwickler und alle anderen anderen wissen, was sie machen müssen. Aber wenn die ersten neuen Feature kommen fängt der Kreislauf wieder an. Und die Angst kommt zurück. Es gibt auch Ausnahmen, aber tritt zu häufig auf.
@MarvinDuck Danke, das ist mir alles klar. ein Punkt an der Stelle ist eher, dass es auch je nach Produkt durchaus berechtigt ist, Anpassungen vorzunehmen. Ansonsten hat man zwar Probleme weniger, überträgt die dann aber an den Kunden oder deren Kunden, die dann mit der Software umgehen müssen. Das ist natürlich ein Dilemma, das man hier hat.
@saschafrankel9220 Das funktioniert nur, wenn du dich als Vertriebler bei der Verhandlung mit den Kunden mit der Entwicklung kurzschließt. Sonst reagiert die Entwicklung nur. Scrum hat die dumme Angewohnheit, dass es zwar eine Rückkopplung zum Kunden vorgesehen ist. Aber der greift meistens erst, wenn alles zu spät ist. Und zum Teil Vertragsstrafen im Raum stehen.
Das einzige Projekt wo ich KEINE Probleme mit Konfigurations-Chaos hatte, war ein Projekt für einen öffentlichen Auftraggeber. Da war alles bereits vorher schon so komplex und schräg konzipiert, dass man es mit ca. 1000 Zeilen voll mit if-else/ else-if/ switch case etc.. Konstrukten bequem programmieren und testen konnte. Der Gesetzgeber hat es so vorgesehen, also wurde das dann genau so gemacht. Ich habe bis heute nicht verstanden, wozu die vielen sich teilweise überschneidenden Fallunterscheidungen eigentlich gut waren. Meinem fachlichen Ansprechpartner bei der Landebehörde ging es aber genauso, von daher gab es bei der Zusammenarbeit und Abnahme keine Probleme.🙂
Das Problem ist das man von Anfang an nicht dran gedacht hat das aus einer Software ein Frankenstein wird die unendlich in der Form am laufen ist. Hätte man von Anfang an an gewusst im Detail wohin die reise geht, hätte man dort schon vielleicht die Software viel anders entworfen. Daher machen manche firmen auch sowas wie Microsoft, das sie hin und wieder einen grindigen schnitt durchführen der oft meist zu lasten der benutzter endet (meist am ende kurzfristig bis man sich dran gewöhnt hat), aber sie werfen vieles mal weg, um wieder für sich eine Software zu haben die man Managen und auch Planen kann und der Philosophie der entsprechend zeit wieder spiegelt. Kein Entwickler kann heute sagen was so ein Change in x Jahren bedeuten wird. Daher Man sollte von Anfang an auch ein EndOfTime bei Software einplanen, und wenn man diese weiter haben will rechtzeitig auf der Grundlage was existiert, eine neue Software von 0 weg Planen mit dem was zu den Zeitpunkt auch der Standard der zeit entspricht. Dabei kann man dann auch normal entscheiden was weiter beinhaltet soll, dinge die Positiver sind und wichtig ist und das wichtige was wegschmeißen werden kann weil keiner, oder nur 1~2 Kunden bzw. nicht mehr stand der zeit entspricht, da kann dann auch der Verkauf wieder mit reden und aufzeigen was Kunden zu der zeit dann wirklich brauchen oder nicht. Bsp. Die Info bekommt Microsoft meist durch ihren daten krallen die alles protokoliert wie, und was man mit ihren System macht, das was man immer so verflucht da sie immer nach hause telefonieren wollen.
Zitat aus einem Meeting mit dem Vertrieb "Aber der eine Schalter kann doch jetzt nicht das ganze Projekt kaputtmachen." Dass die Software vorher schon zig Mal aufgrund der bereits vorhandenen 500 Checkboxen gestorben ist, die sich gegenseitig überschreiben, das wird dabei gerne ausgeblendet. Das Problem der Fehlersuche, bei der schon der Support verzweifelt raten muss, wie zum Teufel der Kunde genau diesen oder jenen Fehler produziert hat, begnet mir in der Tat häufig. Und das Argument vom Vertrieb ist natürlich immer, dass es mehr Geld bringt ... aber wie du sagst wird nicht über die Folgekosten nachgedacht. Bei externen Services geht es dann auch so weiter. Ob 5 oder 10 APIs angebunden werden ... das ist doch das Gleiche oder? ;-) Ich bin gespannt wann für Vertriebler von Lizenz- und SaaS-Software ein Grundkurs in Programmierung zur Pflicht wird. Selbst einfache Basics und das eigene Erleben von Komplexität könnten sicher helfen, an der ein oder anderen Stelle mehr Verständnis zu haben und strategisch bessere Entscheidungen zu treffen.
@@MasterBoyZs Nicht alles, aber sie sollten zumindest die Basics kennen und mal selbst etwas gebaut haben. Das geht wunderbar auch mit 2-3 Tagen Schulung und schafft schon enorm viel mehr Verständnis.
@@noreading oh ha wenn ich zum Leergang ging, bauchte das nur gelächter, aber wen nich paar Monate was bewegte dann brachte das Aerkennung. naja lass mal gut sein die Vertriebler sind die geilsten, für wenig vents und Hirnmassen aber viel blas viel Kohle...
Bitte keine Grundkurse für Vertriebler, da schlägt der Dunning-Kruger-Effekt zu. Ich hatte schon Kunden und Vertriebler, die meinten, weil sie Grundkenntnisse in Programmierung hatten, abschätzen zu können, dass das auch in einem komplexen Projekt nicht so lange dauern kann. Im Grundkurs fehlen einfach die zusätzlichen Wechselwirkung und die Komplexität von echten produktiven Software-Projekten.
Stell Dir vor die stecken dich in ein Projekt rein, das seit ihren schon in einer Sackgasse steckt und du darfst das wieder gerade biegen und aber es fehlen dazu die Mittel... Wenn es dann am Ende doch läuft, das merkt dann keiner mehr, aber wenn etwas nicht so toll läuft wird bemerkt.
Noch ein schmaler Grat ist die Entscheidung, wo sich der Kunde mit seinen Prozessen sich besser an die gewählte SW anpasst und wo sich besser die SW an den Kunden anpasst.
Ich glaube eins der größten Probleme ist ist in der Tat das Leute nicht die waren Kosten von Softwareentwicklung sehen. Software Entwicklung ist teuer. Aber die Leute denken immer man setzt da einen Code Monkey hin der drei Zeilen Code schreibt und dann rollt der Rubel mit der Software. Fertig! Das man den ganzen Kappes nun für die nächsten 20 Jahre am Leben halten muss wird halt nicht gesehen. Übrigens hab ich schon oft erlebt das aus Entwicklersicht sehr fragwürdige Features nachher der totale Knaller waren und Features die Entwicklung super wichtig fanden beim Kunden ein Rohrkrepierer waren. Aber was ich sehr selten sehe ist, das ein Feature was kaum einer benutzt wieder ausgebaut wird. Das dies auf Dauer eigentlich billiger wäre als es drin zu lassen versteht aber kein Manager.
Anforderungen ändern sich über die Zeit. Sobald man merkt dass man mit der Software nur noch mühsam voran kommt, muss man parallel die Entwicklung des Nachfolgers beginnen. Durch die Erfahrungen und Lektionen aus der vorherigen Entwicklung und den Einsatz neuer Technologien kommt man auch sehr viel schneller voran als man denkt. Vorhandener Programmcode ist nicht so wertvoll wie oft gedacht wird. Ich habe es bisher nie bereut Dinge nochmals programmiert zu haben, weil die neue Implementierung immer besser war als die vorherige. Recycling von Programmcode bedeutet das man in der Gestaltung von Anfang an eingeschränkt ist.
David, du hast die ganze Zeit nur von Developern und Architekten usw gesprochen. Wo ist eigentlich der Projektingenieur? Der schaut ja dass die Prozess und Businesslogik passt und schaut dadurch auch was nun technisch bzw. prozessmäßig, also im Business, realisiert wird. Ich komme immer mehr drauf dass immer weniger in der Technik und viel mehr in der Domäne geplant werden muss!
Also wir haben eine Software as a Service Plattform - und uns leider nie so wirklich mit Tests beschäftigt. Allerdings ist dafür dass deployment und auch die Fehlersuche einfach weil ich mich einfach als derjenige Kunden Nutzer anmelden den Fehler nachstellen und auch selbst schauen kann ob er es behoben ist Punkt und generell designen wir jede Anpassung so, als wäre sie ein Feature für alle Nutzer
Dependency injection or event & mutator pattern could be helpful when customizing for specific clients. Having hooks into a system and never modifying tor a single configuration but instead inserting the ability to modify the behavior then implementing the customization in independent modules. Perhaps look at complex open source software like Drupal that only exists as customized configurable instances.
Hier stellt sich mir die Frage, wo fängt die Standardsoftware an und wo hört sie auf? Customizing sollte von der Produktentwicklung getrennt sein, auch technisch. D.h. es werden nur Features engebaut, die auch wirklich von allen genutzt werden können. Langfristig führen Feature-Flags zu einer zu hohen Komplexität. Wenn dann, sollten diese auch innerhalb der Anwendung aktivierbar sein, um nur ein Deployment-Artefakt für alle Kunden zu haben. Das Customizing könnte auch als ein Service angeboten werden, bei dem der Kunde diese selbst vornimmt. D.h. es braucht Schnittstellen oder eine Standard-Library, die erweitert werden kann. Das kann man dann auch als Abo-Modell fahren.
David: Das ist das erste Deiner Videos, welches mir automatisch mit KI generierter Stimme auf Englisch wiedergegeben wurde. Wahrscheinlich weil mein System und Browser auf Englisch eingestellt sind. Ich weiß nicht, ob Dir das klar ist. Gerade habe ich ein Video einer US-Amerikanerin gesehen, die in Deutschland lebt, ihre Videos aber auf Englisch aufnimmt. Jemand hat in den Kommentaren geschrieben, dass sie bei ihnen mit einer deutschen KI-Stimme spricht und die TH-camrin war sich darüber nicht im Klaren und hatte auch TH-cam keine Erlaubnis dafür gegeben.
Kenne zwei solche Projekte. Eins auf Access-Basis und eins auf Lotus, IBM, whatever gerade Notes-Basis. Und ich spüre schon wieder den Schreikrampf näherkommen wenn ich nur daran denke.
Wäre nicht eine Möglichkeit, das Problem grundsätzlich zu vermeiden, individuelle Kundenanpassungen nur auf Kundenseite durch Berater oderso zu machen und nicht alles in die Code base aufzunehmen?
Warum wurde die Software denn nicht modular strukturiert? Dann wäre es doch durchaus möglich, Bausteine hinzuzufügen, auszutauschen oder zu entfernen (und zwar bis auf Codeebene hinunter), ohne die eigentliche Arbeitsmaschinerie (der Code, der die Grundfunktionen steuert und die Inputs orchestriert) anzutasten. Ich stimme aber zu, dass das grösste Problem einfach das Agreement mit der Kundschaft ist. Wenn man von Anfang an klar macht, dass gewisse Modifikationen einfach nicht drin sind, während man bezüglich des GUI ein gewisses Variationsspektrum einplant, ist das oft (auch wenn erst nach einigem Verhandeln) akzeptabel.
Ist schon richtig mit den Modulen, so lange diese keinen Einfluss auf andere haben und in sich abgeschlossen sind. Dann ist das nicht mehr als Feature an oder aus. Das Gesamtverhalten darf sich nicht ändern.
Redet er hier was von Projektplan! HA! Das ist doch was für Anfänger! Ohne Anforderungen und Plan kann auch nichts schiefgehen! So konfiguriert man! :)
Jede zusätzliche Checkbox, jede zusätzliche Konfiguration verdoppelt die Komplexität der Software. Sehr sehr oft entstehen solche Konfigurationen nur aus der Angst eine Entscheidung zu treffen: machen wir es blau oder machen wir es rot? Ich habs, wir machen es Konfigurierbar! Dem Vertrieb ist die zusätzliche Komplexität komplett egal, gerade wenn man damit wirbt eine extrem anpassbare Software zu haben hat der Vertrieb null Incentives dem Kunden nicht das blaue vom Himmel zu versprechen und das Problem auf die Entwickler abzuwälzen.
@MarvinDuck Na, so wie da sicher nicht bzw. das wäre inzwischen für mich eine Red-Flag weiter zu ziehen, leider war ich damals drauf angewiesen. Als ich 2012 da angefangen habe, hat eine Abteilung noch die "Versionsverwaltung" beim Teamleiter auf dem Rechner gemacht, indem die Änderungen auf Diskette übergeben wurden. Das Kassensystem war vollgewurstet mit "#if Kunde == 'xyz'" und die Businesslogik der Warenwirtschaft war vollständig in T-SQL auf dem Server implementiert. So einen Saftladen habe ich in meiner Karriere weder davor, noch danach erlebt.
@@SunSailor 😂 Habe schon alles erlebt. Nicht alles auf einmal, aber es reicht für mehre lustige Abende. Da ich Projektarbeit mache, rechne ich einfach mit allem. Hat mir schon mehrfach eine praktikable Lösung ermöglicht. Aber manchmal kannst du nur zu schauen, und dir einen neuen Kunden suchen. Sonst treibst du dich auf.
Ein Ansatz ist modular vorzugehen. Nicht im Sinne von modularer Erweiterbarkeit. Sondern im Sinne von, nach Jahren bleibt eh nur noch neu machen. Dann muss weniger auf einmal neu gemacht werden.😂
Man baut halt was grundsätzlich anderes. Man baut eben dann keine Fachanwendung für bspw. Warenwirtschaft sondern eine Anwendung deren (hauptsächliche) Fachlichkeit die Konfigurierbarkeit ist.
Ich kann diese Meinung nur bedingt teilen. Es ist doch klar das eine Software immer erweitert werden muss, schließlich kann man die nicht einfach so lassen und hoffen das man die 30 Jahre verkauft. Und deshalb bekommt jede Software zusätzliche Features und wird komplexer und bringt diese Probleme mit sich. Ob das jetzt ein Feature ist das sich der Kunde gewünscht hat oder eins das man sich selbst ausgedacht hat, spielt dabei keine Rolle. Kundenfeatures werden nur halt gerne gemacht, weil da direkt auch gleich die Entwicklungskosten abgedeckt sind während andere Features zwar oft auch auf Feedback der Kunden basieren aber meist nicht extra bezahlt werden.
Geht nicht unbedingt um weitere Features sondern darum, dass bestehende Features unterschiedlich ausgeführt werden, sodass man teilweise bei einem anderen Feature null erahnen kann, was das für Folgen haben kann. Kenne das auch von einem Produktpartner mit dem wir zusammenarbeiten. Wenn da etwas im Kern angepasst wird, kann es sein, dass das ungeahnte Folgen in einem Kunden-Aufsatz hat (und mit Kunden-Aufsatz ist ein customizing für >100.000 Anwender gemeint).
@@xPliCt86 Ich sehe da keinen Unterschied. Jedes neue Feature birgt die Gefahr von Seiteneffekten. Und wenn eine bestehendes Feature anderes ausgeführt ist es auch nichts anderes als ein neues Feature. Und wenn man das vermeiden will, bleibt als Konsequenz nur das die Software nicht weiter entwickelt wird und das kann nicht die Lösung sein.
@@samsgala4416 Ich denke, dass hängt auch sehr stark vom Produkt ab. Wenn es nur um die Farbe der Schrift geht, die bei jedem Kunden anders sein, dann dürfte das nicht das größte Problem sein, wenn man das nicht total übertreibt, wenn aber sich die Prozesslogik bei jedem Kunden individuell ändern lässt, dann wird das ganze recht schnell so unübersichtlich, dass da keiner mehr neue Features einfügen kann ohne einige Konstelationen zu schrotten. Wobei ich mich dann auch frage, ob das manchmal nicht auch an einer falschen Architektur liegen kann.
Solche Software-Buden, deren Geschäftsmodell auf Anhäufen technischer Schulden beruht, kenne ich nur zu gut. Am Ende gehen die wirtschaftlich immer pleite.
Es gibt kein Unternehmen, welches nicht in diese Probleme rennt. Ich habe ein paar Arbeitgeber durch und es wird immer schlimmer. Als Entwickler weiß man so lange auf die Probleme hin, bis am aufgeben muss. Somit geht Wissen für das Unternehmen flöten. Tja, Pech gehabt.
🤣🤣🤣 Ah verrückt du bist bei uns in der Firma für Beratung? Wir hätte noch das Problem, dass unser Vertrieb Funktionen verkauft welche wir überhaupt noch nicht haben bzw. auch nicht umsetzbar sind. Kläre das doch bitte denen ab 😉
Wir hatten da immer drei Versionen, eine die der Vertriebler dem Kunden verkaufte, eine die, die GF glaubte das wir haben und eine die es wirklich gab. ;-)
Ok, aber die Abgrenzung von SaaS Angeboten zum Lizenzgeschäft kann ich absolut nicht nachvollziehen. Ich kenne keinen SaaS-Service mit breiter fachlicher Funktionalität, der mit wenig Kunden-Parametrisierbarkeit auskommt. Unabhängig vom Lizenzmodell bekommt man keine neuen Kunden, wenn die Anpassungen an Kundenbedarfe nur minimal bis gar nicht möglich sind. Das Hauptproblem hast Du ja benannt: dass neue Parametriesierungsmöglichkeiten zu einem nicht kostendeckenden Preis verkauft werden. Natürlich ist das Testen von Kundenspezifika nicht trivial aber halt auch Teil des Produkt-Business. Mein Anti-Pattern: Parameter implementieren, wenn ich noch keinen konkreten Anwendungsfall für mindestens eine zweite oder dritte Parameterausprägung kenne.
Nur Mietmöglichkeit (Abo) Nutzung ist Shit... Abhänig vom Anbieter ob nicht nach x Monaten einfach die Lizenz geändert wird zum Nachteil vom Kunden oder Massiv die Preise erhöht werden.... Darauf die Firma bzw Einkommen Abhängig zu machen ist schon sehr Riskant wie manche Firmen merken mussten.... Alleine mal des Projekt Sichern und nach x Jahren neu einspielen ggfs in einer VM und oh Software ist "Abgelaufen".... kein Nutzen/Zugriff mehr so möglich.... und für eine Alte Software macht auch nicht jeder Hersteller dann nen neue Lizenz falls die Firma noch Vorhanden ist.....
Leistungsloses Einkommen per Abo war ja durchaus mal eine Methode Geld zu verdienen, und für Startups, die in den ersten 2 Jahren die Investorengelder verbrannt haben, ist das auch sinnvoll. Richtige Firmen, die von echten Unternehmern und nicht "Managern" geführt werden, sind aber nachhaltig am Markt und da ist ein Einmalkauf die sinnvollere Variante - sehr zum Leidwesen der Softwareanbieter, die schon gute Argumente für den Versionswechsel haben müssen - für die Softwarepflege gibt es ja Maintenanceverträge. Aber den Mist mit Abo und keinen Zugriff auf Daten ohne Abo oder bei Pleite des Anbieters haben wir als massives Risiko erkannt und entsprechend andere Anbieter eingeführt.
Ja das ist leider die heutige Inkompetenz der Softwarearchitekten. Leider wird es im Studium gar nicht mehr richtig beigebracht. Stattdessen soll man das neuste Framework nutzen, bla bla bla. Hohe testbarkeit, Abstraktion und das umsetzen von klassischen Prinzipien helfen bei der impl der Software. Auch im Nachhinein oder wenn noch gar nicht alle usecases bekannt sind.
Du sprichst anfangs von GUI Konfig Kram und erweckst den Eindruck, dass dies nicht lange in Indien entwickelt wird. Weed und Kaffee ist keine gute Kombi 😂
Das hatten wir bei einer Firma, wo ich war. Da konnte man bei einigen Konfigurationsvariablen Funktionsaufrufe reinschreiben. Beim Debuggen hat man sich dann von Code in Konfigurationsdateien und von dort in anderen Code gehangelt.
Genau so ein Projekt habe ich auch verzapft, aber ohne Druck von nem C-Level und mit Anlauf :D Wir haben das Projekt von Anfang an so designed, dass wir damit diverse Fälle abdecken können (Input-Module mit Flags, geteilte Logik mit wenigen Settings, Output-Module mit Flags), aber mit jedem weiteren Fall kamen auch einige Sonderfälle mit rein, die wir dann versucht haben in unser modulares System rein zu quetschen. Das ist aber ein generelles Problem bei vielen Projekten. Die Domäne des Kunden lernt man erst über die Zeit wirklich kennen und in dem Moment wo man diese vollständig durchblickt hat, ist es oftmals schon viel zu spät, deswegen ist gutes Anforderungsmanagement das wichtigste und muss aktiv passieren, denn der Kunde hat in den allermeisten Fällen selbst keine Ahnung was er will, das fällt ihm ein wenn das Projekt abgeschlossen ist.
Oh ja mit Anforderungsmanagement haben wir total gute Erfahrungen gemacht. Da wurde extra ein Anforderungsanalytiker eingestellt. Der hat dann die Aufgabe bekommen, zu analysieren, ob wir die Anforderungen erfüllen. Hat dann etliche Monate damit verbracht, die (Tausenden) Anforderungen einfach als Frage zu formulieren. Also so richtig stur durchgezogen, zb die Anforderung "Dateisysteme müssen ein Journal verwenden" wurde dann "verwenden Dateisysteme ein Journal?" Also, natürlich erst noch mal ganz ernst und nachdenklich kucken und dann erst aufschreiben. Das hat er über ein Jahr lang gemacht, dann fertig gemeldet. Alle haben sich auf die Schulter geklopft dass wir endlich das Anforderungsmanagement im Griff haben 😂 Die offenen Fragen (also alle Tausende) sollten dann nur noch vom Entwickler eben beantwortet werden 😂
Das nennt man dann wohl Bottom-Up Requirements Engineering und reiht sich neben dem Obstkorb in der flachen Hierarchie ein :D Das passiert wenn man auf solche Positionen Leute setzt, die eigentlich keine Ahnung haben, was ihre Aufgabe ist und diese sich dann ne Beschäftigung ausdenken. Besonders gut finde ich Consultants, die ohne Berufserfahrung oder sonstige Qualifikation frisch aus dem Studium kommen und dann Leute mit deutlich mehr Berufserfahrung beraten sollen oder Strukturen & Prozesse aufbauen sollen, die sie selbst noch nie gelebt haben.
Hui ja mir kommt da auch ein Projekt in meiner Ex-Firma in Erinnerung. YAGNI haben sie dort nie gehört, alles auf maximale Flexibilität und Anpassbarkeit designed ohne guten Grund und es war dann ein wahnsinniger Krampf, irgendwas sinnvolles damit zu machen.
@@JanBebendorf das sind auch die, die es nie besser konnten und dann oben sitzen und keine Ahnung in echt haben. Aber es gibt auch die laten hasen, die Ahnung haben.
Und irgendwann schläg die eigene Uhr 12 und man sitzt auf den Stuhl in der mitte...
Erfahrungen sich nacher, die zählen und die Rechnungen zahlen. Wissen ist relativ...
Starkes Video! Extrem verständlich erklärt und sehr nachvollziehbar. Welche architekturellen Mittel und Frameworks meinst du bei 11:43 um solche hoch konfigurierbaren Anwendungen einigermaßen stabil zu halten?
Das größte Problem ist, wenn die Anwendung ein großer amorpher Haufen ist. Wenn ich 1000 konfigurierbare Optionen habe, die sich potentiell alle gegenseitig beeinflussen können, ist das Projekt tot. Wenn ich aber 32 klar voneinander getrennte orthogonale Komponenten mit je 32 konfigurierbaren Optionen habe, dann ist das zwar auch schon sehr komplex, aber durchaus noch managebar.
Ich denke, dass Software sogar besser werden kann, dadurch, dass man sie anpassen kann. Man muss das dann halt alles mit sehr wenig Kopplung arbeiten. Das bedeutet führt dann natürlich zu mehr Arbeitsaufwand beim Testen aber man muss sich das halt sehr gut bezahlen lassen.
Die 32 Komponenten muss man aber auch erst mal planen und implementieren, es ist ein Kampf Abhängigkeiten zu verhindern und am Ende hat man wenn man nicht höllisch aufpasst doch nur wieder ein Wollkneul von Abhängigkeiten.Und außerdem hat man dann eh nicht 32 Komponenten mit 32 Optionen, sondern eine Komponente mit 900 Optionen und 24 mit null.
Meistens ist leider zu Anfang nicht absehbar, welche Varianten man brauchen wird. Oft werden im Lauf der Zeit auch Änderungen durch Rechtsverordnungen o.ä. erforderlich.
@@343max Dass alle einzelnen Komponenten exakt gleich viele Abhängigkeiten haben, ist natürlich sehr unwahrscheinlich. Es wird sich ziemlich sicher eine Pareto-Verteilung ergeben.
Aber auch dann gilt: wenn die Config-Optionen sich über die Interfacegrenzen hinaus auswirken, müssen benachbarte Komponenten theoretisch auch immer mit jeder Kombination an Optionen integrativ getestet werden. Das wird sehr sehr schnell zu aufwändig. Wenn Config-Optionen nur einen lokalen Effekt haben, reichen "Unit Tests" für die Komponenten und sehr wenige integrative Smoke-Tests, die sicherstellen, dass die Interfaces nicht auseinanderdriften.
Und man muss nicht alles an Tag 1 planen. Man muss nur genügend erfahrene Leute im Team haben, die es rechtzeitig erkennen und laut schreien, wenn Dinge zu stark gekoppelt sind. Und dann muss man diesen Leuten die Zeit geben, aufzuräumen und Sachen wieder zu entwirren. Und wenn man das lange genug nicht macht, hat man irgendwann so viele Edge cases und hacky Features eingebaut, für die sich immer jeweils exakt 1 Kunde finden lässt, für den das unverzichtbar ist, dass man es nie wieder aufgeräumt bekommt.
Hallo David, vielen Dank für das Video.
Was mich interessieren würde, wie konntet ihr das Problem lösen?
Mich würde ebenfalls interessieren, wie du die Analyse und die Ergebnisse dem Kunden aufbereitest hast?
Vielen Dank fürs teilen.
Meiner Meinung nach gibt es 3 Möglichkeiten.
1. Du gibst dich mit deinem Kundenstamm zufrieden und fügst nicht für jeden einzelnen Kunden für sie spezifische Funktionen hinzu sondern nur, wenn einige Kunden diese Funktion haben wollen/brauchen
2. Du implementierst eine Art Plugin-System (Je nach Möglichkeit) um neue Funktionalitäten bzw. Komponenten für die jeweiligen Kunden hinzuzufügen
3. Du gehst nach Robert C. Martin vor und schreibst für jede neue Funktion auch wirklich eine neue Funktion und erweiterst nicht immer die gleiche bzw. baust diese noch schlimmer um. Auch nicht die schönste Lösung, gerade wenn man einen Bug in der Hauptfunktion findet und man alle Funktionen anpassen darf aber so behält man wenigstens den Überblick welche Funktion wofür sind (Wenn es gut Dokumentiert wird)
Super Video, werd das mit verlinken wenn ich den nächsten Changerequest ablehne 😀
"Potenzieller Kunde sagt, wenn wir in unsere _Standardsoftware_ noch DAS für ihn einbauen, dann kauft er es ga-ran-tiert!" - Vertriebler. Immer.
Solang der Vertrieb, bevor er was verkauft, noch mit der Entwicklung redet und klärt was das bedeutet, ist das doch OK, und auch mal nein sagt wenn er die Infos hat.
Ein Problem ist es nur dann, wenn es verkauft wird ohne auch einmal Rücksprache darüber zu halten, das so gar nicht mal möglich ist oder nur dahin geschustert werden kann bzw. mehr Probleme macht als es soll.
Branch pro Kunde, und es wurde Cherry Picking betrieben
Auch schon erlebt... :D
In welche Branche nutzt man multiple branches?
@@MasterBoyZs ... Sondermaschinenbau
Und dann ewig rebases ... auch nicht die Lösung. Besser ein vernünftig modulares Pluginsystem.
@@hansdietrich1496 oh je da sollte man wirklich mal überlegen, ob man mit Zinnsoldaten oder mit Drohnen in die Schlacht zieht...
Ich würd ja glatt sagen Du warst bei mir in der Firma, aber wir haben keinen Architekten. Die Prämisse meiner Firma ist, der Kunde ist König und es wird jede gewünschte Anpassung umgesetzt.
Ergebnis kann man sich denken 😄
Interessant, was du hier erzählst, trifft genau die Probleme in dem letzten Projekt, in dem ich gearbeitet habe. Da frage ich mich nun, auf wie viele Projekte genau dieses Problem anteilsmäßig zutrifft.
Das kommt drauf wie genau du die Projekte definierst, es ist ja nicht jedes Projekt finanziell so stark von Anpassungen und konfiguration abhängig. Aber sobald Anpassungen und Konfiguration reinkommen, wächst diese gefährliche Komponente.
Ich habe in den letzten 10 Jahren in verschiedenen SaaS-Unternehmen gearbeitet, die alle auch vorher das alte Lizenzmodell gefahren haben und zumindest für diesen Unternehmenstyp würde ich die Quote auf 80% oder mehr schätzen. Bei Unternehmen die als SaaS gestartet sind, gibt es das Problem auch, aber in meinen persönlichen Erfahrungen nicht so krass. Dort wird oft von Anfang an mehr Zeit in Schulung investiert, so dass der Kunde teilweise auch seine Prozesse an die Software anpasst und nicht nur umgekehrt.
Verückterweise kenne ich das Problem aus der umgekehrten Perspektive. Ich bin ein "normaler" Entwickler und hatte zeitweise die Angewohnheit, Konfigurationseinstellungen hinzuzufügen, die einfach unnötig waren, ungefähr nach dem Motto "wenn man das einstellen kann, brauchen wir nachher kein Update/Release, wenn wir das ändern wollen". Es war dann der Architekt, der gemeint hat, das brauchen wir nicht, setz einen default Wert und entferne die Konfiguration. Zum Glück hatten es diese unnötigen Änderungen (fast) nie über einen orphaned feature branch hinaus geschafft. 😅
Meistens ist der Vertriebler näher an der Geschäftsführung als die Entwicklung. Das schlimmste was ich mal erlebt habe war dass die Entwickler anfingen für jede Kundenanpassung einen eigenen Branch zu machen und man aus den Branches dann die Deployments gebaut hat. Natürlich wurden die Branches dann irgendwann nicht mehr in den master zurückgeführt weil die Mergeaufwände zu hoch wurden. So hatte man dann irgendwann x Stände von der Software und jede etwas anders. War dann bei der Versionierung die Hölle. Weil Version 1.0.5 bei Kunde X war halt nicht Version 1.0.5 bei Kunde Y :D. Herrlich war das.
Ich bin der Meinung, dass das Problem bei dem Design und der Architektur liegt.
Wenn das Hauptunterscheidungsmerkmal die Konfigurierbarkeit ist, dann muss die Software das unterstützen.
Ich vermute aber, dass die Konfigurierbarkeit kein ursprüngliches Feature war, sonder erst nach und nach dazu gebaut wurde.
Jain, wie im Video gesagt gibt es natürlich architekturelle Mittel um das abzufedern, aber das hat halt alles seine Grenzen - ein System was nur darauf aufbaut, ist fast unmöglich über lange zeit wirtschaftlich zu betreiben.
das geht dann so weit, das man sagt, kannst du lieber ganz neu und dann richtig machen.
@@MasterBoyZs wenn Konfiguration als Geschäftsmodell wichtig ist, dann ist das sicher die beste Entscheidung.
@@DavidTielke Lösungen wie SAP und andere ERP/CRM Lösungen usw. beweisen durchaus, dass Software konfigurierbar programmiert werden kann, wenn man sie dafür auslegt.
Ich glaub auch. Allerdings muss man diese Art der Programmierung und Architektur usw erst mal kennen und dann auch noch können.
Ich kann ein wenig fühlen wie man das machen könnte aber wenn ich die herkömmliche Programmierung hernehme dann sollte es sehr schwer bzw. fast unmöglich sein komplexe Konfigurierungen mittels DEV umzusetzen.
Vl. ein wenig Described programming mit Function programming gemixt. dann könnte es vl. gut gehen.
Ein Problem entsteht doch erst, wenn man 3-10 Consultants braucht, weil keiner allein mehr alle Customizingmöglichkeiten überblickt. Klassische ERP Software halt und umgekehrt scheint es ja eine Art Jobmotor zu sein :)
Wir haben genau dieses problem und es treibt mich noch in den Wahnsinn.
Nicht nur ist der branch für den wichtigsten kunden komplett nicht mehr ohne bestimmte daten vom kunden in der datenbank testbar, sondern es wurden hunderte changes auf dem production server gemacht die nicht commited wurden. Und wie auch in dem video besprochen wurden dutzende konfigurierbare features rein gepackt die dann nur für den kunden aktiviert werden. Das arbeiten an dieser Software ist der reinste alptraum...
Tut mir (wirklich) leid das zu hören....
das kommt davon wenn man programmieren sagt, weil software entwicklen, etwas anderes ist. Das sollte man richtig machen oder es in andere Hände geben lassen.
Ich fühle 100% mit dir. Wir haben im vergangenen Jahr eine Umstellung auf AWS gemacht, nachdem es vorher viele einzelne Installationen waren, bei denen es auch Sonderlösungen in Unterordnern und "Spezialeinträge" in der Datenbank gab. Ich würde sagen wir haben so 95% davon eliminiert und der Rest kommt sicher irgendwann noch als Zombie hoch, wenn jemand den falschen Knopf drückt.
Es ist mühselig ... sehr mühselig soetwas aufzuräumen ... aber ich verspreche dir es lohnt sich. Es ist ein gutes Gefühl, wenn man so einen Dämon bezwingen kann, auch wenn man dafür eine dicke Rüstung und viel Ausdauer benötigt.
Ich drücke die Daumen, dass ihr das in dem Projekt noch in den Griff bekommt. :)
Trigger auf der Datenbank, die dann Felder missbrauchen, sind auch spitze. Oder Erweiterungen von Datenbanken um Felder, die nur der Projektierer kennt.
Auch die Projektierung kann Software zum Platzen bringen und für Service wie auch Entwicklung nicht nachvollziehbares Verhalten erzeugen.
@@MasterBoyZs Ja, irgendwann wird der große Knall kommen. Vielleicht merkt die Firma ja dann mal dass es so nicht weiter gehen kann. Aber am Ende leiden vermutlich wieder die Entwickler darunter...
Danke dir wirklich vom Herzen. Der Kommentar ist natürlich out of Kontext, aber durch das ganze KI Drama und den negativen Input, den man oftmals von anderen Leuten hört, war ich doch hin und wieder am Zweifeln wie lange ich das, was ich liebe tatsächlich noch mit Gewinn ausführen kann. Das Video hat mir wieder gezeigt, das eine KI nie und nimmer einen Entwickler mit Erfahrung ersetzen kann :)
Sehr gutes Video. Werde ich demnächst mal meinen Kollegen schicken, wenn sie wieder die nächste Spezial-Konfiguration einführen wollen... :-) Ich kämpfe tatsächlich schon lange darum, genau diese Probleme zu vermeiden, und stoße dabei nicht selten auf totales Unverständnis.
Das Video würde ich gern an unseren Kunden schicken, dass das Problem nicht nur bei SAP Projekten existieren, sondern bei allen Software Produkten.
Die Komplexität entsteht ja durch die Kombinatorik. Um diese einigermaßen in den Griff zu bekommen haben wir uns dazu entschieden eine Art Präprozessor einzusetzen der im Build integriert ist.
Im Quellcode sind dann alle Varianten enthalten, aber nicht mehr alle Kombinationen möglich. Unerlaubte Kombinationen fallen sofort beim Build auf (fail early) und nicht erst beim Kunden. Dies hilft schon viel auch wenn der Quellcode unübersichtlicher bleibt und der Build aufwändiger wird, aber diese Nachteile wachsen nun linear und nicht exponentiell.
Wünschte dies wäre nativ in die Programmiersprache und Compiler (bei uns Java und Kotlin) integriert.
Man muss zu einem Kunden auch mal nein sagen können. Es gibt Kunden, auf deren Umsätze ich im Nachhinein verzichten würde, nur wegen des angerichteten Chaos. Heute lehne ich alles ab, was nicht auch für alle anderen Kunden einen Mehrwert hat. Damit bin ich unterm Strich weitaus erfolgreicher.
Oder zumindest einen Kompromiss vorschlagen, damit man selbst auch davon profitiert.
Das Problem hatten wir auch vor ca. 5 Jahren (die Software ist ca. 20 Jahre alt). Mittlerweile haben das Problem sehr gut in den Griff bekommen. 1. durch automatisierte Testsysteme beim Kunden, damit der Kunde oder Consultant Test's erstellen und damit auch das Release welches eingespielt werden sollte vorher getestet werden kann. Bei einem Kunden sind es sogar ca. 1,5 Millionen Integrationstests. 2. durch ca. tausend UnitTests in der CI/CD in der Entwicklung, da das aber aber nicht gereicht hatte wurden noch 3. IntegrationsTest die Nächtlich auf den 3 wichtigen Branch'n laufen. 4. Wir haben nach und nach Features die Entwickler mal eingebaut zurück gebaut und Migrationen machen müssen.
Herzlichen Glückwunsch an euren Vertrieb, dass euer Kunde eure Arbeit übernimmt. Aber wie erstellt man 1,5 Millionen Tests in fünf Jahren?
@31redorange08 der Vertrieb hat dieses Test-Feature sogar verkauft, 1 Jahr später war es natürlich Kostenlos. Denn der Kunde konnte damit die Software und ihren Output selber testen. Zur deiner Frage: die Software hat Dokumente für z.b. ein Auftragsdokument, Fertigungsdokument oder Maschinendaten erzeugt. Das hab ich einfach als PDF in einer Datenbank abgespeichert und danach dann in nächtlichen Lauf erneut erstellt und gegen das Original mittels PDF Vergleich abgeglichen. Von diesen Daten hat der Kunde dank kleinem Tool ca. 26 Tausend generiert. Als nächstes kann die App Bilder generieren, also wurden auch hier Bilder einfach in einer Datenbank abgespeichert und mittels Bildvergleich kann dann abgeglichen werden, ob es noch genauso ist wie vorher. Das sind aktuell ca. 4 Tausend Tests. Merkmalsvergleich ca. 5 Tausend Test, RestApi sage und schreibe 7 Tests und dann kommt noch der Stammdaten Test. Der Kunde hat in seiner Datenbank Daten. Bewegungsdaten sowie Stammdaten z.b. ein Artikel. Belege sind erstmal egal. Aber Stammdaten wie z.B. Artikel, Gruppen, etc. kann man super testen und damit kommen die restlichen Tests zustande. z.B. ein einfacher Test war: hat der Artikel eine korrekte ArtikelNr, oder eine deutsche Beschreibung. Dann kommt man schnell auf solche Zahlen.
@@31redorange08vielleicht greift dir DSVGO nicht, und man lässt einfach die Historie immer wieder durch laufen? Aber alle 5 Jahre im Schnitt ändern sich ja die gewünschten Testresultate .
@@svenbuckbesch3959
1. Schreibe schlechte Software, damit der Kunde genervt davon ist
2. Verkaufe teure Test-Software zu deiner schlechten Software, um die schlechte Software vom Kunden testen zu lassen
=> Profit
Wie lange laufen die Pipelines nachts ?
Du David, bist Du gerade in der Firma, in der ich arbeite? Das kommt mir so bekannt vor.
Wenn ich letzte Woche Montag bis Mittwoch bei euch im Haus war, könnte das sein... :D
@ lach, na ich bin zu 100% im HO, und bei uns wirst Du leider nicht gewesen sein. Aber diese Story passt leider.
Ich kämpfe die ganze Zeit für Besserung. Aber immer kommen die gleichen Antworten👍👍
Bitte mal erklären was es für Lösungen gibt für solche Software. Also was gibt es jetzt für Möglichkeiten? Vielen Dank! Für deine Videos.
Es gibt sehr anpassungsfähige Software, zum Beispiel:
Betriebssysteme und Hardware: Treiber sind eine Art Plugin
Linux Distributionen: User Interface kann aus verschiedenen Bausteinen kombiniert werden, aber der Linux Kernel ist derselbe
Excel: Mehrere mehr oder weniger kleine Programmiersprachen für Erweiterungen
Wenn das Management oder der Vertrieb solche Software kennt hilft das auch bei der Kommunikation.
Wo ich ergänzen würde:
Transparenz seitens der Entwicklung, was ein neues Feature wirklich kostet (Wartung, Erweiterung, längerfristige Kosten) ist nicht gerade einfach.
Hier liegt wahrscheinlich der Hund begraben. Mit genug Transparenz könnte korrekt gesteuert werden. Nur kann die keiner liefern. Support weiss nicht, wieviel mehr Bugs reinkommen. Vertrieb weiss nicht wieviel mehr support gebraucht wird. usw... denke die Kette lässt sich ganz schön weit fortführen.
Erfahrung kann hier etwas helfen, aber eben nicht komplett abdecken. Metriken wären da toll. Aber welche ist die Richitge, und wird sie richtig gefüttert?
Das klingt für mich nach einem spannenden Gespräch!
Ja da ist schon etwas wahres dran, aber als Architekt sollte ich bei der menge des Anpassung schon Aussagen treffen können, was das für die Qualitätsattribute bedeutet, die ich zu verantworten habe.
@@DavidTielke hm... wenn man als Architekt aber in die Rolle "gerutscht" ist, dann klappt das nicht so.
vor allem bei über Jahre gewachsenen Teams.
Ich bin gerade dran bei meinem Chef ein Coaching von dir für ihn zu bekommen.
Mal schauen ob ich genug Überzeugungsarbeit leisten kann. ;-)
Transparenz kann nicht nur keiner liefern, die will auch keiner hören.
Da stellst du ja direkt das ganze business model der Firma in Frage wenn du mit realistischen zahlen kommst.
Ich empfehle: Konsolidierung der config und die toggles wieder ausbauen, wenn xie configuration lange nicht gewechselt wurde oder 80/90% identisch ist..
David, das kommt mir alles so bekannt vor. In der Vergangenheit war bei uns dann die Lösung, dass man den Kunden dann gleich noch Consulting mit verkaufen kann, das das Produkt dann konfiguriert. Da skaliert dann aber irgendwann nicht mehr, da schließlich die Anzahl der Consultants begrenzt ist. So 100%ig hat man auch leider nicht daraus gelernt. Es wird aber heute mehr einheitliche Konfiguration verwendet.
Das “Lustige” ist, ich habe von Bekannten gehört, dass die Konkurrenzprodukte wohl noch schlimmer sind, so dass wir tatsächlich gar nicht so schlecht dastehen.
was wären denn gute architekturmittel um dieses problem zu lösen ? Kennt ihr da gute Bücher?
Das Problem sind die Varianten. Jede Konfiguration ist eine Potenz x^y. Tue es einfach nicht, sondern a) überzeuge den Kunden vom Standard oder b) biete allen Kunden mehr aber gleich an.
Du kannst auch aus jeder Konfiguration ein eigenes Produkt machen. Aber auch diese muss man testen. Vielleicht mit Libraries arbeiten. Aber jede Änderung kann die "eigenen Produkte" instabil machen. Das zu testen ist auch sehr aufwendig und mit einfachen Tests nicht umsetzbar. Jedoch möglich.
Stell dir mal vor Microsoft würde Outlook für jeden Kunden individuell zuschneiden. Eher nicht. Da ist "friss oder stirb" die wirtschaftlichere Variante. Also besser lernen nein zu sagen.
Ah, und ich dachte das wäre hier bei uns besonders kurios. Scheint also ein weit verbreitetes Problem zu sein. :D
Die Geschäftsführung muss die Interessen von Vertrieb, Design, Entwickler, Management, ... gegeneinander abwägen, sodass am Ende alle klar kommen und Gewinn erwirtschaftet wird.
Hier wurde eindeutig Vertrieb zu sehr priorisiert, zum Nachteil von allen anderen.
Ich sehe hier kein Problem. Respektive, dass ist einfach zu lösen. Pro Kunde ein Konfigurationsfile. Pro Kunde ein branch. Per Git die Kundenbranches regelmässig zusammenführen und testen (bei jeder aktiven Kombination der Konfigurationsoptionen). Checkliste der Cross-Cutting-Concerns einführen und Entwickler schulen diese mit in Betracht zu ziehen. Der Kunden zahlt dann das Feature, die Integration in den Restlichen Code (Merge & Testing). Ein Newsletter informiert Kunden über neue Features. Kunden auf did guten Features umsteigen lassen. So handhaben wir das. Entwickler müssen einfach wissen wie Abkängigkeiten zu vermeiden.
Ich hätte das Video gerne bei uns geteilt aber sicher nicht mit dem unseriösen Thumbnail als ersten Eindruck. Ich verstehe nicht warum du einmal mehr ein so schreckliches AI generiertes Bild wählst, schade :(
Dem kann ich nur zustimmen, der AI generierte Quatsch an sich und in dem Fall auch das konkrete Bild.
Ich denke (aber so ein Projekt hatte ich noch nicht), dass Metriken der Nutzung bei den Kunden wichtig wären, um zu wissen, welche Konfigurationsmöglichkeiten überhaupt genutzt werden und welche man zurückbauen kann.
Außerdem würde ich versuchen, Konfigurationen, die exklusiv oder fast exklusiv zusammen genutzt werden, auch im Cluster zu testen. Aber ja, 'nein' sagen wäre eine gute Prävention.
Die Frage die sich mir stellt ist: was ist die Lösung zu der riesen Software? Refactoring und Software modular programmieren?
Vielen Dank für dieses großartige Video. Ich muss an der Stelle aber auch meistens von Kunden- oder Anwendersicht problematisch, wenn man eine Software bedienen muss, die nicht wirklich zu dem passt, was man eigentlich braucht und man bestimmte Workarounts benötigt. Da ist es oft verständlich, dass der Vertrieb besonders auf Kundenwünsche Wert legt. Vor der Seite aus betrachtet ist das Problem oft eigentlich sogar noch größer.
Das Problem ist, dass du eine perfekte Software nur für einem Kunden schreiben kannst. Danach ist alles nur noch ein Kompromiss. Jeder Mensch/Kunde hat andere Vorlieben.
Wenn du Glück als Entwickler hast, ist ein Großteil der Funktionalität beim Beginn der Entwicklung klar. Sonst wird es meistens lustig.
Als User und Kunde weißt du nicht was technisch möglich ist. Wenn es der Vertrieb es auch nicht weiß, und ohne Rückfrage entscheidet, wird es lustig.
Häufig gibt es bei Scrum ein Kontakt zwischen Kunde und Entwickler, wenn das bestellte Feature in der Entwicklung ist.
Aber da ist es schon lange zu spät, weil man besser das Feature nie an den Kunde verkauft hätte.
Softwareentwicklung ist wie ein Hausbau. Nur das die Planung und Vertrieb von Fachfremden durchgeführt werden. Da wird bildliche eine Tiefgarage im Dachgeschoss geplant, und die Zufahrt soll durch das Wohnzimmer oder durch das Badezimmer. Am besten konfigurierbar. Der nächste Kund möchte gerne eine normale Gerage, welche über das Dach erreichbar ist. Optional soll es aber eine Tiefgarage sein. Wobei das Wohnzimmer nur eine Tür haben darf.
Da das Entwicklerteam meist nicht über alles Bescheid weißt, fängt es einfach an. Am Anfang ist alles rosa rot, aber auch jeder Entwickler hat seine Vorstellung, wie der Code auszusehen hat.
Wenn die Entwickler dann noch Fälle abfangen, die nie bestellt werden, wird es lustig. Und am besten alles mit minimaler Dokumentation.
Den Rest kannst du dir vorstellen. Als Kunde sieht man nur die Fassade. Aber häufig entwickeln sich Projekte zum Albtraum für alle Beteiligten. Und irgendwann kann die Fassade nicht mehr alle Katastrophen perfekt abdecken.
@MarvinDuck Vielen Dank für die Erklärung. Das ist mir soweit auch klar. Ich denke hier geht es um das Problem, dass man ein Produkt hat, dass für mehrere Kunden konzipiert ist. Und es klingt für mich so, als wollte man die Software so flexibel halten, dass jeder seine Wunschsoftware bekommt.
Ich verstehe total, warum das schief gehen musste, muss aber auch sagen, dass es als Kunde mit unter ein Problem ist, wenn es nicht so ist. Für mich ist dieser Kompromiss, das das Softwareunternehmen da machen muss, ein Dilemma.
Das natürlich noch weitere Dinge reinkommen, wie zusätzliche Features oder Minimaldokumentation, kommt ja noch zusätzlich hinzu.
@@saschafrankel9220 Der Kunde ist normalerweise kein Teil der Firma.
Es ist Auflage des Vertrieb nicht nur zu verkaufen, sondern es muss auch geklärt werden, was die Entwickler leisten können.
Schon das funktioniert meist nicht. Aber auch die meisten Entwickler entwickeln meist ohne Absprache vor sich her. Und zusätzlicher Zeitdruck, verhindert spätere Korrekturen im Code. Srum ist dafür berühmt.
Aber das meiste ist kein Problem. Aber wenn wegen den ganzen Ungewissheiten noch Angst dazu kommt, wird es toxisch.
Wenn das Team, die Software neu entwickelt, wird es meist besser.
Die Entwickler und alle anderen anderen wissen, was sie machen müssen. Aber wenn die ersten neuen Feature kommen fängt der Kreislauf wieder an. Und die Angst kommt zurück.
Es gibt auch Ausnahmen, aber tritt zu häufig auf.
@MarvinDuck Danke, das ist mir alles klar. ein Punkt an der Stelle ist eher, dass es auch je nach Produkt durchaus berechtigt ist, Anpassungen vorzunehmen. Ansonsten hat man zwar Probleme weniger, überträgt die dann aber an den Kunden oder deren Kunden, die dann mit der Software umgehen müssen.
Das ist natürlich ein Dilemma, das man hier hat.
@saschafrankel9220 Das funktioniert nur, wenn du dich als Vertriebler bei der Verhandlung mit den Kunden mit der Entwicklung kurzschließt.
Sonst reagiert die Entwicklung nur. Scrum hat die dumme Angewohnheit, dass es zwar eine Rückkopplung zum Kunden vorgesehen ist. Aber der greift meistens erst, wenn alles zu spät ist.
Und zum Teil Vertragsstrafen im Raum stehen.
Das einzige Projekt wo ich KEINE Probleme mit Konfigurations-Chaos hatte, war ein Projekt für einen öffentlichen Auftraggeber.
Da war alles bereits vorher schon so komplex und schräg konzipiert, dass man es mit ca. 1000 Zeilen voll mit if-else/ else-if/ switch case etc.. Konstrukten bequem programmieren und testen konnte. Der Gesetzgeber hat es so vorgesehen, also wurde das dann genau so gemacht.
Ich habe bis heute nicht verstanden, wozu die vielen sich teilweise überschneidenden Fallunterscheidungen eigentlich gut waren.
Meinem fachlichen Ansprechpartner bei der Landebehörde ging es aber genauso, von daher gab es bei der Zusammenarbeit und Abnahme keine Probleme.🙂
Zum Glück ändern sich Gesetze nie … 😁
Das Problem beginnt wenn einer sagt „da muss man doch nur…“
Mein Chef sagt immer dem Kunden das haben wir fertig in der Schublade das sind wenige Mausklicks 😂
Es beginnt da nur, wenn der Satz von einem Entwickler kommt.
Mach doch 'mal eben' - redflag
@@31redorange08 nö, es gibt Personen, die setzen sich da einfach durch, egal was vom Fach aus kommt und gesagt wird.
Das Problem ist das man von Anfang an nicht dran gedacht hat das aus einer Software ein Frankenstein wird die unendlich in der Form am laufen ist. Hätte man von Anfang an an gewusst im Detail wohin die reise geht, hätte man dort schon vielleicht die Software viel anders entworfen.
Daher machen manche firmen auch sowas wie Microsoft, das sie hin und wieder einen grindigen schnitt durchführen der oft meist zu lasten der benutzter endet (meist am ende kurzfristig bis man sich dran gewöhnt hat), aber sie werfen vieles mal weg, um wieder für sich eine Software zu haben die man Managen und auch Planen kann und der Philosophie der entsprechend zeit wieder spiegelt.
Kein Entwickler kann heute sagen was so ein Change in x Jahren bedeuten wird. Daher Man sollte von Anfang an auch ein EndOfTime bei Software einplanen, und wenn man diese weiter haben will rechtzeitig auf der Grundlage was existiert, eine neue Software von 0 weg Planen mit dem was zu den Zeitpunkt auch der Standard der zeit entspricht. Dabei kann man dann auch normal entscheiden was weiter beinhaltet soll, dinge die Positiver sind und wichtig ist und das wichtige was wegschmeißen werden kann weil keiner, oder nur 1~2 Kunden bzw. nicht mehr stand der zeit entspricht, da kann dann auch der Verkauf wieder mit reden und aufzeigen was Kunden zu der zeit dann wirklich brauchen oder nicht.
Bsp. Die Info bekommt Microsoft meist durch ihren daten krallen die alles protokoliert wie, und was man mit ihren System macht, das was man immer so verflucht da sie immer nach hause telefonieren wollen.
Zitat aus einem Meeting mit dem Vertrieb "Aber der eine Schalter kann doch jetzt nicht das ganze Projekt kaputtmachen." Dass die Software vorher schon zig Mal aufgrund der bereits vorhandenen 500 Checkboxen gestorben ist, die sich gegenseitig überschreiben, das wird dabei gerne ausgeblendet. Das Problem der Fehlersuche, bei der schon der Support verzweifelt raten muss, wie zum Teufel der Kunde genau diesen oder jenen Fehler produziert hat, begnet mir in der Tat häufig. Und das Argument vom Vertrieb ist natürlich immer, dass es mehr Geld bringt ... aber wie du sagst wird nicht über die Folgekosten nachgedacht. Bei externen Services geht es dann auch so weiter. Ob 5 oder 10 APIs angebunden werden ... das ist doch das Gleiche oder? ;-)
Ich bin gespannt wann für Vertriebler von Lizenz- und SaaS-Software ein Grundkurs in Programmierung zur Pflicht wird. Selbst einfache Basics und das eigene Erleben von Komplexität könnten sicher helfen, an der ein oder anderen Stelle mehr Verständnis zu haben und strategisch bessere Entscheidungen zu treffen.
Der Trend geht zu Softwarevertriebsingenieur, also man muss alles etwas studiert haben...
@@MasterBoyZs Nicht alles, aber sie sollten zumindest die Basics kennen und mal selbst etwas gebaut haben. Das geht wunderbar auch mit 2-3 Tagen Schulung und schafft schon enorm viel mehr Verständnis.
@@noreading oh ha wenn ich zum Leergang ging, bauchte das nur gelächter, aber wen nich paar Monate was bewegte dann brachte das Aerkennung. naja lass mal gut sein die Vertriebler sind die geilsten, für wenig vents und Hirnmassen aber viel blas viel Kohle...
Bitte keine Grundkurse für Vertriebler, da schlägt der Dunning-Kruger-Effekt zu. Ich hatte schon Kunden und Vertriebler, die meinten, weil sie Grundkenntnisse in Programmierung hatten, abschätzen zu können, dass das auch in einem komplexen Projekt nicht so lange dauern kann. Im Grundkurs fehlen einfach die zusätzlichen Wechselwirkung und die Komplexität von echten produktiven Software-Projekten.
Folgekosten lassen sich wunderbar über Jahre vergraben oder einzelnen Mitarbeitern in die Schuhe schieben.
Dann muss aber schon einiges im Argen sein :)
Stell Dir vor die stecken dich in ein Projekt rein, das seit ihren schon in einer Sackgasse steckt und du darfst das wieder gerade biegen und aber es fehlen dazu die Mittel... Wenn es dann am Ende doch läuft, das merkt dann keiner mehr, aber wenn etwas nicht so toll läuft wird bemerkt.
Noch ein schmaler Grat ist die Entscheidung, wo sich der Kunde mit seinen Prozessen sich besser an die gewählte SW anpasst und wo sich besser die SW an den Kunden anpasst.
Ich glaube eins der größten Probleme ist ist in der Tat das Leute nicht die waren Kosten von Softwareentwicklung sehen. Software Entwicklung ist teuer. Aber die Leute denken immer man setzt da einen Code Monkey hin der drei Zeilen Code schreibt und dann rollt der Rubel mit der Software. Fertig! Das man den ganzen Kappes nun für die nächsten 20 Jahre am Leben halten muss wird halt nicht gesehen. Übrigens hab ich schon oft erlebt das aus Entwicklersicht sehr fragwürdige Features nachher der totale Knaller waren und Features die Entwicklung super wichtig fanden beim Kunden ein Rohrkrepierer waren. Aber was ich sehr selten sehe ist, das ein Feature was kaum einer benutzt wieder ausgebaut wird. Das dies auf Dauer eigentlich billiger wäre als es drin zu lassen versteht aber kein Manager.
Spannend! Danke
Anforderungen ändern sich über die Zeit. Sobald man merkt dass man mit der Software nur noch mühsam voran kommt, muss man parallel die Entwicklung des Nachfolgers beginnen. Durch die Erfahrungen und Lektionen aus der vorherigen Entwicklung und den Einsatz neuer Technologien kommt man auch sehr viel schneller voran als man denkt.
Vorhandener Programmcode ist nicht so wertvoll wie oft gedacht wird. Ich habe es bisher nie bereut Dinge nochmals programmiert zu haben, weil die neue Implementierung immer besser war als die vorherige. Recycling von Programmcode bedeutet das man in der Gestaltung von Anfang an eingeschränkt ist.
SaaS Architekt hier: Wir machen keine Kundenhacks. Entweder es wird ein normales Feature oder es existiert nicht.
David, du hast die ganze Zeit nur von Developern und Architekten usw gesprochen. Wo ist eigentlich der Projektingenieur? Der schaut ja dass die Prozess und Businesslogik passt und schaut dadurch auch was nun technisch bzw. prozessmäßig, also im Business, realisiert wird. Ich komme immer mehr drauf dass immer weniger in der Technik und viel mehr in der Domäne geplant werden muss!
Also wir haben eine Software as a Service Plattform - und uns leider nie so wirklich mit Tests beschäftigt. Allerdings ist dafür dass deployment und auch die Fehlersuche einfach weil ich mich einfach als derjenige Kunden Nutzer anmelden den Fehler nachstellen und auch selbst schauen kann ob er es behoben ist Punkt und generell designen wir jede Anpassung so, als wäre sie ein Feature für alle Nutzer
Dependency injection or event & mutator pattern could be helpful when customizing for specific clients.
Having hooks into a system and never modifying tor a single configuration but instead inserting the ability to modify the behavior then implementing the customization in independent modules.
Perhaps look at complex open source software like Drupal that only exists as customized configurable instances.
Hier stellt sich mir die Frage, wo fängt die Standardsoftware an und wo hört sie auf? Customizing sollte von der Produktentwicklung getrennt sein, auch technisch. D.h. es werden nur Features engebaut, die auch wirklich von allen genutzt werden können. Langfristig führen Feature-Flags zu einer zu hohen Komplexität. Wenn dann, sollten diese auch innerhalb der Anwendung aktivierbar sein, um nur ein Deployment-Artefakt für alle Kunden zu haben.
Das Customizing könnte auch als ein Service angeboten werden, bei dem der Kunde diese selbst vornimmt. D.h. es braucht Schnittstellen oder eine Standard-Library, die erweitert werden kann. Das kann man dann auch als Abo-Modell fahren.
Ich liebe deine Weltuntergangsvideos 😂😂
Man müsste erfassen können, welche Konfigurationen tatsächlich wie häufig vorkommen. So könnte man Prioritäten setzen.
David: Das ist das erste Deiner Videos, welches mir automatisch mit KI generierter Stimme auf Englisch wiedergegeben wurde. Wahrscheinlich weil mein System und Browser auf Englisch eingestellt sind. Ich weiß nicht, ob Dir das klar ist. Gerade habe ich ein Video einer US-Amerikanerin gesehen, die in Deutschland lebt, ihre Videos aber auf Englisch aufnimmt. Jemand hat in den Kommentaren geschrieben, dass sie bei ihnen mit einer deutschen KI-Stimme spricht und die TH-camrin war sich darüber nicht im Klaren und hatte auch TH-cam keine Erlaubnis dafür gegeben.
Nein, war es mir nicht - danke! Das klingt ja furchtbar... hab mich schon über die ganzen englischen Kommentare gewundert...
Kenne zwei solche Projekte. Eins auf Access-Basis und eins auf Lotus, IBM, whatever gerade Notes-Basis. Und ich spüre schon wieder den Schreikrampf näherkommen wenn ich nur daran denke.
Wäre nicht eine Möglichkeit, das Problem grundsätzlich zu vermeiden, individuelle Kundenanpassungen nur auf Kundenseite durch Berater oderso zu machen und nicht alles in die Code base aufzunehmen?
Nennt sich Schnittstellen 😅
Warum wurde die Software denn nicht modular strukturiert? Dann wäre es doch durchaus möglich, Bausteine hinzuzufügen, auszutauschen oder zu entfernen (und zwar bis auf Codeebene hinunter), ohne die eigentliche Arbeitsmaschinerie (der Code, der die Grundfunktionen steuert und die Inputs orchestriert) anzutasten. Ich stimme aber zu, dass das grösste Problem einfach das Agreement mit der Kundschaft ist. Wenn man von Anfang an klar macht, dass gewisse Modifikationen einfach nicht drin sind, während man bezüglich des GUI ein gewisses Variationsspektrum einplant, ist das oft (auch wenn erst nach einigem Verhandeln) akzeptabel.
Ist schon richtig mit den Modulen, so lange diese keinen Einfluss auf andere haben und in sich abgeschlossen sind. Dann ist das nicht mehr als Feature an oder aus. Das Gesamtverhalten darf sich nicht ändern.
Kommunikation ist alles.
und ab und zu "Nein" sagen ebenfalls!
I love this thumbnail it is awesome
Redet er hier was von Projektplan! HA! Das ist doch was für Anfänger!
Ohne Anforderungen und Plan kann auch nichts schiefgehen! So konfiguriert man!
:)
Jede zusätzliche Checkbox, jede zusätzliche Konfiguration verdoppelt die Komplexität der Software. Sehr sehr oft entstehen solche Konfigurationen nur aus der Angst eine Entscheidung zu treffen: machen wir es blau oder machen wir es rot? Ich habs, wir machen es Konfigurierbar! Dem Vertrieb ist die zusätzliche Komplexität komplett egal, gerade wenn man damit wirbt eine extrem anpassbare Software zu haben hat der Vertrieb null Incentives dem Kunden nicht das blaue vom Himmel zu versprechen und das Problem auf die Entwickler abzuwälzen.
Selbst der Vertrieb weis doch am Ende gar nicht mehr, was die Software alles kann 😂
Bei dem ganzen "spezial" und "sonder" musste ich an Justus Jonas von den drei ??? Denken.
"Das ist wirklich ein spezial gelagerter Sonderfall"
😂
was ich schon erlebt habt: 💣
Na gut dass der Architekt verzweifelt, normalerweise verzweifeln die Entwicker...
Klingt nach meinem ehemaligen Arbeitgeber im Bereich Warenwirtschaft- und Kassensysteme in Osthessen...
Den Arbeitgeber kannst du frei wählen, alles was schiefgehen kann, findest in den meisten IT-Firmen auch.
Leider.
@MarvinDuck Na, so wie da sicher nicht bzw. das wäre inzwischen für mich eine Red-Flag weiter zu ziehen, leider war ich damals drauf angewiesen.
Als ich 2012 da angefangen habe, hat eine Abteilung noch die "Versionsverwaltung" beim Teamleiter auf dem Rechner gemacht, indem die Änderungen auf Diskette übergeben wurden. Das Kassensystem war vollgewurstet mit "#if Kunde == 'xyz'" und die Businesslogik der Warenwirtschaft war vollständig in T-SQL auf dem Server implementiert. So einen Saftladen habe ich in meiner Karriere weder davor, noch danach erlebt.
@@SunSailor Das hört sich schon sehr wüst aus.
@MarvinDuck Sag ich ja.
@@SunSailor 😂
Habe schon alles erlebt. Nicht alles auf einmal, aber es reicht für mehre lustige Abende. Da ich Projektarbeit mache, rechne ich einfach mit allem. Hat mir schon mehrfach eine praktikable Lösung ermöglicht. Aber manchmal kannst du nur zu schauen, und dir einen neuen Kunden suchen. Sonst treibst du dich auf.
In kleiner Form ist mir das bei Windows auch schon passiert.
Ein Ansatz ist modular vorzugehen. Nicht im Sinne von modularer Erweiterbarkeit. Sondern im Sinne von, nach Jahren bleibt eh nur noch neu machen. Dann muss weniger auf einmal neu gemacht werden.😂
Man baut halt was grundsätzlich anderes. Man baut eben dann keine Fachanwendung für bspw. Warenwirtschaft sondern eine Anwendung deren (hauptsächliche) Fachlichkeit die Konfigurierbarkeit ist.
Ich sitze auf Kundenseite der die Anpassungen fordert! 😁
Soso 🤔 dann weißt du ja jetzt das Sonderwünsche die Preise für zukünftige Anpassungen steigen lässt 😁
Ich kann diese Meinung nur bedingt teilen. Es ist doch klar das eine Software immer erweitert werden muss, schließlich kann man die nicht einfach so lassen und hoffen das man die 30 Jahre verkauft. Und deshalb bekommt jede Software zusätzliche Features und wird komplexer und bringt diese Probleme mit sich. Ob das jetzt ein Feature ist das sich der Kunde gewünscht hat oder eins das man sich selbst ausgedacht hat, spielt dabei keine Rolle. Kundenfeatures werden nur halt gerne gemacht, weil da direkt auch gleich die Entwicklungskosten abgedeckt sind während andere Features zwar oft auch auf Feedback der Kunden basieren aber meist nicht extra bezahlt werden.
Geht nicht unbedingt um weitere Features sondern darum, dass bestehende Features unterschiedlich ausgeführt werden, sodass man teilweise bei einem anderen Feature null erahnen kann, was das für Folgen haben kann.
Kenne das auch von einem Produktpartner mit dem wir zusammenarbeiten. Wenn da etwas im Kern angepasst wird, kann es sein, dass das ungeahnte Folgen in einem Kunden-Aufsatz hat (und mit Kunden-Aufsatz ist ein customizing für >100.000 Anwender gemeint).
@@xPliCt86 Ich sehe da keinen Unterschied. Jedes neue Feature birgt die Gefahr von Seiteneffekten. Und wenn eine bestehendes Feature anderes ausgeführt ist es auch nichts anderes als ein neues Feature. Und wenn man das vermeiden will, bleibt als Konsequenz nur das die Software nicht weiter entwickelt wird und das kann nicht die Lösung sein.
@@samsgala4416 Ich denke, dass hängt auch sehr stark vom Produkt ab. Wenn es nur um die Farbe der Schrift geht, die bei jedem Kunden anders sein, dann dürfte das nicht das größte Problem sein, wenn man das nicht total übertreibt, wenn aber sich die Prozesslogik bei jedem Kunden individuell ändern lässt, dann wird das ganze recht schnell so unübersichtlich, dass da keiner mehr neue Features einfügen kann ohne einige Konstelationen zu schrotten. Wobei ich mich dann auch frage, ob das manchmal nicht auch an einer falschen Architektur liegen kann.
Dann muss man ab und an mal Cleanup und Refactoring betreiben. Und ja, sonst landet man am Ende dort...
Solche Software-Buden, deren Geschäftsmodell auf Anhäufen technischer Schulden beruht, kenne ich nur zu gut. Am Ende gehen die wirtschaftlich immer pleite.
Leider nein, ich kenne auch ein paar sehr erfolgreiche Firmen, welche das mit Wonne praktizieren. Solange das Geld reicht, wird es auch verbrannt.
@MarvinDuck Zombies gibt es natürlich auch. Die sind noch schlimmer.
Es gibt kein Unternehmen, welches nicht in diese Probleme rennt. Ich habe ein paar Arbeitgeber durch und es wird immer schlimmer. Als Entwickler weiß man so lange auf die Probleme hin, bis am aufgeben muss. Somit geht Wissen für das Unternehmen flöten.
Tja, Pech gehabt.
Konfigurationsdaten sollten vor allem nicht turing-vollständig sein und die Endungen .cs, .cpp, .js oder .py haben.
🤣🤣🤣 Ah verrückt du bist bei uns in der Firma für Beratung? Wir hätte noch das Problem, dass unser Vertrieb Funktionen verkauft welche wir überhaupt noch nicht haben bzw. auch nicht umsetzbar sind. Kläre das doch bitte denen ab 😉
Wir hatten da immer drei Versionen, eine die der Vertriebler dem Kunden verkaufte, eine die, die GF glaubte das wir haben und eine die es wirklich gab. ;-)
Ok, aber die Abgrenzung von SaaS Angeboten zum Lizenzgeschäft kann ich absolut nicht nachvollziehen. Ich kenne keinen SaaS-Service mit breiter fachlicher Funktionalität, der mit wenig Kunden-Parametrisierbarkeit auskommt. Unabhängig vom Lizenzmodell bekommt man keine neuen Kunden, wenn die Anpassungen an Kundenbedarfe nur minimal bis gar nicht möglich sind. Das Hauptproblem hast Du ja benannt: dass neue Parametriesierungsmöglichkeiten zu einem nicht kostendeckenden Preis verkauft werden. Natürlich ist das Testen von Kundenspezifika nicht trivial aber halt auch Teil des Produkt-Business. Mein Anti-Pattern: Parameter implementieren, wenn ich noch keinen konkreten Anwendungsfall für mindestens eine zweite oder dritte Parameterausprägung kenne.
JO😀
Was denkst du über das aktuelle Chat GPT o1 ?
hört sich nach DATEV an... xD
Nur Mietmöglichkeit (Abo) Nutzung ist Shit...
Abhänig vom Anbieter ob nicht nach x Monaten einfach die Lizenz geändert wird zum Nachteil vom Kunden oder Massiv die Preise erhöht werden....
Darauf die Firma bzw Einkommen Abhängig zu machen ist schon sehr Riskant wie manche Firmen merken mussten....
Alleine mal des Projekt Sichern und nach x Jahren neu einspielen ggfs in einer VM und oh Software ist "Abgelaufen".... kein Nutzen/Zugriff mehr so möglich.... und für eine Alte Software macht auch nicht jeder Hersteller dann nen neue Lizenz falls die Firma noch Vorhanden ist.....
Leistungsloses Einkommen per Abo war ja durchaus mal eine Methode Geld zu verdienen, und für Startups, die in den ersten 2 Jahren die Investorengelder verbrannt haben, ist das auch sinnvoll. Richtige Firmen, die von echten Unternehmern und nicht "Managern" geführt werden, sind aber nachhaltig am Markt und da ist ein Einmalkauf die sinnvollere Variante - sehr zum Leidwesen der Softwareanbieter, die schon gute Argumente für den Versionswechsel haben müssen - für die Softwarepflege gibt es ja Maintenanceverträge.
Aber den Mist mit Abo und keinen Zugriff auf Daten ohne Abo oder bei Pleite des Anbieters haben wir als massives Risiko erkannt und entsprechend andere Anbieter eingeführt.
Sehr gutes Video, sehr grausames Thumbnail.
Ja das ist leider die heutige Inkompetenz der Softwarearchitekten. Leider wird es im Studium gar nicht mehr richtig beigebracht. Stattdessen soll man das neuste Framework nutzen, bla bla bla.
Hohe testbarkeit, Abstraktion und das umsetzen von klassischen Prinzipien helfen bei der impl der Software. Auch im Nachhinein oder wenn noch gar nicht alle usecases bekannt sind.
Unabhängig vom super vorgetragenen Thema -- du hast ständig die Hände vorm Gesicht, das irritiert total....
danke - ja ist mir auch aufgefallen, die Kamera war leider zu niedrig eingestellt :(
Hört sich an wie unsere Software 😂. Hersteller wurde von den Amis gekauft und jetzt muessen wir alle Umlaute loeschen.
"sehr, sehr viele Restfehler", klingt nach grünen Bananen!!! 😂
Genau das ist das Thema nächste Woche :D
Die Software war 80% yaml und 20% Code XD
Ich kann mir das nicht anschauen. Irgendwie is das Video auf Englisch und schlecht übersetzt.
if ($kunde == "Abc") machDies; else machDas
Du sprichst anfangs von GUI Konfig Kram und erweckst den Eindruck, dass dies nicht lange in Indien entwickelt wird. Weed und Kaffee ist keine gute Kombi 😂
Am besten Packt man in die Konfiguration auch noch Code rein. 🤮😭
Das hatten wir bei einer Firma, wo ich war. Da konnte man bei einigen Konfigurationsvariablen Funktionsaufrufe reinschreiben. Beim Debuggen hat man sich dann von Code in Konfigurationsdateien und von dort in anderen Code gehangelt.
Da war doch was vor nicht all zu langer Zeit bei Java ...