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.
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 .
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. 😅
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.
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.
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...
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 :)
@ 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👍👍
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. ;-)
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.
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.
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.
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.🙂
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.
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.
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!
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.
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 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.
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.
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 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.
Solche Software-Buden, deren Geschäftsmodell auf Anhäufen technischer Schulden beruht, kenne ich nur zu gut. Am Ende gehen die wirtschaftlich immer pleite.
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.....
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.
🤣🤣🤣 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. ;-)
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.
Super Video, werd das mit verlinken wenn ich den nächsten Changerequest ablehne 😀
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 .
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. 😅
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.
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.
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...
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...
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 :)
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👍👍
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. ;-)
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.
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.
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.
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.🙂
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.
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.
Ah, und ich dachte das wäre hier bei uns besonders kurios. Scheint also ein weit verbreitetes Problem zu sein. :D
Spannend! Danke
Das Video würde ich gern an unseren Kunden schicken, dass das Problem nicht nur bei SAP Projekten existieren, sondern bei allen Software Produkten.
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!
Ich liebe deine Weltuntergangsvideos 😂😂
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.
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 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.
Klingt nach meinem ehemaligen Arbeitgeber im Bereich Warenwirtschaft- und Kassensysteme in Osthessen...
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.
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 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.
Solche Software-Buden, deren Geschäftsmodell auf Anhäufen technischer Schulden beruht, kenne ich nur zu gut. Am Ende gehen die wirtschaftlich immer pleite.
Kommunikation ist alles.
und ab und zu "Nein" sagen ebenfalls!
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.
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.....
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.
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.
hört sich nach DATEV an... xD
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.
"sehr, sehr viele Restfehler", klingt nach grünen Bananen!!! 😂
Genau das ist das Thema nächste Woche :D
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 :(
Selbst der Vertrieb weis doch am Ende gar nicht mehr, was die Software alles kann 😂
🤣🤣🤣 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. ;-)
Die Software war 80% yaml und 20% Code XD
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.