Hello, Guest the thread was called1.1k times and contains 47 replays

last post from 7Saturn at the

Warum ist das Entwickeln von Software manchmal ein Riesenproblem?

  • Weil die Linux-User es genau so haben wollen um sich rühmen zu können, dass sie diesen Krampf bedienen können.

    Das ist ja auch der Grund warum Linux ingesamt so kompliziert gehalten wird. Stell dir mal vor, jeder könnte das bedienen. Nicht auszudenken. :D

    Professionelle Betriebssysteme für den Betrieb von Internet, Kraftwerken, Flugzeugen, Raumfahrt etc. müssen andere Kriterien erfüllen, als solche, mit denen Leute spielen, Filme schauen und vielleicht ein paar Beiträge oder Mails verfassen.

  • Aus meinem Erleben war früher der typische Ablauf zum Einrichten einer Schnittstelle so:

    Manager haben entschieden, dass wir so eine Schnittstelle brauchen. Danach gab es noch noch ein oder 2 Meetings mit den beteiligten Firmen, und danach hatte man einen Ansprechpartner, der das programmiert. Damit ergab sich ein 2-Mann-Team, und man hat das ganze direkt miteinander abgewickelt. Bei Problemen war man "irgendwie" verantwortlich und hat sie gelöst. Man war gleichzeitig Programmierer, Designer, Helpdesk, und was es sonst noch so gibt.


    Heute sieht es eher so aus:

    Die Programmierer von damals sind in Rente, die Programmier-Abteilungen wurden aufgelöst, und man hat nun einen Manager und einen Externen. Der Manager nimmt, was am besten und modernsten klingt und die größten Versprechen gibt. Der sieht eine Webseite mit MVC, C# und Blablabla, die sieht besser aus als ein Textterminal, auch wenn in der Präsentation die Elemente Optionbutton und Label heißen und die wahren Schwierigkeiten nicht im allergeringsten adressiert sind.

    Technik hat auch Inhalt verborgen. Es ist JSon und Standard, dennoch muss man nicht alles in Textfelder packen und sich keine Gedanken über Normalisierung machen. Aber passt schon, ist ja Mongo-DB. Eine Schnittstelle liefert öfters mal Länge/Breite Höhe in Stück. Leider fehlt mir ein zuständiger Ansprechpartner, der das beheben könnte, denn unsere Schnittstelle ist nur noch eine Ausleitung aus einem anderen Datenaustausch, für den andere Verantwortlich sind. Vielleicht gibt es diese Anderen noch, vielleicht sind die als Externe auch am Ende der Systemumstellung verschwunden...


    "Warum ist manchmal das Entwickeln von Software so ein Riesenproblem?"

    - Es klappt ziemlich sicher, wenn einer mit Durchblick und ausreichend Entscheidungsbefugnissen eine tatsächliche Verantwortung trägt. Torvalds trägt so eine Verantwortung, Musk auch, extern für Einzelaufgaben Hinzugekaufte tun das nicht. Manager mit Karrierewünschen ebenfalls nicht, die wollen irgendwann weiterziehen.

    - Verantwortung wird vermieden, man ist nicht zuständig. Probleme könnten in 5 Minuten besprochen und gelöst sein, aber man produziert Tickets und Eskalationen und beteiligt 5 Leute eine Woche in Meetings. Qualitätsmanagement hatte mal einen anderen Sinn.

    - Je größer ein Projekt, desto mehr Teilaufgaben, desto mehr Management-Aufgaben, desto mehr Idioten.

    - Projekte werden zu groß. Heute will man mit einer Software alle Aufgaben eines großen Konzerns auf mehreren Kontinenten erledigen.

    - Je größer ein Unternehmen wird, desto schwieriger ist es, Informationen zu beschaffen. Die Leute erledigen seit Jahrzehnten Ihre Aufgaben, in solchen Zeiträumen entwickeln verschiedene Abteilungen verschiedene Sprachen. Ganz feine Aufgabe, dort alle nötigen Anforderungen zu sammeln und von den unnötigen zu trennen.

    - Die Idee scheint verbreitet, dass schon die Verwendung modernerer Technik Probleme löst. Tut sie nicht.

  • Weil die Linux-User es genau so haben wollen um sich rühmen zu können, dass sie diesen Krampf bedienen können.

    Das ist ja auch der Grund warum Linux ingesamt so kompliziert gehalten wird. Stell dir mal vor, jeder könnte das bedienen. Nicht auszudenken. :D

    Professionelle Betriebssysteme für den Betrieb von Internet, Kraftwerken, Flugzeugen, Raumfahrt etc. müssen andere Kriterien erfüllen, als solche, mit denen Leute spielen, Filme schauen und vielleicht ein paar Beiträge oder Mails verfassen.

    Es ging hier im Linux als erfolgreiches Projekt. Du hast den Kontext nicht verstanden oder warst zu faul, nachzulesen, worauf ich mich bezog.

  • Manchmal könnten die Entwickler auch besser, dürfen aber wegen Vorgaben der Projektleitung nicht - mir wurde da mal der Fall einer Smart Home-App erzählt, die die Vorgabe hatte, nur ein möglichst dünner Wrapper auf dem Webinterface der Steuerzentrale zu sein. Das funktionierte zwar, war aber bei den Benutzern nicht besonders beliebt weil die App dadurch träge war und schnell Probleme mit Verbindungsabbrüchen beim Wechsel zwischen WLAN und Mobilfunk hatte - im Store dümpelte die bei ungefähr 2 Sternen herum. Irgendwann gelang es dann doch irgendwie, das Projektmanagement von einer komplett auf dem Telefon laufenden App zu überzeugen und es wurde alles vom gleichen Team von Grund auf neu geschrieben. Ergebnis: Viel flüssigere Bedienung, begeisterte Benutzer (trotz mancher Probleme in den ersten Releases) und 4,x Sterne-Bewertung im Appstore.

    Ich kenne da jemanden, der was erzält hat. ;)


    Webbasierte Anwendungen sind Stand der Technik. Ordentlich programmiert sind die kein Stück langsamer oder weniger komfortabel als native Anwendungen. Und sie laufen im Browser auf jedem Betriebssystem. Dafür gibt es inzwischen ausgefeilte Frameworks. Das Problem wird gewesen sein, dass das technisch schlecht umgesetzt war. Was dann aber wieder an den Entwicklern lag und nicht an der Projektleitung.


    Wie wurde das dann konkret umgesetzt? Zwei getrennte Apps für iOS und Android? Oder einfach eines der beiden Betriebssysteme ausgespart?


    Wenn Softwareentwickler was verkacken, liegt es natürlich immer an der Projektleitung. :D

    Ich bin seit vielen Jahren Softwareentwickler. Wenn ein Softwareprojekt scheitert, liegt es manchmal an der Projektleitung oder am Management und manchmal an der Unfähigkeit der Entwickler.

  • controlport2

    Changed the title of the thread from “Warum ist das entwickeln von Software manchmal ein Riesenproblem?” to “Warum ist das Entwickeln von Software manchmal ein Riesenproblem?”.
  • Unsere Warenwirtschaft ist ein perfektes Beispiel für das, was die Kollegen schon schrieben:

    Das Ganze basiert auf Navision von Micro$oft (da geht's schon los! :D ).

    Das Problem hieran ist aber, dass diese Software so unglaublich komplex ist, noch dazu NICHT intuitiv zu bedienen und dann noch fehlerträchtig.


    Am einfachsten beschreibe ich das Ganze bildlich:

    pasted-from-clipboard.png


    Heißt: wenn vorne was schief geht, fällt u.U. das Ganze in sich zusammen.

    Im konkreten Fall ist das bei uns so, dass wir schon so manchen Fehler an den Entwickler gemeldet haben, dann kam irgendwann ein Hotfix und nach ein paar Wochen stellte sich heraus, dass woanders im Programm was nicht mehr funzte.


    An diesem Programm arbeiten viele Programmierer selbstständig, natürlich nach Vorgaben. Aber sie arbeiten nicht wirklich ZUSAMMEN, sondern eben "nur am selben Projekt".

    Ich kann mir vorstellen, dass das auch ein großes Problem bei anderer Soft ist.

  • Das Ganze basiert auf Navision von Micro$oft (da geht's schon los! :D ).

    Das Problem hieran ist aber, dass diese Software so unglaublich komplex ist, noch dazu NICHT intuitiv zu bedienen und dann noch fehlerträchtig.

    Schon mal an einem SAP-System gesessen? :D

    Ich kenne keine Software in dieser Klasse, die intuitiv ist.


    Das Problem ist aber auch, dass die Abläufe in den Unternehmen oft sehr komplex sind und die müssen durch solche Software abgebildet werden. Dementsprechend komplex ist dann auch die Software.


    An diesem Programm arbeiten viele Programmierer selbstständig, natürlich nach Vorgaben. Aber sie arbeiten nicht wirklich ZUSAMMEN, sondern eben "nur am selben Projekt".

    Ich kann mir vorstellen, dass das auch ein großes Problem bei anderer Soft ist.

    Genau an so einem Projekt arbeite ich gerade. Im Unternehmen wird SAP eingeführt und wir müssen die Prüfsoftware in der Fertigung an dieses neue ERP-System anpassen.

    Natürlich arbeiten wir nicht mit den SAP-Leute zusammen. Das wäre ineffektiv und wir würden uns auch gar nicht verstehen. SAP hat seine ganz eigenen Bezeichnungen und Begriffe. Und die SAP-Leute kennen unsere fertigungsinternen Abläufe nicht.


    Das macht überhaupt keinen Sinn, beide Team jetzt auf einen gemeinsamen Wissenstand zu bringen. Wieviele Monate will man denn da schulen?


    Stattdessen werden klare Schnittstellen definiert und es gibt Verantwortliche für diese Schnittstellen (auf beiden Seiten).

    Wenn diese Schnittstellen schlecht oder sogar falsch definiert wurden, dann knirscht es hinterher.

  • Hier knirscht es (zu) oft im Gebälk.


    Man merkt, dass diese Software von Programmierern für Programmierer geschrieben wurde - nicht für Endanwender.

    Mir selbst macht das nix - ich hacke seit Cevi-Seiten auf Computern rum und wenn etwas nicht intuitiv ist, hält mich das nicht ab.


    Aber viele andere Kollegen haben mit dem System nach über sechs Jahren immer noch Schwierigkeiten... die Logik dahinter erschließt sich einem manchmal echt nicht. Man kann sie nur hinnehmen.

    Und ja: es ist bekannt in unserer Branche... es gibt *keine* wirklich gute Warenwirtschaft. :D

  • Man merkt, dass diese Software von Programmierern für Programmierer geschrieben wurde - nicht für Endanwender.

    Hört sich an wie Linux. :D

    Also was die Anwendung von MS Bookings angeht und die Datenverwaltung darauf mit Excel, da bin ich Abwender und Programmierer gleichzeitig.

    Darum funktioniert bei uns auch alles. :D


    Naja fast. Heute hatte der Kollege Daten vom Bookings nach Excel importiert und zeigte ihm einen Fehler. Da gab es plötzlich den 32.06.2022, 33.06.2022 und 34.06.2022. :whistling:


    Aber der Programmierer sitzt ja einen Schreibtisch weiter, also war das Problem schnell beseitigt. :thumbsup:


    Passend zum Thema heute auf Golem: https://www.golem.de/news/agil…rammiert-2205-163049.html


  • Ich zitiere mal:

    Quote

    Daher muss man sich dem Ziel iterativ und inkrementell nähern, Annahmen treffen, Hypothesen (Ideen) entwickeln und umsetzen, Messungen durchführen, das Ergebnis bewerten, immer wieder aus Fehlern und Erfolgen lernen und sich an neue Erkenntnisse anpassen. Deshalb wird hier gern auch von Experimenten gesprochen.

    Genau so wurde es doch beim BER gemacht. Also alles ok. :thumbsup:

  • Und die SAP-Leute kennen unsere fertigungsinternen Abläufe nicht.

    SAP-Leute sind Externe? Oder Interne von euch aus einer anderen Abteilung, die sich mit SAP auskennen?

    Ich vermute stark das Erstere.

    Stattdessen werden klare Schnittstellen definiert und es gibt Verantwortliche für diese Schnittstellen (auf beiden Seiten).

    Nach meiner Erfahrung reicht es meist nicht, sich auf eine einzelne Schnittstelle zu beschränken.

    Erst Auftrag, dann die Konstruktion, dann kommen Fertigung, die Kommissionierung/Verpackung, der Versand, und am Ende kommt die Baustelle.

    Und in der Praxis kommt zuerst der Versand: Der soll sagen, wie viele Container eine Maschine haben wird, weil die Kosten Teil der Auftragsvergabe sind.

    Mit einem Fokus auf eine bestimmte Schnittstelle geht ganz sicher was verloren. Ein Fokus auf eine Abteilung... vielleicht klappt es. Es muss halt allen Beteiligten bewusst sein, dass der Versand die Fertigung nach den Maßen von Teilen fragen wird, die nicht mal konstruiert sind. Aber ohne den Blick fürs Ganze ist darin schwer ein Sinn zu finden, und ohne den Sinn zu verstehen wird das nix.


    Dann haben verschiedene Abteilungen verschiedene Schlüsselfelder. Konstruktions-Stücklistenposition, Fertigungs-Auftrags-Position, Materialnummer und Bestellnummer für zugekaufte Teile, sprechende Losteil-Barcodes zum Aufkleben... Und am Ende verändert die Konstruktion ihre Stückliste, die Nummern verändern sich, alle Schnittstellen packen das auch irgendwie - Nur die gedruckten Barcodes machen keinerlei Sinn mehr. Juckt aber keinen mehr, die sind ja schon in der Kiste, und das System ist ja auch sauber.


    Bei solchen Feinheiten können die Meisten nicht mehr so ganz folgen. Und davon ab: Da draußen sind "Programmierer" unterwegs... :gahh:

    Kurz aufs Thema gebracht:
    Manche Sachen sind sehr komplex und schwer in klar getrennte Bereiche zu zerlegen, ohne dann zu sehr zu vereinfacht zu sein. Unter all den Beteiligten finden sich auch "extrem ambitionierte Arbeitsvermeider", die maximal schlecht arbeiten, sich aber gut durchmogeln können.


    Webbasierte Anwendungen sind Stand der Technik. Ordentlich programmiert sind die kein Stück langsamer oder weniger komfortabel als native Anwendungen. Und sie laufen im Browser auf jedem Betriebssystem. Dafür gibt es inzwischen ausgefeilte Frameworks.

    Genau sowas lässt sich einem Manager super verkaufen :thumbsup:

    Praktisch bekommt er dann: Eine Webseite! Man KÖNNTE da ne feine Anwendung in JScript mit Ajax und so basteln, aber er bekommt: Eine Webseite. Also das http-Pingpong mit html, was Navision halt ausspuckt. Das packst Du dann auf steinalte Windows-CE-Scanner, 8*8 cm Bildschirm, und damit schickst Du dann die User mit dicken Arbeitshandschuhen raus in die Welt, wo keine WLan-Ausleuchtung ist. Es war göttlich, sag ich Dir 8o


    Aufs Thema bezogene sehe ich da an Fehlern:

    - Management kennt die Praxis nicht.

    - Management glaubt an "moderne Technik", ohne Computerwissen zu haben.

    - Ziel war nicht, eine optimale Lösung zu finden, sondern was verkaufen zu können.

    - Null Ambition, die Anforderungen zu erkunden, reine Arbeit nach Vorschrift.

  • Die SAP-Leute sind eine Mischung aus Internen und Externen. Wie das anteilig aussieht, weiß ich nicht. Ist nicht meine Baustelle. Wir haben einen internen Ansprechpartner, der sich um unsere Schnittstelle kömmert.


    Was du da beschreibst, klingt nach Auftragsfertigung. Wir fertigen eigene Serienprodukte.


    Uns in der Fertigungen interessieren die restlichen Abläufe nicht. Wir bekommen einen Fertigungsauftrag, fertigen, prüfen und melden die Fertigungsdaten zurück. Ende. Alles andere ist unnützes Wissen.


    Natürlich gibt es zusätzliche Infos zu geplanten neuen Produkten, Planzahlen usw. Das ist aber nicht Teil von Softwareschnittstelle. Sowas wird in Meetings besprochen und abgestimmt.

  • Uns in der Fertigungen interessieren die restlichen Abläufe nicht. Wir bekommen einen Fertigungsauftrag, fertigen, prüfen und melden die Fertigungsdaten zurück. Ende. Alles andere ist unnützes Wissen.

    Vielleicht mal ne Inventur des Ausgangsmaterials? Gibt es Chargen, Schüttgut oder Material mit Seriennummern? Lagerung nach bzw. Entnahme nach Alter? Akkordarbeit? Fertigungsdauer bestimmen? Oder Fertigstellungstermine und Kapazitäten vergleichen, um mal ne Extraschicht einlegen zu können? Maschinen, die automatisch angesteuert werden könnten? Aufträge an andere Fertigungsorte geben, wenn eine Maschine kaputt ist? Gibt es Prüfsiegel, Kundeninspektion oder variable Kundenlogos? Kundenanforderungen zur Markierung der Ware? Für nen Kunden hatten wir mal einen "Abflug-Monitor" mit Startzeit, aktuellem Erfüllungsgrad und geschätzter Fertigstellung für die nächsten X Aufträge.


    Mir fallen viele komplizierte Sachen ein, die die Fertigung betreffen. Bei uns gibt es auch den einfachen Fall: Tablett an der Wand, einmal einloggen und dann nur Auftragsnummer und 2 Knöpfe "Start" und "Fertig" drauf. Eine Schnittstelle dazu wäre was für den Azubi oder Praktikanten, denn die ist von anderen mit größerem Überblick schon vereinfacht worden und funktioniert, weil das passende Werkzeug und Material für die Produkte des Tages von anderen vorbereitet wurden und die Automatische Säge die Aufträge eines Arbeitsplatzes kennt.


    Und ich nehme stark an, dass "Prüfsoftware an SAP anpassen" kompliziert genug für einige Stolperfallen ist und Daten mitschleppt, die erst woanders im Prozess gebraucht werden. Der SAPler, der sich zusammen mit euch drum kümmert, wird 100%ig das Eine oder Andere angesprochen haben, was über den Horizont der Fertigung und Prüfung hinausgegangen ist.

  • Uns in der Fertigungen interessieren die restlichen Abläufe nicht. Wir bekommen einen Fertigungsauftrag, fertigen, prüfen und melden die Fertigungsdaten zurück. Ende. Alles andere ist unnützes Wissen.

    Vielleicht mal ne Inventur des Ausgangsmaterials? Gibt es Chargen, Schüttgut oder Material mit Seriennummern? Lagerung nach bzw. Entnahme nach Alter? Akkordarbeit? Fertigungsdauer bestimmen? Oder Fertigstellungstermine und Kapazitäten vergleichen, um mal ne Extraschicht einlegen zu können? Maschinen, die automatisch angesteuert werden könnten? Aufträge an andere Fertigungsorte geben, wenn eine Maschine kaputt ist? Gibt es Prüfsiegel, Kundeninspektion oder variable Kundenlogos? Kundenanforderungen zur Markierung der Ware? Für nen Kunden hatten wir mal einen "Abflug-Monitor" mit Startzeit, aktuellem Erfüllungsgrad und geschätzter Fertigstellung für die nächsten X Aufträge.

    Keine Sorge. Das was wir brauchen, ist berücksichtigt. Dafür werden wir bezahlt. :D

    Geh einfach mal davon aus, dass ein Betrieb, der SAP einführt, ein Mindestmaß auf Professionalität an den Tag legt und seine eigenen Abläufe kennt.

  • Geh einfach mal davon aus, dass ein Betrieb, der SAP einführt, ein Mindestmaß auf Professionalität an den Tag legt und seine eigenen Abläufe kennt.

    Woher nimmst Du in Deinem Alter diesen Optimismus? ;)
    Nicht aus dem Auge verlieren: "Warum ist das Entwickeln von Software manchmal ein Riesenproblem?" fragt nach den Fallen und Problemen, nicht nach den Beispielen, wo die Entwicklung prima funktioniert hat und wo es überschaubar ist.


    Nun ist das alles ziemlich in die Business-Ecke abgedriftet. Meine Erfahrung dazu ist:
    Kleine Abteilungen kennen ihre Abläufe, und wenn man Glück hat und da auf einen kompetenten Verantwortungsvollen stößt, dann gibt das ein Traumprojekt.


    Aber ein großer Betrieb ist mehr als die Summe seiner einzelnen Abteilungen. Eine große SAP-Einführung braucht eine Armee von Externen und Jahre, die Abläufe hoffentlich halbwegs korrekt herauszufinden und hoffentlich korrekt umzusetzen. Man bekommt es mit kompetenten Verantwortungsvollen zu tun, aber auch mit desinteressierten Anwendern, Saboteuren und politisch motivierten Managern, und man muss damit leben, dass manche Fragen unbeantwortet bleiben und manche Fehler einfach nicht korrigiert werden.

  • Geh einfach mal davon aus, dass ein Betrieb, der SAP einführt, ein Mindestmaß auf Professionalität an den Tag legt und seine eigenen Abläufe kennt.

    Woher nimmst Du in Deinem Alter diesen Optimismus? ;)
    Nicht aus dem Auge verlieren: "Warum ist das Entwickeln von Software manchmal ein Riesenproblem?" fragt nach den Fallen und Problemen, nicht nach den Beispielen, wo die Entwicklung prima funktioniert hat und wo es überschaubar ist.

    Weil das nicht die erste Umstellung dieser Art ist, an der ich beteiligt bin. Und nur für die Fälle kann ich sprechen. Ich weiß nicht, ob das insgesamt gut laufen wird. Das hängt ja eben auch davon ab, dass die anderen ihren Job machen. Darauf habe ich keinen Einfluss. Es gibt klare Zuständigkeiten. Ich bin kein SAP-Spezialist und kann das nicht beurteilen.

  • Also - ich bin jetzt nicht der "Programmierer", allerdings wurden meinerseits etliche "Projekte" begleitet, respektive durchgeführt.


    Das "Dilemma" ist IMMER das Gleiche:


    -> schnell, schnell, schnell -> gleich -> :grab1: (wenn nicht gleich, später sicher!) Die "Zeiträume" sind viel zu eng getaktet, was totaler Blödsinn ist, da das "hinterher arbeiten" das Zehnfache kostet!

    -> unausgegorene Angaben - heisst soviel wie "....steht noch nicht fest.....wird später definiert.....haben wir keine Info...etc. pp)


    Unklarheiten der "Zuständigkeiten" -> IMMER <- ein hin und her geschiebe - jeder will das Goldene Schwein schlachten, aber KEINER will "Verantwortlich" sein :thumbsup:


    Sowie diverse andere - sagen wir mal - Dinge! :pumpkin:

    -----


    Klar! Nix geht "strait" - allerdings wären viele Dinge einfacher, wenn - ja - WENN - von vorneherein klare Ansagen gemacht werden, wie zB:


    -> in 3 Monaten nicht zu schaffen! Dauert mindestens 1 Jahr <-


    Und genau da liegt der Hase im Pfeffer! ICH - habe verschiedene Projekte in andere "Zeitschienen" gepackt, was "Anfangs" klar auf der Rechnung deutlich zu sehen ist :D


    Und? Parallel dazu liefen gleichartige Projekte, wo da der Zeitraum auf 3 Monate und "Billiger" angegeben und ausgeführt wurde. Im Endeffekt mit dem "hinterher arbeiten" - dauerte das Projekt 3 Jahre, war 10 mal so teuer, und am Ende immer noch nicht fertig, weil alles "auf die schnelle zusammen geferkelt" wurde, um es gerade so am laufen zu halten! :thumbdown:


    "MEIN" Projekt Stand 1A nach einem Jahr - fix und fertig, mit entsprechendem Support - ohne "mullen und knullen" :saint:


    Ok! Ein paar Kleinigkeiten gab es - aber - DIE - waren kein Thema! :whistling:

    -----


    Wollte ich mal gesagt haben.....

  • Eigentlich wurde das meiste schon genannt. Aus der Praxis kann ich sagen, dass riesige Komplexität, handwerkliche Problem aber auch organisatorische Probleme jedes für sich seine ganz eigenen Tücken hat. Komplexität: Irgendwann kommt man an den Punkt, dass das Softwarekonstrukt dermaßen ausufernd groß ist, dass man als einzelne Person gar nicht mehr überblicken kann, was genau das alles bewirkt, wenn man an Stelle A Änderung B vornimmt. Das kann man in Grenzen schon in den Griff kriegen, aber dann folgt das was andere schon gesagt haben: Wenn man das richtig™ machen will, braucht man Zeit. Zeit ist Geld und Kunden wollen natürlich immer alles am besten morgen, und am liebsten wären sie der einzige Kunde auf der Welt, um den sich alles dreht.


    Auf der anderen Seite, was auch schon genannt wurde: Je früher man die Probleme aus dem Weg räumt, desto besser. Am besten schon bei der Spezifikation, wenigstens bei der Umsetzung. Aber nicht erst beim Test, beim Release-Bau oder gar erst beim Kunden. Das ist noch teurer. Hier in der Firma wird einfach viel zu oft die Minimallösung für ein Problem angeschleppt, statt es einfach ein mal gescheit zu machen. Nicht weil die Entwickler nicht wollten... Sondern weil der Fisch vom Kopf her stinkt, und man einfach immer die Ansage kriegt, das zu nehmen, was aktuell am schnellsten und damit billigsten erledigt ist. Dass man dann statt ein mal drei Tage lieber 10 mal einen halben Tag rein stecken muss, garniert mit etwas angesäuerten Kunden. Hauptsache schnell schnell.


    Und das Beispiel mit den neun Frauen, die in einem Monat ein Kind auf die Welt bringen: Mal das Buch »The Mythical Man Month« lesen. Gut beschrieben, warum es nicht immer hilft mehr Manpower drauf zu packen.