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...
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.
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.
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. 😅
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...
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.
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?
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.
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.
@ 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👍👍
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 :)
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 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 😄
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.
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
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.
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.
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.
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.
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.
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.
Ich empfehle: Konsolidierung der config und die toggles wieder ausbauen, wenn xie configuration lange nicht gewechselt wurde oder 80/90% identisch ist..
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.🙂
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.
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.
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!
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.
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.
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
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.
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.
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 :(
🤣🤣🤣 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. ;-)
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.
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.
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.
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.
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.
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.
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...
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.
"Potenzieller Kunde sagt, wenn wir in unsere _Standardsoftware_ noch DAS für ihn einbauen, dann kauft er es ga-ran-tiert!" - Vertriebler. Immer.
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.
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...
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. 😅
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...
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.
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?
Super Video, werd das mit verlinken wenn ich den nächsten Changerequest ablehne 😀
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.
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.
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👍👍
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 :)
Das Video würde ich gern an unseren Kunden schicken, dass das Problem nicht nur bei SAP Projekten existieren, sondern bei allen Software Produkten.
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 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 😄
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.
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 ?
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.
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.
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.
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.
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.
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.
was wären denn gute architekturmittel um dieses problem zu lösen ? Kennt ihr da gute Bücher?
Ich empfehle: Konsolidierung der config und die toggles wieder ausbauen, wenn xie configuration lange nicht gewechselt wurde oder 80/90% identisch ist..
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 … 😁
Spannend! Danke
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.
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.
Ah, und ich dachte das wäre hier bei uns besonders kurios. Scheint also ein weit verbreitetes Problem zu sein. :D
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!
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.
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.
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
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 😂😂
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.
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.
Man müsste erfassen können, welche Konfigurationen tatsächlich wie häufig vorkommen. So könnte man Prioritäten setzen.
Kommunikation ist alles.
und ab und zu "Nein" sagen ebenfalls!
🤣🤣🤣 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. ;-)
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.
Ich sitze auf Kundenseite der die Anpassungen fordert! 😁
was ich schon erlebt habt: 💣
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.
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.
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.
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.
Selbst der Vertrieb weis doch am Ende gar nicht mehr, was die Software alles kann 😂
Was denkst du über das aktuelle Chat GPT o1 ?
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.
Na gut dass der Architekt verzweifelt, normalerweise verzweifeln die Entwicker...
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.
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.
In kleiner Form ist mir das bei Windows auch schon passiert.
Konfigurationsdaten sollten vor allem nicht turing-vollständig sein und die Endungen .cs, .cpp, .js oder .py haben.
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.
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.
I love this thumbnail it is awesome
SaaS Architekt hier: Wir machen keine Kundenhacks. Entweder es wird ein normales Feature oder es existiert nicht.
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.
hört sich nach DATEV an... xD
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 :(
Sehr gutes Video, sehr grausames Thumbnail.
"sehr, sehr viele Restfehler", klingt nach grünen Bananen!!! 😂
Genau das ist das Thema nächste Woche :D
Hört sich an wie unsere Software 😂. Hersteller wurde von den Amis gekauft und jetzt muessen wir alle Umlaute loeschen.
Die Software war 80% yaml und 20% Code XD
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 ...