Laden...

Alltag in unserer Branche (?)

Erstellt von Fabian vor 15 Jahren Letzter Beitrag vor 13 Jahren 42.818 Views
49.485 Beiträge seit 2005
vor 15 Jahren

Hallo marco.b,

Ich glaube nicht dass es pauschal immer technische Lösungen gibt, die helfen. Insbesondere hinter deinem Stichwort sehe ich keine wirkliche Lösung ...

ich habe nicht von Patentrezepten oder Königswegen gesprochen, sondern nur von Lösungen. Das diese Lösungen selbst wieder bestimmte Probleme aufwerfen, ist klar. Allerdings gibt es auch dafür wieder Lösungen (Stichwort: Unitests/automatisierte Tests).

Der springende Punkt ist für mich:

Im Prinzip geht es doch nur darum, ob man lieber bei einer Firma arbeiten will, die an einer Lösung interessiert ist oder bei einer, bei der gesagt wird, Hauptsache es läuft (heute).

Abstriche von einer idealen Welt muss man natürlich auch bei Firmen machen, die versuchen, möglichst sauber zu arbeiten.

herbivore

S
8.746 Beiträge seit 2005
vor 15 Jahren

Wenn man den Lebenszyklus eines jeden Produktes anschaut, dann ist klar, dass sich irgendwann frickeln "lohnt". Das ist schon angesichts der Überlegung klar, dass irgendwann die letzte Änderung kommt. Da ist die Schnellste immer auch die "Beste". Tatsache ist auch, dass die mangelnde Investition in die Struktur einer Software oft viel zu früh einsetzt, nicht selten von Beginn an. Meiner Erfahrung nach passiert es viel zu häufig, dass äußere Faktoren unnötigen Druck auf Projekte laden. Der zweite Fehler besteht dann oft darin, diesem Druck nachzugeben statt ihm aktiv zu begegnen, um das Projekt wieder in das Fahrwasser zu bekommen. Klassische Managementfehler.

S
8.746 Beiträge seit 2005
vor 15 Jahren

ja, ich behaupte, dass jedes größere Softwareprojekt langfristig aufgrund eines Verfalls altert. Dieser Verfall wird durch Implementierungen ausgelöst, die zu Beginn nicht vorgesehen waren.

In diesem Zusammenhang ein Zitat von Jens Coldeway:

2. Hauptsatz der Softwareentwicklung
Ein Softwaresystem tendiert stets zu einem
Zustand höherer Komplexität und größeren
Chaos, wenn ihm von außen keine
Energie in Form von Entwicklungsaufwand
zugeführt wird.

Aus einem Artikel in der ObjektSpektirum mit dem schönen Titel:

"WAS SOFTWAREENTWICKLUNG MIT DER THERMODYNAMIK VERBINDET"

http://www.sigs.de/publications/os/2003/01/coldewey_OS_01_03.pdf

Nun wird die Energie die zugeführt werden muss immer mehr, weil die Komplexität insgesamt immer steigt (wer baut schon Funktionen wieder aus...). Statt einer "Energieeinheit" pro Funktionspunkt braucht man irgendwann 10 und die Software wird unbezahlbar. Dann verfällt sie.

Auf der anderen Seite hat Herbi natürlich Recht, dass deine Beschreibung von Softwareentwicklung zwar eine realistische (weil oft anzutreffende), aber zugleich auch pessimistische ist. Ein Design welches aus einem von dir beschriebenen Wasserfall-Prozess entspringt, wird immer ein schlecht zu wartendes Monster sein. Agile Entwicklung und inkrementelles Design sind aus technischer und organisatorischer Sicht "Heilmittel". Wie Medizin können sie den Tod nicht verhindern, aber die Lebenserwartung und auch die Lebensqualität (insbesondere der ENtwickler) erhöhen. Aber diese Methoden erfordern eine starke Bereitschaft zur Veränderung - sowohl persönlich als auch innerhalb der Strukuren. Weniger positiv formuliert: Sie machen Angst und erfordern daher Mut. Als "kleiner angesteller Entwickler" hat man es nicht in der Hand diese einzuführen. Bestenfalls kann man Guerilla-Taktiken anwenden. Der alleinschaffende Freiberufler oder Unternehmer hat es da leichter. Aber das sind nunmal die wenigsten...

Um wieder auf das Thema "Anstellung" zurückzukommen: Man sollte sich klar ist was für ein Typ man ist. Nicht jeder ist der intellektuelle Überflieger. Dafür sind die selten die gewissenhaften Menschen für die letzten 20%. Manche hassen es wie die Pest Unit-Tests zu schreiben. Manche haben keine Lust sich mit Fachthemen auseinanderzusetzen, sondern stehen eher darauf eine klare Anfoderung auf dem Papier möglichst schnell/kurz/performant umzusetzen.

Jeder neigt daher zu einer bestimmten Arbeitsweise. Nur eines darf es nicht sein: Unprofessionell. Chaos ist immer schlecht. Insofern bewegt sich die Welt heutzutage zwischen zwei Profi-Extremen: (Groß-) Unternehmen mit professioneller, dokumentengetriebener Entwicklung oder kleine, agile, hoch-disziplinierte Special-Forces die mit hoher Geschwindigkeit sich bewegene Anforderungen mit minimalen Reibungsverlusten "niederkoden".

T
415 Beiträge seit 2007
vor 15 Jahren

Diese nette Grafik bringt es doch lustig auf den Punkt ;o)

Kundenprojekte

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo,

Das Bild mit dem Baum musste ja irgend wann kommen! 😁 👍
Ich finde das super Witzig auber auch super traurig, weil es eben oft stimmt.

Gruß
Juy Juka

4.207 Beiträge seit 2003
vor 15 Jahren

Zum Thema Softwarequalität siehe auch das aktuelle Streitgespräch von Peter Bucher und mir:

http://www.des-eisbaeren-blog.de/post/2009/02/01/Die-Forderung-nach-Softwarequalitat.aspx

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

5.941 Beiträge seit 2005
vor 15 Jahren

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Fabian Themenstarter:in
1.985 Beiträge seit 2004
vor 13 Jahren

Hallo zusammen,

über ein Jahr ist mein Eingangspost mittlerweile her. Jetzt wollte ich mal nachfragen, was sich bei Euch in der Zwischenzeit getan hat? Ist es schlimmer/besser geworden oder habt ihr vor der Situation endgültig kapituliert?

Mit meiner damaligen Aussage

Ändern kann ich aktuell und in mittlerer Zukunft aber wahrscheinlich nichts an der Situation.

lag ich ziemlich richtig. Grund genug für mich, der Firma in Kürze den Rücken zu kehren.

Vielleicht habt ihr ja Lust, ein Update zu geben.

Gruß,
Fabian

"Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vornherein ausgeschlossen erscheint." (Albert Einstein)

Gefangen im magischen Viereck zwischen studieren, schreiben, lehren und Ideen umsetzen…

Blog: www.fabiandeitelhoff.de

2.921 Beiträge seit 2005
vor 13 Jahren

@Fabian: Dann gehts Dir so wie mir.

Ich könnte euch genügend Beispiele aus unserem Coding-Style Horror geben, der bei uns generiert wird.

Neuester Super-Gau: Alle Compiler und .NET-Runtime Sicherheitsmechanismen wurden abgeschalten. Begründung: Jetzt sind die Fehlermeldungen UND die Fehler weg.

Alles schwarz/weiß gedruckte bei Microsoft und weiteren einschlägigen sehr zuverlässigen Quellen wurde mit einem "Glaub ich nicht" weggewischt.

Tja da sag ich dann nur noch: Kürbis gedeihe. 😉

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

F
10.010 Beiträge seit 2004
vor 13 Jahren

Bei uns hat es sich deutlich verbessert.

Bei uns waren Testerstellung (TDD oder BDD ) bzw Testdaten Erstellung unerwünscht, "weil das kostet zeit und bringt keinen Mehrwert für den Kunden".

Wir hatten ein Teilprojekt, das sich gut extern entwickeln liess "nebenbei" entwickeln lassen.
Entgegen der vorherrschenden Meinung des Managments habe ich durchgesetzt,
das bei der Erstellung der Lasten/Pflichtenhefte auch die Testdaten mit bereitgestellt werden müssen, und die Entwicklung mit BDD durchgeführt werden soll.

Nur mal "um zu sehen" ob sich dadurch etwas ändert.

Nachdem das teilprojekt dann fertiggestellt war, und wegen anderer Mgmt Entscheidungen erstmal auf eisgelegt lag, wurde es dann ca 6 Monate später in das Hauptprodukt integriert.
Jetzt schlugen die Tests an, und wir haben in sehr kurzer zeit alles fixen können.
Die Tester sind zufrieden, das Mgmt war erstaunt.

Jetzt machen wir SCRUM und BDD.

Evtl lesenswert dazu ist auch :
http://www.codeproject.com/KB/tips/convince.aspx

109 Beiträge seit 2009
vor 13 Jahren

Hallo Community,

Auch wenn ich glaube diese Diskusion schon einmal gelesen zu haben, ist sie mir heute noch einmal aufgefallen und möchte nun einmal meine Erfahrungen schildern. Falls ich dabei vom Thema abweiche tut es mir leid.

Ich habe letztes Jahr meine Ausbildung zum Fachinformatiker beendet, bin also in etwa gleichzusetzten mit den "ambitionierten Uniabgängern" die hier schon einmal erwähnt wurden. Meine Ausbildung und das Jahr danach habe ich im öffentlichen Dienst zugebracht, wo ja doch ein etwas andres Arbeitsklima herscht als in der freien Wirtschaft. Bei mir gab es so etwas wie "Zeitdruck" nicht in dem Sinne wie er hier des öfteren angesprochen wurde. Eine anderer Unterschied ist, dass ich hier am Standort der einige "Vollblut-"Programmierer bin, alle anderen in der IT beschäftigen sich mit dem Netzwerk und der gleichen, wovon ich allerdings vollkommen ausgeschlossen bin. Dadurch bin ich in einem tierischen Nachteil, weil ich niemanden habe, der mit mir meine Codes durchgeht und sie einmal gegencheckt (im sinne des CCD) und ich leider auch während der Ausbildung keinen richtigen Eindruck bekommen habe, wie es "richtig" geht. Um das zu ändern habe ich mir einen dualen Studienplatz im bereich Informatik gesucht und werde quasi nocheinmal von vorne Anfangen. Dieses mal will ich auch die CCD-Regeln gleich mitlernen

und so stellt sich wieder einmal die Frage: Warum klappt das nicht gleich so gut?

Gelöschter Account
vor 13 Jahren

im studium lernst du nicht programmieren 😉
ok du lernst evtl ein paar sprachen und viel theorie.. aber wie es richtig geht lernst du nciht im studium.

109 Beiträge seit 2009
vor 13 Jahren

Darum ja ein Duales studium mit programmiererischen tätigkeiten im praxisbetrieb 😉

und so stellt sich wieder einmal die Frage: Warum klappt das nicht gleich so gut?

1.815 Beiträge seit 2005
vor 13 Jahren

Hallo!

im studium lernst du nicht programmieren 😉

Stimmt nicht allgemein. Ich konnte sowohl im Grund- als auch im Hauptstudium Fächer wählen, in denen aktiv programmiert wird.

ok du lernst evtl ein paar sprachen und viel theorie.. aber wie es richtig geht lernst du nciht im studium.

Im Hauptstudium gab' es im o.g. Fach eine Abschlussveranstaltung, in welcher man in einer Gruppe eine Anwendung entwickeln musste. Auftraggeber war entweder der lehrstuhl selber, oder ein externes Unternehmen, z.B. im Zuge eines Forschungsprojektes.
Und bei jedem Projekt ist der Lehrstuhl immer aktiv involviert (regelmäßige Treffen, Zwischenstandsprüfungen, ...).

Ich für meinen Teil kann nur sagen, dass mir dieser Teil des Studiums am besten gefallen hat, und ich bzgl. aktiver Programmierung einiges gelernt habe (u.a. auch, dass man sich leider nicht immer auf Teammitglieder verlassen kann).

Aber zurück zum Thema:
Ich habe zwar erst in zwei verschiedenen Unternehmen gearbeitet, aber in beiden habe ich das Glück, dass den Entwicklern genug Freiraum gegeben wird, um das Produkt den eigenen Maßstäben entsprechend entwickeln zu können.

Das einzige Problem zur Zeit ist, dass ich der einzige C#-Programmierer mit Erfahrung bin und somit kein kritisches Input erwarten kann. Und gerade dass hat mir im Team immer gefallen, dass man teilweise durch Diskussionen (wie auch hier oft im Forum festzustellen) letztendlich zu einer völlig anderen aber teils auch viel besseren Lösung gelangen kann.

Nobody is perfect. I'm sad, i'm not nobody 🙁

H
222 Beiträge seit 2010
vor 13 Jahren

also bei mir in der firma sind 70% der software in cobol geschrieben, ich musste mich auch mal ne zeit lang damit beschäftigen, ein glück ist das vorbei... immer mehr wird mit java und c++ rangestrickt, weil cobol es einfach nicht bringt. und trotzdem wurde entschieden cobol bis zum letzten atemzug zu nutzen, also wirklich zukunftsorientiert ist das auch nicht wirklich. wobei man sagen muss, dass unsere kern-software (für zulassungsstellen, führerscheinstellen usw...) gigabyteweise quellcode hat. da dauert das umstellen ne weile 😃... ich denke wenn meine arbeitgeber die nächsten 10 - 15 jahre bestehen will muss sich einiges ändern...

wobei mich das nicht wirklich interresiert, da es ab september zur uni geht...

Die Welt hat genug für jedermanns Bedürfnisse, aber nicht für jedermanns Gier.

187 Beiträge seit 2009
vor 13 Jahren

Man verliert als Informatiker in einem Projekt auch schnell mal betriebswirtschaftliche Kenngrößen aus den Augen. Es ist leider nicht immer Möglich das perfekte Programm mit der perfekten Architektur zu schreiben. Es sind in der Regel einfach nicht genug Mittel da.

In meiner ehemaligen Firma (Autohersteller...) habe ich an einem Projekt gearbeitet das 1990 iniziert wurde. Ich habe noch nie in meinem Leben eine so durchdachte Architektur und so schönen Code gesehen. Aber da war auch kein Kostendruck da. Bei meiner Einstellung wurde mir gesagt: "Und wenn du 5 mal länger brauchst aber mach es RICHTIG.". Jeder Entwickler konnte im Architekturprozess mitreden und jede Änderung wurde vom kompletten Team besprochen und getragen. Im Prinzip das Paradies 😉

Fast forward in den Mai 2010:
Ich bin jetzt bei einem Consultingunternehmen und da bekomm ich den Kostendruck in voller Härte zu spühren...Da kann ich dem Kunden lange was von Wartbarkeit und Erweiterungsmöglichkeiten und dadurch entstehende Kostenersparnisse erzählen... die SW muss laufen und zwar ASAP.. wenn man in 4 Jahren nochmal das Doppelte reinschießen muss ist es egal.

Und mal etwas Offtopic am Rande aber die Aufwandsschätzungen der Entwickler sind ne einzige Kathasrophe (ich rechne i.d.R. nochmal 50-100% drauf) 😉

799 Beiträge seit 2007
vor 13 Jahren

Und mal etwas Offtopic am Rande aber die Aufwandsschätzungen der Entwickler sind ne einzige Kathasrophe (ich rechne i.d.R. nochmal 50-100% drauf) 😉

Das liegt vor allem daran, dass man das nicht unbedingt beigebracht bekommen hat. Als Anfänger hab ich mich auch immer grob verschätzt. Als vor kurzem ein Freund als Programmierer anfing, gab ich ihm den Rat (natürlich nicht ganz ernst gemeint) folgende Formel dafür zu verwenden: t = geschätzte zeit + 12 * rand(1, 12) in stunden.

As a man thinketh in his heart, so he is.

  • Jun Fan
    Es gibt nichts Gutes, außer man tut es.
  • Erich Kästner
    Krawutzi-Kaputzi
  • Kasperl
Gelöschter Account
vor 13 Jahren

eine akkuratere formel, die ich häufig verwende und vermittle ist "t = geschätzt * 2"
diese findet man auch häufig online als empfehlung.

deine formel wäre schon recht inakkurat bei kleinen und sehr großen änderungen. wenn ich 1 std für eine kleinigkeit brauche, kann ich nciht 24 std daraus machen (im extremfall) aber 2 stunden könnten es schon werden wenn ich probleme bekomme.

also bei mir in der firma sind 70% der software in cobol geschrieben.....gigabyteweise quellcode

ist doch normal bei cobol 😁

Man verliert als Informatiker in einem Projekt auch schnell mal betriebswirtschaftliche Kenngrößen aus den Augen. Es ist leider nicht immer Möglich das perfekte Programm mit der perfekten Architektur zu schreiben. Es sind in der Regel einfach nicht genug Mittel da.

das ist korrekt aber man sollte sich mit händen und füßen gegen das andere extrem wehren. wenn ich nciht mehr auf meine arbeit stolz sein kann und lieber behaupte, das ich kanalreiniger bin, bevor ich zugeben muss das ich an der software beteiligt war, dann muss man aktiv werden.

leider verlieren die betriebswirte allzu häufig die technischen auswirkungen und die betriebswitschaftlichen folgeschäden ihrer entscheidungen aus den augen....

187 Beiträge seit 2009
vor 13 Jahren

das ist korrekt aber man sollte sich mit händen und füßen gegen das andere extrem wehren. wenn ich nciht mehr auf meine arbeit stolz sein kann und lieber behaupte, das ich kanalreiniger bin, bevor ich zugeben muss das ich an der software beteiligt war, dann muss man aktiv werden.

Definitiv.

leider verlieren die betriebswirte allzu häufig die technischen auswirkungen und die betriebswitschaftlichen folgeschäden ihrer entscheidungen aus den augen....

Ja aber meiner Erfahrung nach sind das die Betriebswirte in den Kundenfirmen und nicht die der umsetzenden Dienstleister.
Und wenn ich als Diesntleister nur Betrag X für das Projekt bekomme und dies zu wenig ist dann spare ich entweder an den Features (was der Kunde nicht akzeptiert) oder an der Qualität (was er meist billigend in Kauf nimmt).

U
208 Beiträge seit 2008
vor 13 Jahren

Ich denke es ist nicht ganz richtig, die Schuld an schlecht wartbarem (oder evolvierbarem, wie es bei CCD heißt) Code nur den Betriebswirten zu geben. Klar, auf Architekturebene kann man als einzelner Entwickler nicht viel machen, aber man kann auch abseits dessen um guten Code bemüht sein. Wer die CCD-Prinzipien und -Praktiken soweit umsetzt, wie es ihm im Rahmen des Projekts möglich ist, wird die Codequalität schon erheblich steigern können.

Die Ausrede alá "Ich würde gerne sauberen/guten Code schreiben, wenn ich könnte/dürfte" würd ich da nicht gelten lassen. Man sollte sich in erster Linie immer an die eigene Nase fassen und darauf achten, das beste aus der gegebenen Situation zu machen. Und letztlich muss man auch zugeben können, dass man auch nicht der Super-Duper-Programmierer ist der alles richtig machen könnte wenn er die Zeit dazu bekäme. Oft fehlt es einem einfach am Know-how und das sollte man sich selber eingestehen können.

Zum Thema allgemein noch: Bei mir in der Firma sieht's zwiegespalten aus. Bei den Projekten, die ich alleine bearbeite, versuche ich so gut wie möglich nach CCD zu arbeiten und eine gute, komponentenorientierte Architektur zu erstellen.
Wenn ich dann aber einige ältere Projekte aufmachen muss wird's teilweise sehr haarsträubend...

2.921 Beiträge seit 2005
vor 13 Jahren

@Isaac:

Es sind nicht nur die, manchmal sind es auch die Projektleiter die aktiv mitprogrammieren.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

F
58 Beiträge seit 2009
vor 13 Jahren
Unfähige (Pseudo-)Softwarearchitekten

Das muss ich mir mal von der Seele reden.
Man studiert 4+ Jahre Informatik. Man lernt Softwareengineering, Prozessarten, UML, Entwurfsmuster, Design-Prinzipien, Unit Tests, etc pp. Man ist ein Mathecrack und legt eine sehr gute Diplomarbeit hin.

Dann kommt man in eine Firma mit einem selbsternannten "Softwarearchitekten".
Der steuert quasi im Alleingang alle Softwareprojekte in der Firma, hat aber von der Theorie eines Entwicklungsprozesses keinen blassen Dunst. Und regt sich auf, dass er überlastet ist, und ihm niemand Arbeit abnehmen würde. Die Standardlösung - wie man es von so jemand erwartet - ist, Überstunden anzuordnen um im Zeitplan zu bleiben. Bei Kundenanforderungen wird übers Ziel hinaus geschossen, eine Entwurfsphase war praktisch nicht vorhanden und eine professionelle Herangehensweise an Probleme erst recht nicht (mal ein Buch oder Paper aufschlagen, oder nach einem passenden Algorithmus suchen, denkste).

If noobs would rule the world.

EDIT: Ich wollte nochmal einen Auszug aus dem Buch "Cash Code" beisteuern.

Drohten die resultierenden Probleme dann das Projekt zu gefährden, wurden die
entsprechenden Maßnahmen ergriffen. Das Spektrum reichte dabei von erzwungenen
Überstunden über Outsourcing bestimmter Aktivitäten und Gehaltskürzungen bis hin zum
Erzeugen von sozialem Druck. Der Maßnahmenkatalog wurde dabei wie aus einem Reflex
heraus eingesetzt, ohne jedoch die gewünschte Wirkung zu erzielen. Der höhere Druck auf
die Mitarbeiter konnte keine spürbar höhere Produktivität, und auch keine höhere Qualität
erzeugen. Es stellte sich immer wieder heraus, dass bestimmte Aufgaben ganz offensichtlich
eine konstante Zeit benötigten, unabhängig von den äußeren Umständen.

Bin ja heilfroh, dass ich privat entwickeln kann wie ich möchte und so meine Erfahrung sammle.

H
222 Beiträge seit 2010
vor 13 Jahren

also da ich in einer kleinen firma arbeite (7 programmierer) hab ich weitestgehend freie hand was meine projekte betrifft. ich kann sie so schreiben wie ich es für richtig halte, was nicht immer von vorteil ist, da keiner meinen code prüft... aber ich habe es mir recht schnell angewöhnt meinen code (sofern ich zeit habe) immer mal wieder durchzuchecken und meine lösungswege ständig in frage zustellen. denn ich glaube es ist in der wirtschaft wie in der evolution, wer stehen bleibt stirbt. meiner meinung nach muss man ständig veränderungen herbeiführen.

oder wie ein sprichwort besagt:

the more things change the more they stay the same...

schönen abend noch

hurby

Die Welt hat genug für jedermanns Bedürfnisse, aber nicht für jedermanns Gier.

1.433 Beiträge seit 2006
vor 13 Jahren

Im Grunde genommen ähneln sich sehr viele Firmen. Bei mir ist es so:

  • Kurz spezifizieren
  • Wenn noch Fragen offen sind Annahmen treffen und implementieren

und zum Schluss sich wundern wieso der Kunde meint er habe das nicht gewollt. Am Wichtigsten ist so oder so eine saubere Requirements Analyse in welcher wirklich komplett alle Kunden angefragt und ihre Anforderungen abgeholt werden, erst dann das Design etc.

Ich versuch mich gerade das gerlente von der Schule in der Firma einzubringen, es ist aber schwer wenn die Leute das Gewohnte nicht einfach so aufgeben wollen und sich an das "nicht-Optimal" gewöhnt haben.

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

Fabian Themenstarter:in
1.985 Beiträge seit 2004
vor 13 Jahren

Hallo zusammen,

[...] es ist aber schwer wenn die Leute das Gewohnte nicht einfach so aufgeben wollen und sich an das "nicht-Optimal" gewöhnt haben.

das finde ich das schlimmste an der Sache. Dieser Tunnelblick, der sich einstellt. Frei nach dem Motto "habe ich immer schon so gemacht, mache ich auch weiterhin so". Die Leute sind dann nach einiger Zeit so betriebsblind, dass sie echte Schwierigkeiten bekommen, wenn es dann mal anders laufen soll oder muss. Sei es durch einen Firmenwechsel, oder weil sich in der ursprünglichen Firma doch was ändert.

Gruß,
Fabian

"Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vornherein ausgeschlossen erscheint." (Albert Einstein)

Gefangen im magischen Viereck zwischen studieren, schreiben, lehren und Ideen umsetzen…

Blog: www.fabiandeitelhoff.de

390 Beiträge seit 2008
vor 13 Jahren

Hallo Zusammen

Frei nach dem Motto "habe ich immer schon so gemacht, mache ich auch weiterhin so".

Ein solches Verhalten kenne ich aber auch von den Nutzern, wenn es um die Migration von alten Anwendungen geht: Man möchte es halt so, wie es bereits war. Nie wird in Frage gestellt ob man das überhaupt noch so braucht oder es nicht irgendwie besser und für den Nutzer angenehmer ginge.

using Skill

Gelöschter Account
vor 13 Jahren

dieses verhlaten ist nciht branchenspezifisch. es scheint sogar eher eine allgemeine menschliche eigenschaft zu sein, die bei jedem existiert, nur manchmal eben recht stark ausgeprägt ist.

1.433 Beiträge seit 2006
vor 13 Jahren

dieses verhlaten ist nciht branchenspezifisch. es scheint sogar eher eine allgemeine menschliche eigenschaft zu sein, die bei jedem existiert, nur manchmal eben recht stark ausgeprägt ist.

Oder eben aus "Faulheit" weil man vor dem Neuen Angst hat...

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

6.911 Beiträge seit 2009
vor 13 Jahren

dieses verhlaten ist nciht branchenspezifisch. es scheint sogar eher eine allgemeine menschliche eigenschaft zu sein, die bei jedem existiert, nur manchmal eben recht stark ausgeprägt ist.

Das ist eher ein ganz natürliches Grundprinzip: Der Weg des geringsten Widerstands.
Nur wenige erkennen dass der Widerstand geringer werden kann wenn man zuerst mit etwas Energie eine Hürde bewältigt...

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

M
368 Beiträge seit 2006
vor 13 Jahren

hat aber von der Theorie eines Entwicklungsprozesses keinen blassen Dunst.

In dem Zusammenhang das Ergebnis einer Umfrage von dzone.com zum Thema Verbreitung und Nutzung von UML: [DZone]Are UML still widely used ?

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

Fabian Themenstarter:in
1.985 Beiträge seit 2004
vor 13 Jahren

Hallo zusammen,

dieses verhlaten ist nciht branchenspezifisch. es scheint sogar eher eine allgemeine menschliche eigenschaft zu sein, die bei jedem existiert, nur manchmal eben recht stark ausgeprägt ist.

da hast Du Recht. Das Verhalten ist überall anzutreffen. Wenn man in der Softwareentwicklung tätig ist, sollte es meiner Meinung nach aber weniger stark ausgeprägt sein. Der Wille zur (ständigen) Veränderungen sollte schon vorhanden sein. Wie stark ausgeprägt, ist dann immer noch die andere Frage.

Nur wenige erkennen dass der Widerstand geringer werden kann wenn man zuerst mit etwas Energie eine Hürde bewältigt...

Schön gesagt!

Gruß,
Fabian

"Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vornherein ausgeschlossen erscheint." (Albert Einstein)

Gefangen im magischen Viereck zwischen studieren, schreiben, lehren und Ideen umsetzen…

Blog: www.fabiandeitelhoff.de