Moderne Entwicklungsmethoden - Anspruch und Wirklichkeit
-
@TyRoXx
Dieses Argument wird gerade deswegen so gerne vorgeschoben, eben WEIL es manchmal total zutrifft und schwerer wiegt als alles andere.Dass ein bestimmtes Argument oft als Entschuldigung/Verschleierung für Faulheit/Trägheit/... vorgeschoben wird, heisst ja nicht dass es nie stimmt und man sich nie danach richten sollte. Es heisst nur dass man hellhörig werden sollte und sehr genau hingucken/abwägen ob es auf die jeweilige Situation bezogen auch so ist.
Zu sagen dass das Argument immer Quatsch ist (und so interpretiere ich deinen Beitrag - falls das nicht stimmt bitte nicht übel nehmen sondern einfach korrigieren), halte ich daher auch für falsch.
Das umgekehrte Problem gibt es nämlich genau so. Leute die immer alles besser/moderner/XYZ-iger machen wollen, und dabei viel viel mehr kaputt machen/verschlechtern als richten/verbessern. Und auch diese finden ihre Arbeitsweise voll OK und gut und richtig.
Ist halt alles leider nicht so einfach. Man muss sich jeden Fall immer wieder aufs neue angucken und versuchen abzuschätzen was wann wie wo und warum die beste Lösung wäre. (Und das "leider" ist hier jetzt kein "spitze Formulierung" die Zynismus/Sarkasmus kennzeichnet, sondern ich meine das ganz ernst. Ich zumindest finde das schon sehr ermüdend. Hilft aber nix, ändert sich deswegen ja nicht.)
-
TyRoXx schrieb:
Das ist exakt die Argumentation der Schluderer. Besser hätte ich es nicht treffen können. Mal von mir auf Deutsch übersetzt: Verbesserung ist nur ein Risiko, Experimente sind immer zu teuer. Lernen ist zu teuer. Man müsste zugeben, dass man Fehler gemacht hat. Wer Fehler macht, wird nie ein Sieger der Geschichte werden. "Bewährte" (alte) Methoden sind immer die vernünftige Wahl (siehe mein vorheriger Beitrag). Wenn es ab und zu mal gut funktioniert, rechtfertigt das rück- und fortwirkend jeden vermeidbaren Rückschlag. Ausfälle nach Verbesserungen liegen nur an den Verbesserungen. Ausfälle ohne Verbesserungen sind normal. Software hat eben Bugs und es ist nicht möglich etwas dagegen zu unternehmen.
Es ist eben sehr oft im Leben existenzbedrohend, wenn ein Plan nicht funktioniert. Ist das so schwer zu verstehen? Esse ich lieber nur die Pilze, von denen mir die Alten erzählt haben, dass ich sie essen darf, oder probiere ich lieber alle einmal aus, um zu sehen, ob ich meine Ernte steigern kann? Setze ich das Firmenkapital ein, um mit bewährten Methoden ein Produkt auf den Markt zu bringen, oder riskiere ich Insolvenz, um eventuell ein besseres Produkt entwickeln zu können?
Das man damit auch Unaufgeschlossenheit gegenüber Neuerungen verteidigen kann, macht diese Einstellung nicht generell falsch.
-
maximAL schrieb:
Es gibt einen Styleguide an den sich niemand hält, schon gar nicht der leitende Entwickler.
Es gibt dafür keine Argumente. Es hat sich nicht bewährt, dass jeder so programmiert, wie es ihr gerade passt.
maximAL schrieb:
C mit Klassen, riesige "Module", die wiederum von anderen, ebenso riesigen Modulen, abhängig sind. Public Member, leaky Abstractions und er scheut sich auch nicht eine 2000-Zeilen Klasse zu duplizieren um in der zweiten Variante ein paar Sachen ändern zu können.
Dafür gibt es auch keine Argumente. Nein, wirklich nicht. Solche Leute verursachen mehr Arbeit als sie erledigen. Diese Art von Schluderei hat sich auch nicht bewährt. Nicht alles, was gängig ist, ist automatisch "bewährt"!
maximAL schrieb:
Unit Tests gibts nur für Dinge, die sowohl sehr kritisch sind und sich leicht testen lassen wie beispielsweise mathematische Algorithmen. Der Wert von testbaren Code, der positive Einfluss auf das ganze Design wird negiert.
Ansonsten gibt es gar keine automatischen Test (Integrations-, Systemtests etc.).Dafür gibt es keine Argumente. Software braucht immer automatische Tests. Die wegzulassen hat sich nicht bewährt.
maximAL schrieb:
Es gibt keine Testabteilung oder wenigstens eine klar definierte Testphase. Neue Versionen gehen meistens direkt zum Kunden, wenn man gerade keinen kritischen Bug mehr gefunden hat - und scheitern dort regelmäßig.
Kunden mögen so etwas akzeptieren, wenn sie keine andere Wahl sehen. Das hat sich aber nicht "bewährt"!
maximAL schrieb:
Code Reviews gibts höchstens für wirklich umfangreiche oder kritische Aufgaben, dass ist dann eber eher ein "zeig dem Chef was du gemacht hast", nicht das, was ich mir unter einem Code Review vorstelle.
Code Reviews lohnen sich immer. Software ist unheimlich komplex. Man kann nicht erwarten, dass mehrere Entwickler sinnvoll zusammenarbeiten ohne voneinander zu wissen. Blind Code einzuchecken ohne jede Überprüfung durch andere Menschen hat sich nicht bewährt.
maximAL schrieb:
Neuen Technologien steht man erst mal grundsätzlich ablehnend gegenüber. Am liebsten möchte man alles selbst implementieren und der Einwand, dass Tool X oder Bibliothek Y genau diese Probleme löst wird meistens ohne weitere Diskussion abgeschmettert.
Alles selbst zu machen hat sich nicht bewährt.
maximAL schrieb:
Von Dingen wie Continuous Integration oder einem agilen Entwicklungsprozess will ich gar nicht erst anfangen.
Auf CI zu verzichten hat sich nicht bewährt. Wild in der Gegend herumzuentwickeln hat sich nicht bewährt.
SeppJ schrieb:
Es ist eben sehr oft im Leben existenzbedrohend, wenn ein Plan nicht funktioniert.
Es ist existenzbedrohend sich nicht der Realität der Gegenwart anzupassen. Mehr sage ich doch gar nicht.
SeppJ schrieb:
Ist das so schwer zu verstehen? Esse ich lieber nur die Pilze, von denen mir die Alten erzählt haben, dass ich sie essen darf, oder probiere ich lieber alle einmal aus, um zu sehen, ob ich meine Ernte steigern kann?
Oder man kauft einfach die Pilze in einem seriösen Geschäft. Da bekommt man garantiert keine giftigen.
SeppJ schrieb:
Setze ich das Firmenkapital ein, um mit bewährten Methoden ein Produkt auf den Markt zu bringen, oder riskiere ich Insolvenz, um eventuell ein besseres Produkt entwickeln zu können?
Gerne bewährte Methoden. Schluderei ist keine bewährte Methode. Das ist meine Argumentation.
SeppJ schrieb:
Das man damit auch Unaufgeschlossenheit gegenüber Neuerungen verteidigen kann, macht diese Einstellung nicht generell falsch.
Eine saubere Arbeitsweise ist keine Erfindung des 21. Jahrhunderts. Alt=schlecht ist ein Strohmann. Darum geht es gar nicht. Ich verwende auch gerne C++, obwohl es uralt ist. Ich weiß aber, wie man es verwendet und warum neue Standards besser sind. Schluderer lehnen neue Standards ab, weil sie neu sind, weil sie glauben, dass Nicht-Schluderer alles ablehnen, was alt ist. Nicht zu wissen, warum man etwas so macht, wie man es macht, kritisiere ich hier.
hustbaer schrieb:
Das umgekehrte Problem gibt es nämlich genau so. Leute die immer alles besser/moderner/XYZ-iger machen wollen, und dabei viel viel mehr kaputt machen/verschlechtern als richten/verbessern. Und auch diese finden ihre Arbeitsweise voll OK und gut und richtig.
Richtig, das gibt es auch in der anderen Richtung. Das nennt man Hype, glaube ich. Man muss wissen, warum man etwas macht.
-
TyRoXx schrieb:
hustbaer schrieb:
Das umgekehrte Problem gibt es nämlich genau so. Leute die immer alles besser/moderner/XYZ-iger machen wollen, und dabei viel viel mehr kaputt machen/verschlechtern als richten/verbessern. Und auch diese finden ihre Arbeitsweise voll OK und gut und richtig.
Richtig, das gibt es auch in der anderen Richtung. Das nennt man Hype, glaube ich. Man muss wissen, warum man etwas macht.
Ich hätte jetzt gesagt man nennt das "dumme Leute"
-
meine Erfahrung ist: die (vermeintlich) guten kämpfen zu wenig - resignieren oder gehen dann
Es gibt wenige Entwickler die (lange)genug Arsch in der Hose haben (=Ausdauer+Fähigkeit) um Karren dauerhaft aus dem Dreck zu ziehen
(kann auch mal(oder oft) Jahre dauern)kein sinnloses kämpfen - aber auch nicht zu früh (paar Monate harter arbeit an dem Zustand sollte schon sein) die Flinte ins Korn werfen können in vielen Situationen was bringen
-
Gast3 schrieb:
meine Erfahrung ist: die (vermeintlich) guten kämpfen zu wenig - resignieren oder gehen dann
Wo gehen die dann hin?
-
TyRoXx schrieb:
Gast3 schrieb:
meine Erfahrung ist: die (vermeintlich) guten kämpfen zu wenig - resignieren oder gehen dann
Wo gehen die dann hin?
Zur nächsten Klitsche, in der es am Ende auch nicht besser läuft natürlich
-
Du musst vielleicht auch einfach lang genug dabei bleiben, bis du auch was zu sagen hast. Bei mir hats auch 1-2 Jahre gedauert, bis ich mich durchsetzen konnte. Wenn man sieht, dass deine Projekte laufen und du nicht nur leeres "modernes" Geschwätz von dir gibst, wird man eher auf dich hören.
-
Mechanics schrieb:
Du musst vielleicht auch einfach lang genug dabei bleiben, bis du auch was zu sagen hast. Bei mir hats auch 1-2 Jahre gedauert, bis ich mich durchsetzen konnte. Wenn man sieht, dass deine Projekte laufen und du nicht nur leeres "modernes" Geschwätz von dir gibst, wird man eher auf dich hören.
Der Kampf hört nie auf, weil jede erfolgreiche Maßnahme ganz schnell als selbstverständlich wahrgenommen wird, aber sich keine Kultur der ständigen Verbesserung einstellt. Je mehr Werkzeuge und Methoden man einführt, desto öfter ist man auch pauschal für alle Probleme damit verantwortlich.
-
andere Moeglichkeit: "leading by example". Ich hab auch in diversen chaos-projekten gearbeitet, aber gerade dann wenn Vorgaben und Richtlinien fehlen hat man meist Gestaltungsfreiraum weil eh jeder tut was er will. Was haelt Dich also ab fuer Deine Komponenten guten Code zu schreiben oder automatisierte UTs zu haben?
Spaetestens wenn du im groessten Projektstress immer rechtzeitig fertig bist waehrend andere noch ewig ihren Quatsch debuggen wird es Nachahmer geben :).
-
Mechanics schrieb:
Du musst vielleicht auch einfach lang genug dabei bleiben, bis du auch was zu sagen hast. Bei mir hats auch 1-2 Jahre gedauert, bis ich mich durchsetzen konnte. Wenn man sieht, dass deine Projekte laufen und du nicht nur leeres "modernes" Geschwätz von dir gibst, wird man eher auf dich hören.
Hey, ich bin seit über 5 Jahren dabei. Und tatsächlich haben die Sachen, die ich selbstständig umsetzen konnte gut funktioniert, während die Sachen, bei denen mit permanent reingeredet wurde regelmäßig in die Hose gegangen sind.
Das Problem ist einfach, dass die Vorgesetzten die gute Arbeit nicht sehen, weil das Themen sind, in denen die nicht drin stecken. Dort wo sie ihre Nase reinstecken und alles auf ihre Art gemacht haben wollen sehen sie dann, dass es nicht funktioniert - was dann natürlich meine Schuld ist.
Außerdem gibt es hier kein wirkliches Qualitätsbewusstsein. Es wird als normal betrachtet, dass man viel Zeit mit der Fehlersuche verbringt. Teils werden Mannmonate ins Debugging von einer Komponente gesteckt, das scheint niemanden zu stören. Investiert man hingegen Zeit für ein sauberes Design, schreibt Unit Tests etc., dann dauert das natürlich erst mal länger und man steht unter Rechtfertigungsdruck. Dass das Zeug dann aber funktioniert und nicht mehr ständig angefasst werden muss sieht nachher natürlich keiner.TheBigW schrieb:
Spaetestens wenn du im groessten Projektstress immer rechtzeitig fertig bist waehrend andere noch ewig ihren Quatsch debuggen wird es Nachahmer geben
Wir entwickeln hier aber eigene Produkte, die Monate und Jahre verschoben werden. Und es gibt hier auch nicht einfach "meinen Code" und "deren Code", weil die Aufgaben ständig verschiedenen Entwickler zugeteilt werden. Da hast du dann das Problem, dass sonst keiner versteht was deine Unit Tests eigentlich tun und der Code anderer Leute nicht getestet oder überhaupt testbar ist.
-
Vorgesetzte spielen auch gerne die "Business-Karte". Weil sie verantwortlich sind für den finanziellen Erfolg, glauben sie, dass sie automatisch mit ihrer Intuition immer richtig liegen. Eine Verzögerung von Monaten durch Schluderei ist leichter zu rechtfertigen als eine um Wochen durch saubere Arbeitsweise. Das liegt vielleicht daran, dass ein Fachfremder irrational annimmt, dass Qualität ein schlechteres Preis-/Leistungsverhältnis bedeutet. Das mag bei vielen materiellen Gütern und Dienstleistungen so sein, aber nicht bei Software-Entwicklung. Bis zu einem gewissen Grad lohnt es sich immer in die genannten Praktiken zu investieren. Meiner Erfahrung nach liegen die meisten Unternehmen weit unter diesem Grad.
Die Verzögerung durch "Beeilen" wird meiner Erfahrung nach auch gerne als eine kranke Art der Investition wahrgenommen. Beim nächsten Mal muss es ja besser klappen, weil man den blöden Entwicklern endlich die Ideen ausgetrieben hat.
Automation ist grundsätzlich zu teuer, weil Rechenzeit Geld kostet und Server gepflegt werden müssen. Und die ganzen Emails wegen kaputter Builds lenken nur von der eigentlichen Arbeit ab.
Diese Schluderei führt dann zu absurden Zyklen wie: Es lohnt sich nicht das Deployment zu automatisieren -> ein Testserver wäre zu aufwendig, weil das Deployment manuell erfolgt -> wieso das Deployment automatisieren, wenn es nur den Produktivserver gibt?
Wie argumentiert man gegen so etwas, wenn Verfügbarkeit, Korrektheit oder die Verringerung von Entwickleraufwand für das Deployment alles keine validen Argumente zu sein scheinen?
-
Wir entwickeln hier aber eigene Produkte, die Monate und Jahre verschoben werden. Und es gibt hier auch nicht einfach "meinen Code" und "deren Code", weil die Aufgaben ständig verschiedenen Entwickler zugeteilt werden. Da hast du dann das Problem, dass sonst keiner versteht was deine Unit Tests eigentlich tun und der Code anderer Leute nicht getestet oder überhaupt testbar ist.
IMO ein klassisches Grunduebel: jeder ist fuer alles und nichts verantwortlich ... Wenn man dann nicht mindestens ein paar gleichgesinnte hat die die eigene Warnhemmung teilen kann man wirklich nur noch das Weite suchen ...
Wirklich perfekt habe ich es auch noch nirgends gesehen, aber was besseres sollte sich schon finden lassen.
BTW: wenn meine eigenen Ansprueche zur Arbeitsrealitaet mal wieder zu weit abweichen schnapp ich mir zu Hause ein privates Projekt - das erdet
-
maximAL schrieb:
Mechanics schrieb:
Du musst vielleicht auch einfach lang genug dabei bleiben, bis du auch was zu sagen hast. Bei mir hats auch 1-2 Jahre gedauert, bis ich mich durchsetzen konnte. Wenn man sieht, dass deine Projekte laufen und du nicht nur leeres "modernes" Geschwätz von dir gibst, wird man eher auf dich hören.
Hey, ich bin seit über 5 Jahren dabei. Und tatsächlich haben die Sachen, die ich selbstständig umsetzen konnte gut funktioniert, während die Sachen, bei denen mit permanent reingeredet wurde regelmäßig in die Hose gegangen sind.
Das Problem ist einfach, dass die Vorgesetzten die gute Arbeit nicht sehen, weil das Themen sind, in denen die nicht drin stecken.Sorry, ich hatte das so interpretiert, dass du frisch von der Uni kommst, paar Monate in der Firma bist und es nicht so läuft, wie du es dir im Studium vorgestellt hast
Wenn es nach fünf Jahren immer noch nicht geklappt hat, nichts wie weg Unsere Vorgesetzten sind zwar auch nicht so drin, aber das ist aus meiner Sicht auch nicht das Problem... Wir haben einen Teamleiter, der auch nicht alles im Detail kennt, aber auch Informatiker ist und sich insgesamt gut auskennt. Und die Kollegen selber sind auch einsichtiger. Keiner von denen sagt, mein alter Code mit den 10 000 Zeilen in einer Klasse war super, würd ich wieder so machen.Läuft also schon ziemlich komisch in deiner Firma, würde ich sagen. Wir sind da auch kein Musterbeispiel, aber ich würd sagen, deutlich besser. Und da ich noch besser aufgestellte Firmen kenne und davon ausgehe, dass es noch viel mehr davon gibt, wirst du wahrscheinlich schon was besseres finden können.
-
TheBigW schrieb:
andere Moeglichkeit: "leading by example". Ich hab auch in diversen chaos-projekten gearbeitet, aber gerade dann wenn Vorgaben und Richtlinien fehlen hat man meist Gestaltungsfreiraum weil eh jeder tut was er will. Was haelt Dich also ab fuer Deine Komponenten guten Code zu schreiben oder automatisierte UTs zu haben?
Spaetestens wenn du im groessten Projektstress immer rechtzeitig fertig bist waehrend andere noch ewig ihren Quatsch debuggen wird es Nachahmer geben :).Hach. Wie schön es wäre Tests zu haben, denn das würde voraussetzten, dass es eine Anforderungsdefinition gegeben hätte. Bei uns ändern sich noch am Tage der Auslieferung die Anforderungen, weil es "der Kunde nun doch so will".
-
Mason_ schrieb:
Hach. Wie schön es wäre Tests zu haben, denn das würde voraussetzten, dass es eine Anforderungsdefinition gegeben hätte. Bei uns ändern sich noch am Tage der Auslieferung die Anforderungen, weil es "der Kunde nun doch so will".
Wenn sich Anforderungen ändern, sind Tests besonders hilfreich. Für Unit Tests braucht man keine Anforderungsdefinition. Die testen eher, dass das, was du tatsächlich geschrieben hast, deinen Erwartungen entspricht. Ob diese Erwartungen sich im Gesamtbild mit Anforderungen decken, ist eine andere Frage.
-
maximAL schrieb:
Ich bin schon länger unzufrieden damit wie in meiner Firma gearbeitet wird. Da ich aber keinen wirklichen Vergleich zu anderen Firmen habe bin ich mir nie so richtig sicher, ob ich nicht einfach zu viel erwarte.
Die Firma ist ein kleiner Mittelständler und die Codebasis ist Teils bis zu 20 Jahre alt. Da bleiben viele Legacy-Sünden natürlich nicht aus.Ich glaube du erwartest zu viel. Mir gehts wie dir, aber teils noch älterer Code und überhaupt kann ich dich um deine Punkte eher nur beneiden.
Wir maintainen immer noch einen System-Abstraktionslayer (Sachen wie Threads, Zeit, File-IO etc.).
Das heißt ja schon mal, dass nicht jede Funktion im Programm ihre eigene Lieblings-API benutzt.
Das Build-System ist immer noch GNU make (auch unter Windows - mit msys), die offizielle "IDE" ist Emacs etc.
Sei froh über gmake. Das ist zwar alt, aber nach wie vor modern und vor allem praktisch (d.h. man kann alles machen).
Ich darf mich hier mit so einer modernen (verbuggten IDE) rumschlagen, wo ich tausend Mausklicks machen muss, nur um zw. Debug und Release umzuschalten.
Die Projektdateien sind in XML und werden ständig automatisch von der tollen IDE verwurstelt.
Mit dem Compiler fange ich gar nicht erst an.Abgesehen davon das Emacs super ist, bedeutet das doch vor allem, dass du deinen Lieblingseditor nehmen kannst, der nur make aufrufen muss.
Es gibt einen Styleguide an den sich niemand hält, schon gar nicht der leitende Entwickler.
Hier genauso. Aber das schöne daran ist, dass man für seine Sachen, den einzig richtigen Style nehmen kann
Unit Tests gibts nur für Dinge, die sowohl sehr kritisch sind und sich leicht testen lassen wie beispielsweise mathematische Algorithmen. Der Wert von testbaren Code, der positive Einfluss auf das ganze Design wird negiert.
Tests? lol, das wär mal was. Andererseits bin ich als Entwickler ja in der Situation, Tests schreiben zu können... Ganz ganz selten mache ich das sogar.
Es gibt keine Testabteilung oder wenigstens eine klar definierte Testphase. Neue Versionen gehen meistens direkt zum Kunden, wenn man gerade keinen kritischen Bug mehr gefunden hat - und scheitern dort regelmäßig.
Da stehen wir zum Glück besser da.
Am liebsten möchte man alles selbst implementieren und der Einwand, dass Tool X oder Bibliothek Y genau diese Probleme löst wird meistens ohne weitere Diskussion abgeschmettert.
Hier möchte man am liebsten alles irgendwie dazu kaufen weil die fertige Komponente billiger ist als die geschätzte Zeit für einen Entwickler.
Die Zeit die der Entwickler dann damit verbringt, sich durch irgendeine ranzige, undokumentierte Dritt-Software zu schlagen, wird leider nicht so genau eingerechnet.Ich bin schon froh, dass wir endlich CVS durch git ausgetauscht haben
Ja, sei froh über git
Erwarte ich wirklich einfach zu viel, wenn ich automatische Tests, Code Reviews, Bibliotheken und modernen Tools für selbstverständlich bei der Entwicklung von neuem Code halte?
Also wenn man sich so einige OpenSource-Projekte anguckt, scheint es das wohl tatsächlich zu geben. Innerhalb einer Firma, habe ich das noch nicht erlebt.
-
Hallo an alle, hab mir mal die Zeit genommen, diesen Thread zu lesen: manches kommt mir aus eigener Erfahrung sehr bekannt vor
Hab nach dem Studium 3 Jahre in der HW-Entwicklung gearbeitet (Netzwerke), danach (bis heute manchmal noch) im Embedded-Bereich (z.B. Maschinensteuerungen mit "harten" Echtzeitanforderungen).Bitte nicht falsch verstehen, aber ich kann nur sagen: Willkommen im "richtigen" Leben
Von Paradigmen haben zu meiner Anfangszeit als SW-Entwickler nicht viele geredet: SW-Goldgräberzeit oder gar SW-Wildwest? Test-Units: was ist das?
Ich kann nur den Rat geben: sich nicht frustrieren lassen, wenn es einem zu viel wird, in Ruhe eine neue Stelle suchen. Aber Vorsicht: man kann ganz leicht vom Regen in die Traufe geraten. Besonders dann, wenn die neue Firma bereits länger existiert und sich eine gewisse Codebasis "angesammelt" hat, aka. man auf etablierte Strukturen trifft.
Perfekt wäre eine neugegründete Garagenfirma, da kann man dann von Grund auf neu beginnen. Wird nach ein paar Jahren aber in einer ähnlichen Situation sein. So ist das nun mal.
Ansonsten muss man darauf hoffen, dass man mit Unterstützung selbst ans "Ruder" kommt....Einer, der mit über 50 die Firma nicht mehr wechseln kann (zumindest nicht als SW-Entwickler)
Grüße!
-
Seh ich auch so ....
Bei uns haben die "neuen", also frisch von der Uni und so, auch noch Ideale. Je nach Projekt, wo sie "verheizt" werden, dauerts 2-5 Jahre, bis sie die verlieren ....
Am Anfang: Unit-tests, Continius Integration, Ticket System ... wo find ich was ?
Nach ner Weile: Unit-tests, Continius Integration, Ticket System ... macht das hier wirklich Sinn ?Was ist die Ursache ?
Ich denk 90% unserer Projekte würden schon beim Anforderungs-Management durchfallen. D.h. Die meisten Projekte fangen an "produktiv" zu werden noch bevor klar ist, was die genauen Anforderungen sind.Die meisten Projekte sind so ausgeschrieben, das nen sauberes Anforderungsmanagment schon das halbe Gesamt-Budget fressen würde.
Der SW Architekt und die Entwickler kennnen auch meistens die Langzeit-Ziele (sofern es welche gibt) nicht.
Zeitknappheit durch Preisdruck tut dann das übrige ...
Unter solchen Umständen ist man dann froh, überhaupt was fertig zu bekommen, Qualität wird dann zum untergeordneten Problem, leider
Ciao ...
-
Inkompetenz wird gerne als Sparsamkeit getarnt. Eine saubere Arbeitsweise spart Zeit, aber man muss es auch können.
Eine Woche herumzueiern ohne Ergebnisse ist total akzeptiert, aber einen Tag Lesen und Ausprobieren ist Zeitverschwendung.
Andere darauf hinzuweisen, dass sie etwas besser machen könnten, birgt immer das Risiko, dass man sich unbeliebt macht oder dass stärker auf die eigenen Fehler geschaut wird.
