Laden...

Alltag in unserer Branche (?)

Erstellt von Fabian vor 15 Jahren Letzter Beitrag vor 13 Jahren 42.818 Views
Fabian Themenstarter:in
1.985 Beiträge seit 2004
vor 15 Jahren
Alltag in unserer Branche (?)

Hallo zusammen,

manchmal bin ich schon recht frustriert. Ich habe das Gefühl, in unserer Branche wird gefrickelt was das Zeug hält. Hauptsache es läuft. Was morgen, übermorgen oder noch weiter in der Zukunft passiert, weil beim Programmieren mal wieder nicht bis 5 gedacht wurde, scheint keinen zu interessieren.

Wie sieht das bei Euch aus? Wie viel Methodik steckt in Eurem Alltag? Nicht nur bei Euch selber, sondern in Euren Unternehmen? Seid Ihr mit dem aktuellen Stand glücklich, oder würdet ihr manchmal gerne (wie ich) einfach aufstehen und gehen, weil ihr die Hoffnung aufgegeben habt?

Wie geht Ihr mit der Situation um? Sich dran gewöhnen? Einfach abstumpfen und es nach kurzer Zeit genau so machen? Ständig gegen ankämpfen? Zuerst habe ich gedacht, dass ich vielleicht auch irgendwann abstumpfe oder es mir schlicht egal wird. Mittlerweile sehe ich das nicht mehr so. Ich will für mich daran was ändern und mich mit der Situation nicht zufrieden geben. Ändern kann ich aktuell und in mittlerer Zukunft aber wahrscheinlich nichts an der Situation. Vielleicht nur die kleinen Code-Teile sauber halten, für die ich verantwortlich bin.

Ich habe da gerade mal wieder länger drüber nachgedacht, nachdem ich den folgenden Kommentar im Code gefunden habe:

Hauptsache, wir können kompilieren...

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

458 Beiträge seit 2007
vor 15 Jahren

Willkommen in der realen Welt.

be the hammer, not the nail!

R
234 Beiträge seit 2007
vor 15 Jahren

Also bei uns sieht das leider ziemlich ähnlich aus. Zeit ist Geld heißt es ja immer ... ich denke aber, dass man auf längere Sicht günstiger davonkommt, wenn man sich beim Entwurf und der (durchdachten) Implementierung etwas mehr Zeit lässt und wartbaren Code produziert. Naja, davon will die "Obrigkeit" aber erstmal überzeugt werden. 🙂

Ich halte es ähnlich wie du - ich versuche meinen Teil übersichtlich und wartbar zu halten und wenn ich dann mal an fremden Code rumschraube versuch ich halt das beste draus zu machen.

/Edit: Böse Rechtschreibfehler ...

Gelöschter Account
vor 15 Jahren

ich habe festgestellt, das die größe des code-misthaufens proportional zur größe des projektes zunimmt. daher habe ich kleinere projekte, wo ich mehr kontrolle habe am liebsten.

am allerliebsten habe ich projekte, wo ich die aufsicht habe (also leitung mit coden zusammen), denn da schaue ich regelmäßig durch den code und spreche die leute sofort darauf an, wenn mir etwas nciht passt.

ansonsten hilft nur noch kopf in den sand stecken und seinen eigenen stall sauber halten.

32 Beiträge seit 2009
vor 15 Jahren

Hallo,

Ich wurde vor einem Jahr in einer neuen Firma in ein Projekt geworfen, andem ich allein weiter arbeite. Das Problem ist, dass der Vorgänger nicht mehr da war um mich einzuarbeiten und ich habe mich durch seinen Code gewühlt.

Da sind mir ein paar Sachen aufgefallen, da hatte ich nur den Kopf geschüttelt und mich gewundert, dass die Software überhaupt funktioniert 🙂

Er hat wohl wirklich nach dem von dir angesprochenen Prinzip gearbeitet.

Ich habe daraufhin, meinem Chef die interessantesten Code-Schnipsel rauskopiert und ihm das alles gezeigt. (Er kennt sich Gott-Sei-Dank in der Softwareentwicklung aus) Er selbst konnte mir das ganze sogar erklären.

Es gab ein Konzept, nachdem die Software erstellt wurde. Doch der Kunde ist ja König (ja...immer noch 😄) und wollte eine Änderung nach der anderen...am besten gestern...da bleibt nicht immer Zeit um sich ein richtiges Konzept zu überlegen... Da wird einfach drauflos programmiert.

Später wirst du es bereuen und dann noch mehr Zeit investieren, um deine Fehler auszubügeln...oder bei weiteren Wünschen des Kunden es komplett umzuschreiben...aber

der Kunde bezahlt und das ist alles was zählt.

Daher...Kopf hoch und gar nicht darüber nachdenken..

Gruss
Christian

PS:
Bei uns heißt das erfolgreiche Kopilieren "Der Christian - Test wurde bestanden" 😁

Rambo: "Das war nicht mein Krieg. Ich bin nur hier, um den Dreck wegzuräumen."
Programmierer: "Das ist nicht mein Code. Ich mache nur die Fehler raus."

3.511 Beiträge seit 2005
vor 15 Jahren

Tja, in der Firma wo ich vorher war (war noch zu Delphi-Zeiten), bin ich irgendwann aufgestanden und gegangen. Ich hab in der Firma angefangen, als da schon ein Chaos herrschte, das es echt ein Wunder war, das die Software überhaupt lief. Habe versucht zu retten was zu retten war, aber irgendwann ging es zu sehr an die Nerven und habe aufgegeben. Hauptgrund war, das die Geschäftsführung den Kunden immer alles versprochen hat, nach dem Motto "Ja, kein Problem. Haben sie nächste Woche". Dummerweise sollte man vielleicht mal jemanden vorher fragen, der sich damit auskennt. Naja...

Da wo ich jetzt bin, läuft es schon viel viel geordneter/besser. Sicherlich gibt es immer wieder Stellen (Klassen, Methoden) die man gerne neu schreiben würde, weil Teile noch aus dem 1.1 Framework kommen (was teils auch sehr nervt). Aber ansonsten ist alles geregelt. Zeit genug hat man eigentlich immer, man kommt nur in Zeitdruck wenn man selber pennt. Kurz und knapp, ich bin momentan sehr zufrieden. Es wird vorher über Softwareänderungen/neuerungen diskutiert und alles genau geprüft, wie sich die Änderungen integrieren. Also, ob es überhaupt sinnvoll ist, ob die Arbeit den Nutzen rechtfertigt usw...

Es ist eigentlich ziemlich interessant beide Seiten kennengelernt zu haben (totales Chaos, totale Ordnung). Anhand der Erfahrungen aus der alten Firma, weis ich was zu schlechten Ergebnissen führt und kann immer brav gegen an gehen. Ich könnte ein Buch schreiben über "Softwareentwicklung - So macht man es nicht". Und diese Erfahrung war echt gut im nachhinein.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo Fabian,

mir war gute Architektur und "schöner" Code immer wichtig und ich hatte meistens auch das Glück, genug Zeit zu haben, um das auch erreichen zu können.

herbivore

T
511 Beiträge seit 2008
vor 15 Jahren

Bislang kannte ich das von meiner alten Firma nur immer so:

1.) es kommt eine Anforderung rein
2.) man prüft die Anforderung auf Machbarkeit
3.) man schätzt den Aufwand
4.) es wird ein Fachkonzept erstellt
5.) es wird ein DV-Konzept erstellt
6.) nach Konzept wird umgesetzt, weitere Anforderungen/Änderungen hinten angestellt
7.) es wird getestet
8.) Freigabe

Mittlerweile läuft das bei meinem neuen Arbeitgeber auch anders:

1.) es kommt eine Anforderung rein
2.) man prüft ggf. noch auf Machbarkeit
3.) man programmiert drauf los
4.) und wartet ab ob das Ergebnis dem Kunden gefällt

😦

Nicht für das Leben, für die Arbeit lernen wir ...
Windows ist Klasse, ich nehme es um Linux zu downloaden ....

458 Beiträge seit 2007
vor 15 Jahren

1.) es kommt eine Anforderung rein
2.) man prüft ggf. noch auf Machbarkeit
3.) man programmiert drauf los
4.) und wartet ab ob das Ergebnis dem Kunden gefällt

So kenn ich das auch.. nur ohne 2.

be the hammer, not the nail!

T
511 Beiträge seit 2008
vor 15 Jahren

na, mir ist die 2 schon wichtig.

Ich hab oft genug einem Kunden sagen müssen, das ist so nicht umsetzbar.
Nur das vorher Chefe gesagt hat: Ist doch alles kein Problem, machen wir.

Nicht für das Leben, für die Arbeit lernen wir ...
Windows ist Klasse, ich nehme es um Linux zu downloaden ....

42 Beiträge seit 2008
vor 15 Jahren

Hi,

In der Firma in der ich zeitweise Praktikum gemacht hab hat es meist 2 Wochen
gedauert bis man überhaupt angefangen hat mit Coden denn da wurde immer erst ein
genauer Ablaufplan erstell mit Versionskontrolle bis ins kleinste Detail.

Und jetzt bin ich bei einer kleinen Firma in der das nicht so ist. Hier geht zwar auch
immer jemand anders noch über den Code und guckt ihn sich an bevor Kompailiert
wird.

Mfg Lisko

T
511 Beiträge seit 2008
vor 15 Jahren

Richtiges Vorgehen: (leider zu wenig umgesetzt, da vielen Firmen zu teuer)

In der Firma in der ich zeitweise Praktikum gemacht hab hat es meist 2 Wochen
gedauert bis man überhaupt angefangen hat mit Coden denn da wurde immer erst ein
genauer Ablaufplan erstell mit Versionskontrolle bis ins kleinste Detail.

Falsches Vorgehen: (meist gesehen)

Und jetzt bin ich bei einer kleinen Firma in der das nicht so ist. Hier geht zwar auch
immer jemand anders noch über den Code und guckt ihn sich an bevor Kompailiert
wird.

Allerdings frag ich mich immer wieder.
Annahme: Kunde zahlt 25.000,- für´s Programm, kriegt es schnell aber es hat Fehler, es wird "kostenpflichtet" nachgebessert!
oder: Kunde zahlt 35.000,- für´s Programm und es ist mehr oder weniger fehlerfrei.

Der Kunde wäre sicher mehr für Punkt 2, Dein Chef eher für Punkt 1, da er mehr verdienen kann. Naja, vielleicht würde ich als Chef genau so handeln. Trotzdem arbeite ich lieber nach Plan.

Nicht für das Leben, für die Arbeit lernen wir ...
Windows ist Klasse, ich nehme es um Linux zu downloaden ....

3.511 Beiträge seit 2005
vor 15 Jahren

Hier hängt es echt stark von der Geschäftsführung ab. Entweder man hat ein Chef, der mehr Verkäufer ist, also schnell schnell. Oder man hat ein Chef der auch Wert auf Qualität legt, also planen und mit dem Kunden die Anforderungen durchdenken.

Leider kenne ich es auch von vielen bekannten Entwicklern, das es mehr in Richtung schnell schnell tendiert.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

42 Beiträge seit 2008
vor 15 Jahren

Naja man muss aber auch noch sagen das die Planung des Projekts
mit dem Kunde gemacht wird ( die zwei Wochen) und ich glaube deshalb ist man dort
in der Lage "Methode 1" zu benutzen.

4.506 Beiträge seit 2004
vor 15 Jahren

Hallo zusammen,

ich muss zugestehen, dass ich ziemlich die gleichen Erfahrungen wie Khalid gemacht hab (Beitrag von 14:56 heute).

Ich war bisher bei einigen kleineren bis mittelständischen Unternehmen, bei denen Codedesign darin bestand es kompilierfähig zu machen.
Inzwischen bin ich in einem Großunternehmen und arbeite in einem richtig großen Projekt, bei dem es schlichtweg bedeutet: In einer Tagesverarbeitung auf dem Produktivsystem steckt so viel Kohle drin, dass es einfach nicht bezahlbar wäre, wenn das System grob fehlerhaft wäre.

Da in der heutigen Zeit aber auch Softwareänderungen in der Tagesordnung zu finden ist, muss alles eben hochgradig dynamisch und konfigurativ gelöst werden.

Bei uns ist es so, dass bei einer Beauftragung es ca. 3-6 Monate dauert bis angefangen wird zu programmieren (Ausnahme Proof of Concepts [Machbarkeitsstudie]). Bis dahin werden Scope- und Designsitzungen mit Kunden, Projektleitern und auch Entwicklern gemacht.

Deshalb kann ich nur bestätigen, in der breiten Masse wird wahrscheinlich QuickAndDirty Programmierung vorzufinden sein, aber wenn man das Vergnügen hat, in einem strukturierten Projekt mitzuarbeiten, dann will man nicht mehr anders.

Grüße
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

1.200 Beiträge seit 2007
vor 15 Jahren

Wie ist das an meinem gegenwärtigen Projekt?

Siehe Coding Styles Horror

Noch Fragen?

Wie gehe ich damit um? Es ist frustrierend. Refactoring ist nicht möglich, da man, wenn man einen kleinen Teil verändern und besser strukturieren will, fast so gut wie alles andere bricht. Würde man iterativ vorgehen, bräuchte man sicher genau so lange um das Ding auf Vordermann zu bekommen, wie die Entwicklung insgesamt bisher gedauert hat.

Neu schreiben ist auch unmöglich, da einfach in der Flut der Mini CRs nicht genug Zeit ist, sich darauf einzulassen.

Zum Glück hab ich das bald hinter mir.

Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

YARRRRRR!

F
10.010 Beiträge seit 2004
vor 15 Jahren

Sowohl das gar nicht Planen, wie auch das erst alles Planen und dann umsetzen
haben bei mehr als 50% der in der Branche durchgeführten Projekte
zu deren Scheitern beigetragen/dieses ausgelöst.

Vielleicht ist das Thema Agile Softwareentwicklung doch noch nicht so
in der allgemeinen SW-Entwicklung bekannt, was schade ist.

Leider wird an Universitäten dieses Thema immer noch viel zu Stiefmütterlich
behandelt, so das die meisten Studienabgänger leider mit den Techniken
arbeiten, die in den 80ern schon nicht wirklich geholfen haben.

Da ich auch beide Seiten kenne, sind aber auch die Entwickler mit "schuldig" an
diesem Dilema.

  1. Natürlich braucht die GF/der Vertrieb eine Möglichkeit etwas flexibler in der Entwicklung zu sein.
  2. Natürlich muss die GF genug Informationen über den Fortgang der Entwicklung haben.
  3. Sollte die Zeitplanung in einem für die GF nachvollziehbaren Rahmen eingehalten werden.

Leider sind SW entwickler in diesen 3 Punkten meist nicht so "zuverlässig"
wie die GF sich das wünschen würde, weshalb man in grösseren Firmen dazu
übergegangen ist, zuviel Bürokratie einzuführen.

Und schlechter Code liegt selten an der GF.
Wer halt die Grundlagen nicht beherrscht wird auch im optimalen Umfeld
keine vernünftige SW erstellen.
Und Umgekehrt, kann man mit den richtigen herangehensweisen auch im hochagilen
Umfeld einigermassen wartbare SW erstellen.

Wer aber in ein Projekt kommt, das "verhunzt" ist, hat halt dann wirklich Pech gehabt.

J
1.114 Beiträge seit 2007
vor 15 Jahren

Siehe
>

Oh je, das kommt mir aber auch schwer bekannt vor. Ich durfte ein Projekt von einem Praktikanten übernehmen (wovon ich vorher nix wusste), und bin ständig auf solchen Mist gestossen (statische Klasse ad absurdum). Und noch schlimmer: Die statischen Klassen lagen in einem Webservice und wurden von zisch Clients angesprochen. Das Desaster war perfekt! Und hätte ich von vorneherein die ganze Misere durchblickt (es war wirklich schlimm), hätte ich wahrscheinlich alles neu programmiert. Nicht nur der C# Code war die Hölle, sondern auch das Datenbankdesign dahinter ist katastrophal. Ich hab dann tatsächlich 3 Monate damit verbracht, den Code so umzubiegen, damit die Software dann heute doch irgendwie läuft. Meine Lösung wäre "Neuschreiben" gewesen, aber das war leider nicht möglich.

H
154 Beiträge seit 2007
vor 15 Jahren

arbeite freiberuflich,

eine kunde von mir, eine softwarefirma, hat ein 1A framework. echt der hammer. es ist eine sehr komplexe applikation mit vieler, zT sehr anspruchsvoller businesslogik (Versicherungen etc.). also eine langfristige investition. da lohnt sich natürlich der aufwand für so ein frame work und entsprechender methodik.
das framework reduziert die komplexität der basistechnologien wie persistenz, gui etc. extrem, so dass der entwickler sich auf die entwicklung von businesslogik konzentrieren kann. qualitätskontrolle wird durch 4-augen prinzip des sourcecode, manuelles und maschinelles testing gewährleistet.
das ergebnis ist super.

bei einem ehemaligen arbeitgeber haben sich mir auch die haare aufgestellt. und da bin ich dann auch gegangen. die architektur lässt sich am besten als sumo hochzeit beschreiben, leider etwas dass man (aus meiner erfahrung) noch sehr häufig antrifft.
http://de.wikipedia.org/wiki/Antipattern

andererseits muss ich sagen, dass ich bei kundenspezifischen projekten, die nicht extrem umfangreich sind, auch schon mal straight-forword programmiere. klar zugunsten der kosten die der kunde nie zahlen würde. frei nach nach dem motto: "ich arbeite zwar manchmal vergebens, aber nie umsonst" 😃

32 Beiträge seit 2009
vor 15 Jahren

In meiner Ausbildung sollte ich mal ein Programm überarbeiten und was fand ich da?

Es war eine Form in der man Labels finden konnte, wenn man diese vergrößert. Diese waren unsichtbar für den Anwender und hielten Informationen zum zwischenspeichern...das war nicht witzig sag ich euch...

Rambo: "Das war nicht mein Krieg. Ich bin nur hier, um den Dreck wegzuräumen."
Programmierer: "Das ist nicht mein Code. Ich mache nur die Fehler raus."

H
154 Beiträge seit 2007
vor 15 Jahren

how bizzare.... 😃

S
156 Beiträge seit 2007
vor 15 Jahren

Es war eine Form in der man Labels finden konnte, wenn man diese vergrößert. Diese waren unsichtbar für den Anwender und hielten Informationen zum zwischenspeichern...das war nicht witzig sag ich euch...

Das hat mir doch grad echt an diesen nicht so tollen Tag (Doku schreiben) ein schmunzeln breitet. Danke dafür 😃

4.207 Beiträge seit 2003
vor 15 Jahren

Ein Hauptproblem ist aber auch, dass die Projektleiter den Aufwand oft unter- und die Entwickler sich überschätzen.

Ich stelle es gerade selbst fest: Zu zweit (Peter Bucher und ich) arbeiten wir derzeit an einem eher kleinen Projekt, wo wir beide seit etlichen Wochen jeden Tag mehrere Stunden dransitzen.

Unser Ziel ist - abgesehen davon - dass nachher alles funktioniert, auch, eine saubere Architektur hinzubekommen, eine gute Testabdeckung zu haben, ... und das kostet unglaublich viel Zeit!

Wenn man guckt, was das Ding für den Endanwender kann, fragt man sich, wie wir da länger als einen oder zwei Tage dransitzen.

Wenn man sich die Architektur ansieht, weiß man es.

Ich bin aber unendlich froh, dass wir uns diese Arbeit machen und uns die zeit dafür nehmen, denn wir haben schon etliche Male festgestellt, dass die Architektur extrem tragfähig ist und die einzelnen Komponenten problemlos austausch- und erweiterbar sind.

Die Frage ist halt, ob es das in kommerziellen Projekten den Entwicklern bzw Projektleitern auch wert ist ... und wenn ja, dann braucht man eben verdammt viel Zeit.

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

Hallo Golo

Die Frage ist halt, ob es das in kommerziellen Projekten den Entwicklern bzw Projektleitern auch wert ist ... und wenn ja, dann braucht man eben verdammt viel Zeit.

Für ein Framework oder für eine neue Anwendung von Grund auf, würde ich das auf jeden Fall investieren.

Ich sehe das grösste Problem darin, dass es den Managern / Leitern mehr ums Geld geht und das weitsichtige Denken fehlt.
Wenn eine Software - oder noch schlimmer - ein Framework steht und man dann dran rummurkens muss, verliert man viel mehr Zeit als die die investiert worden wäre, um das richtig zu machen.

Zudem macht die Arbeit daran mehr Spass und die Einarbeitungszeit für neue Mitarbeiter ist geringer.
Schlussendlich ergeben sich aus einer besseren Vorgehensweise, sowohl Vorteile für den Entwickler, sowie auch der Firma selber.

Gruss Peter

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

F
10.010 Beiträge seit 2004
vor 15 Jahren

Wobei es dann meist die Frage ist, ob man soetwas selber entwicklen "muss",
oder ob man etwas fertiges nimmt.

Leider haben gerade diejenigen SW-Entwickler, die etwas von Architektur verstehen
meist die Angewohnheit ein Framework benutzen zu wollen, das ganz genau
ihren Ansprüchen entspricht.

Und das führt dann dazu, das es so viele Teile gibt, die leider zigfach neu geschrieben
werden, statt das sich diese Leute zusammentun, oder Kompromisse eingehen.

Gutes Beispiel sind die derzeit auf dem Markt befindlichen IOC Container.

Ich benutze jetzt seit jahren CAB/SCSF, das hat sicherlich seine Schwächen,
aber es ist ein extrem vielseitiges, flexibles und durchdachtes FW,
das für MiniApps ( dann nur CAB ) oder Enterprise Apps vollkommen reicht.

Allerdings hat man das Problem, das die Testbarkeit durch die Workitems etwas leidet.

S
683 Beiträge seit 2006
vor 15 Jahren

Ihr werdet mich jetzt hassen aber ich bin auch ein Code Schlamper...
Nachdem ich damit aber beim letzten Projekt auf die Nase gefallen bin, in dem die Bug behebung in der Beta ewig gedauert hat, möchte ich nun daran Arbeiten und Professioneleren Code produzieren. Auch dank eines Artikels in der dotnetpro...

Ich hoffe dass ich nun demnächst eine Schulung für Softwareentwicklung machen kann.

Hat jemand vielleicht eine Idee welche Hilfen es gibt ein Professioneller(er) Entwickler zu werden?

Eine Null kann ein bestehendes Problem verzehnfachen

5.941 Beiträge seit 2005
vor 15 Jahren

Hallo s0h0

Hat jemand vielleicht eine Idee welche Hilfen es gibt ein Professioneller(er) Entwickler zu werden?

Ja, auf jeden Fall.

  • Erfahrung sammeln
  • Willen zeigen
  • Dich mit Prinzipien befassen
  • Dich mit Design Patterns und Architektur befassen
  • Fremden Code lesen

Schau dir mal folgende Seite an:

Gruss Peter

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

H
154 Beiträge seit 2007
vor 15 Jahren

Wobei es dann meist die Frage ist, ob man soetwas selber entwicklen "muss",
oder ob man etwas fertiges nimmt.

Leider haben gerade diejenigen SW-Entwickler, die etwas von Architektur verstehen
meist die Angewohnheit ein Framework benutzen zu wollen, das ganz genau
ihren Ansprüchen entspricht.

du hast nicht ganz unrecht, ich denke aber dass es für komplexe, "grosse" anwendungen schon sinn macht sich etwas optimales in seiner domäne zu bauen, so dass man in seiner domäne eine hohe produktivität hat.

für kleinere projekte stimme ich dir zu.

143 Beiträge seit 2008
vor 15 Jahren

Dies ist ganz klar kein Problem der Softwareentwicklung, sondern ein Problem in allen Bereichen der Wirtschafft.
Ich kann da immer nur sagen, alles ist in einem Zielekonflikt. Es ist immer eine Frage der Sichtweise.

Beim Maschinenbau weis z.B. häufig der Werkstoff/Methode der Herrstellung ist besser geeignet als die andere, aber er ist teurer oder man hat schlicht das Know How nicht um diesen zu verwenden. Dann werden Wartungintervalle hochgeschraubt und dann passt es doch wieder irgendwie. Auch daran verzweifeln Leute.

In einem Team, kann man nur auf dem Wissenstand arbeiten den alle Mitarbeiter die mit der Sache zu tun haben, auch teilen. Und selbst davon muss man noch abstriche machen. Da man sich lieber erstmal beim alten bleibt, da man schon bewiesen hat das es funktioniert. Seit doch froh das ihr zu den gehören um die sich die Firma keine Sorgen machen muss, dass ihr mitkommt. 👍 😁

Also verzweifelt nicht, persöhnlich ist man immer schneller, als ein Organisation.

Gruß Timo

4.207 Beiträge seit 2003
vor 15 Jahren

Hat jemand vielleicht eine Idee welche Hilfen es gibt ein Professioneller(er) Entwickler zu werden?

Guck mal hier: http://www.des-eisbaeren-blog.de/post/2008/11/27/Architektur-lernen.aspx

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

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

4.207 Beiträge seit 2003
vor 15 Jahren

du hast nicht ganz unrecht, ich denke aber dass es für komplexe, "grosse" anwendungen schon sinn macht sich etwas optimales in seiner domäne zu bauen, so dass man in seiner domäne eine hohe produktivität hat.

für kleinere projekte stimme ich dir zu.

Gerade bei großen Projekten macht es IMHO nicht unbedingt Sinn, weil zu viel Zeit und Energie drauf geht ... meistens ist das ein typischer Fall des "Not invented here"-Syndroms.

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

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

1.130 Beiträge seit 2007
vor 15 Jahren

[unqualifiziert=Senf dazu]Eigentlich ist es das NIH-Syndrom pur, wenn man das .net Framework nicht verwendet.[/unqualifiziert]

Projekte:Jade, HttpSaver
Zum Rechtschreiben gibts doch schon die Politiker. Aber die bauen auch nur mist!

S
683 Beiträge seit 2006
vor 15 Jahren

Ich glaub ich hol mir mal ein rotes Bändchen, das erinnert mich dann vielleicht immer daran, sauberer zu Arbeiten...

Hat schon jemand so ein Armband?

PS: Irgendwie erinnert mich diese Diskussion an 'Pfusch am Bau'.

Eine Null kann ein bestehendes Problem verzehnfachen

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo,

s0h0 hat vielleicht garnicht so unrecht. Wenn man nicht höllisch aufpasst oder (wie manche meiner Firmen-Kollegen) gar keinen Wert drauf legt, hat man in nur wenigen Zeilen "Pfusch am Bau".

Gruß
Juy Juka

4.207 Beiträge seit 2003
vor 15 Jahren

Ich hätte gerne eins gehabt, aber da waren die schon ausverkauft ... gibt's schon wieder welche?

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

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

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

Hallo zusammen,

danke für die rege und konstruktive Diskussion. Auf der einen Seite bin ich etwas erleichtert, dass diese Situation nicht nur bei mir vorherrscht. Auf der anderen Seite tut es mir natürlich auch leid für Euch, dass es eben so ist wie es ist 😃.

Augen zu und durch, heißt es da wohl.

Schau dir mal folgende Seite an:

Diese Seite und die dahinter stehende Idee kann ich sehr empfehlen und unterstützen. Mal sehen, ob es was bringt.

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

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo Fabian,

Augen zu und durch, heißt es da wohl.

das würde ich aus dem Thread nicht schließen. Es gab doch im Gegenteil genug, die gesagt haben, dass sie die Situation genauso leid waren wie du und durch einen Wechsel des Arbeitgebers (deutlich) verbessern konnten.

herbivore

691 Beiträge seit 2007
vor 15 Jahren

Also ich habe beruflich immer halbwegs sauber programmieren müssen, da viel Wert auf Wiederverwendbarkeit gelegt wurde. Ansich eine gute und nachvollziehbare Sache =)

Hat schon jemand so ein Armband? Interessant? Was für nen Armband soll das sein? Solange es nicht so nen Gummiteil ist, bin ich nicht abgeneigt mir auch sowas zu holen =)

Edit: http://www.clean-code-developer.de/wiki/CcdArmband
Hmm. Die Idee eines solchen Armbands gefällt mir schon, allerdings das Armband selber nicht. Hat jemand ne gute Alternative? (Jetzt bitte nicht antworten mit "Gute Programmierung muss allgegenwärtig sein" oder "dafür braucht man doch gar keinen Schmuck" 😃 )

mit freundlichen Grüßen,
Tomot

Projekte: www.gesellschaftsspieler-gesucht.de

S
683 Beiträge seit 2006
vor 15 Jahren

Hat jemand ne gute Alternative?

Lass es dir auf den Unteram tätowieren 😃

http://www.clean-code-developer.de/

Wirklich eine super Seite und gut geschrieben, schon nach dem Lesen der Regeln und Muster für das rote Band gingen mir 3 Lichter auf.

Ich hätte gerne eins gehabt, aber da waren die schon ausverkauft ... gibt's schon wieder welche?

Steht noch ausverkauft da, angeblich Mitte Januar wieder... Welche Farbe willst du dir den holen?

Das Armband soll ja denke ich auch kein modisches Accessoire sein sondern einen daran erinnern nach welchen Regeln und Grundsaetzen man handeln möchte. Ich werde es auch nicht sichtbar sondern spürbar tragen..

Eine Null kann ein bestehendes Problem verzehnfachen

4.207 Beiträge seit 2003
vor 15 Jahren

Ich hätte gerne eins gehabt, aber da waren die schon ausverkauft ... gibt's schon wieder welche?
Steht noch ausverkauft da, angeblich Mitte Januar wieder... Welche Farbe willst du dir den holen?

Da man ja eh immer wieder wechselt, eigentlich alle 😉

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

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

S
683 Beiträge seit 2006
vor 15 Jahren

ja aber ich mein bei welcher du einsteigen willst... 😉

Eine Null kann ein bestehendes Problem verzehnfachen

4.207 Beiträge seit 2003
vor 15 Jahren

Rot.

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

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

S
8.746 Beiträge seit 2005
vor 15 Jahren

Ich sehe das grösste Problem darin, dass es den Managern / Leitern mehr ums Geld geht und das weitsichtige Denken fehlt.

Wenn es wirklich so ist, dass gutes Design, Unittests, agile Methoden wirklich Geld sparen, dann wäre es doch wunderbar wenn die Manager so hinter dem Geld her sind. Dann wäre all diese Verfahren quasi von oben verordnet.

Meiner Erfahrung nach besteht das Problem nicht in Gier sondern in mangelndem Wissen. Mal Hand hoch: Wer kennt Methoden zur Aufwandsschätzung von Softwareentwicklung? Fragt das mal eure Manager die von euch Aufwandsschätzungen haben wollen (oder analog: "Was kostet es?"). Gebt mal als Antwort: Mit welcher Methode soll ich schätzen und mit welcher Wahrscheinlichkeit soll das Ergebnis behaftet sein?

Da gucken die wie ein U-Boot. Vergessen das aber schnell und sind dann ganz schnell dabei deine genannte Zahl (X Wochen...) in ihr MS-Project einzubauen und dann mit den Tapeten zur Geschäftsleitung oder zum Kunden zu rennen und Release-Termine zu vereinbaren.

Fairerweise muss man sagen: Die SW-Entwickler sind oft nicht schlauer, aber sie spüren den Leidensdruck direkter. Du findest unter SW-Entwickler genau die gleichen Plan-Hörigen/-losen oder wie unter den Managern.

Von letzteren aber sind m.E. nach 80% einer der beiden folgenden Gruppen zuzuordnen:

  1. Läßt seine Truppe alleine laufen. Wenn es schlecht läuft wird gebrüllt und Druck gemacht. Keine Methoden, dafür viele Überstunden und Wochenendarbeit.

  2. Versucht seine Truppe mit Kostenzahlen und Terminen zu kontrollieren. Das gelingt u.U., die Software ist aber genauso mies, weil man mit BWL-Methoden eben SW nicht besser machen kann. Häufig in Großunternehmen anzutreffen, kombiniert mit monatelangem Anforderungsermittlungsprozess, Quality-Gates, und Freigaben in dreifacher Ausfertigung. Die Projekte scheitern hier auch, kosten dann aber mindestens 30 Millionen und sind wenigstens dokumentiert gescheitert.

Die letzten 20% sind die "Guten", zumindest teilweise.

1.200 Beiträge seit 2007
vor 15 Jahren

Meiner Erfahrung nach besteht das Problem nicht in Gier sondern in mangelndem Wissen. Mal Hand hoch: Wer kennt Methoden zur Aufwandsschätzung von Softwareentwicklung? Fragt das mal eure Manager die von euch Aufwandsschätzungen haben wollen (oder analog: "Was kostet es?"). Gebt mal als Antwort: Mit welcher Methode soll ich schätzen und mit welcher Wahrscheinlichkeit soll das Ergebnis behaftet sein?

Jetzt mal ohne Scheiss: Ich schätz das fast 100% akkurat. Zumindest in dem 2 Mann Team, in dem ich seit einer Weile bin.

EDIT: Muss noch dazu sagen: Ich plan aber auch in Tagen. Da ist das natürlich keine Kunst.

Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

YARRRRRR!

84 Beiträge seit 2007
vor 15 Jahren

Ich stelle es gerade selbst fest: Zu zweit (Peter Bucher und ich) arbeiten wir derzeit an einem eher kleinen Projekt, wo wir beide seit etlichen Wochen jeden Tag mehrere Stunden dransitzen.

Unser Ziel ist - abgesehen davon - dass nachher alles funktioniert, auch, eine saubere Architektur hinzubekommen, eine gute Testabdeckung zu haben, ... und das kostet unglaublich viel Zeit!

Wenn man guckt, was das Ding für den Endanwender kann, fragt man sich, wie wir da länger als einen oder zwei Tage dransitzen.

Same here..

Ich finde zudem, dass die immer mehr werdenden Möglichkeiten zur Entwicklung eines Produkts den Aufbau einer Architektur nicht zwangsläufig vereinfachen oder beschleunigen, teilweise ist das genaue Gegenteil der Fall.

Einige konkrete Beispiele:

Datenzugriff:

  • Entity Framework?
  • LINQ to SQL ?
  • ADO .Net 2.0 ?
  • ADO .Net 1.0?
  • NHibernate ?

User Interface:

  • WindowsForms?
  • WPF?
  • WebFrontend?

Design:

  • n-Tier (3 Layer? 4 Layer? 5 Layer?)
  • FatClient? SmartClient? ThinClient?
  • Applikationsserver?
  • Nur SQL Server?
  • Stored Procedures?
  • DTOs oder DB-Entitys?

Umfeld:

  • Net 3.5/3.0/2.0 möglich?
  • MS-Only Datenbanken?

Ja, was den nun?
Man könnte das noch weiterführen.

Dazu kommt, dass man oft keine der Technologien als "best practice" bezeichnen könnte:

  • Mit dem EF und L2S kann man tolle LINQ Abfragen basteln - aber mehrschichtige Anwendungen sind beim aktuellen Stand nur unschön zu lösen..

  • Mit ADO .Net 2.0 kann man Datensätze durch alle Schichten schieben - aber bei Abfragen darf man erstmal wieder "SELECT * FROM Customers WHERE ..." in seine Settings-Datei tippen.

  • Mit NHibernate darf man aber erstmal zig Attribute und Config Einträge ohne Designer manipulieren..

Eine kleine Anwendung zur Verwaltung von Kundendaten ist schnell geschrieben.
Aber hat man sich erstmal einge der Patterns angesehen, _vervielfacht _sich der Zeitaufwand gut und gerne:
z.B. Design mit Layern und MVP-Pattern:
DataAccess -> Manager -> Services -> Presenter -> UserInterfaces

Hinzu kommt noch die Abstraktion durch Interfaces und/oder DataContracts zwsichen den einzelnen Schichten, die die erforderliche Menge an Code und Planungszeit stark ansteigen lässt.

Ich denke deshalb, dass auch in der Software-Entwicklung der Grundsatz gilt, dass auf 20% der Funktionaliät 80% der Arbeit entfallen. Übertragen auf die Architektur könnte man also vielleicht die These aufstellen, dass eine saubere, auf Patterns bzw. Vermeidung von AntiPattern basierte Architektur mit einem Schluck Pragmatismus die produktivste Art der Entwicklung darstellt.

Gruß,
Razer

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo zusammen,

lasst mal die fachlichen Details/Diskussionen hier in Smalltalk raus. Das wäre was für Rund um die Programmierung. Konzentriert euch auf die die Situation und die menschlichen Aspekte.

herbivore

M
303 Beiträge seit 2006
vor 15 Jahren

Hallo,

ich persönlich denke, das Problem wird von einigen etwas naiv betrachtet, vermutlich von denen, die noch nicht an wirklich großen Projekten gearbeitet haben. Die Behauptungen "lange Planung = saubere Architektur", "geldgeile Manager = schlechter Code" die so gerne geäußert werden, sind unüberlegt.

Ich spreche im Folgenden von Projekten, die eine Codegröße von 500.000 Zeilen aufwärts aufweisen. Hier haben wir meiner Erfahrung nach folgende Situation:

Erstmal ein paar Annahmen, die ich für das Folgebeispiel voraussetzen möchte und die vermutlich auch auf viele Projekte zutreffen:

  1. Das Projekt wird über viele Jahre hinweg entwickelt. Es gab schon mehrere Major- und Minorversionen, das Produkt ist im Einsatz.

  2. Bei einer solchen Projektgröße und Entwicklungsdauer kann man meistens auch davon ausgehen, dass viele verschiedene Entwickler daran gearbeitet haben, und bestimmt nicht immer das zu Projektbeginn aufgestellte Team. Entwickler kamen hinzu, Entwickler gingen. Der eine ist vielleicht ein erfahrener Informatiker gewesen, der andere kommt gerade von der Uni, wieder ein anderer hat gerade eine Ausbildung beendet, hat somit wenig Erfahrung, ist aber dafür recht ambitioniert.

Beginnen wir zeitlich bei 0:
Zu Projektbeginn gab es irgendwann mal eine Menge von Anforderungen, die vom resultierenden Produkt erfüllt werden sollen. Nehmen wir an, das anfängliche Team hat sich lange für die Planung zeitgelassen: Die Anforderungen analysiert, Zusammenhänge entschlackt und abstrahiert, und sämtliche Geschäftsfälle totmodelliert. Das Resultat ist eine saubere Klassenstruktur, die von nun an gepflegt wird.

Gehen wir nun 4 Jahre in die Zukunft. Das Produkt ist bei 200 Firmenkunden im Einsatz. Die Codegröße liegt inzwischen bei 230.000 Zeilen. Genug Platz für Bugs. Diese werden über ein Bugreporting-System eingespeist. Die Kunden möchten Fehler schnell behoben sehen, es herrscht also Zeitdruck.
Neu eingestellte Entwickler schlagen sich nun durch die 230.000 Zeilen Code, um die aktuellen 50 bekannten Bugs zu entfernen.
Leider erkennen sie nicht alle Feinheiten der vom ursprünglichen Team beabsichtigten Architektur. So beginnen sie, gegen Kapselungsvorgaben zu verstoßen. Klasse A braucht plötzlich zwei Setter mehr, die von Klasse B beschrieben werden sollen. Sollte laut dem ursprünglichen Entwicklermodell nie passieren, aber der eine, unglaublich nervige Bug konnte durch die neuen Setter ruckzuck behoben werden. Super, wieder ein zufriedener Firmenkunde!
Doch nicht nur Bugs werden gemeldet, auch Neuanforderungen. Neuanforderungen, die vom damaligen Entwicklerteam, welches die Grundarchitektur entworfen hatte, niemals vorausgesehen werden konnten. Also muss die Architektur umgebogen werden, damit neue Anforderungen zeitnahe implementiert werden können. Und selbst wenn viel Zeit vorhanden ist, ist es äußerst schwer eine Architektur zu verändern, auf der bereits so viele laufende Geschäftsprozesse innerhalb der Software aufbauen.

Spulen wir weitere 3 Jahre vor: Die Umbiegung und Veränderung der Architektur führt dazu, dass sich bereits sogenannte "Workarounds" für Inkonsistenzen im eigenen Projekt gebildet haben. Das Projekt fast inzwischen 700.000 Zeilen, und durch die immer wieder kehrende Einprogrammierung neuer Asssoziationen zwischen Klassen (Neue Parameter im Konstruktor, Getter / Setter, etc.) sind die Klassen untereinander ziemlich fest verzahnt, was es schwer macht, unsauber implementierte Teile der Architektur neuzuschreiben, da man damit wieder viele Löcher in anderen Codeteilen aufreist.

Jetzt nach 7 Jahren kommt ein ambitionierter Programmierer hinzu der sagt: Schlechte Architektur. Wer plant denn bitte so ein Blödsinn! Hätte man ja alles gleich besser machen können.
Und die Geschichte geht von Neuem los, nämlich bei 0, fest definierten Anforderungen und einer großen Portion Enthusiasmus.

Gehen wir nun 4 Jahre in die Zukunft...

458 Beiträge seit 2007
vor 15 Jahren

marco.b: Bessere Beschreibung hab ich nie gelesen.

be the hammer, not the nail!

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo marco.b,

das beschreibt nur das Problem, verschweigt aber, dass es dafür Lösungen gibt (auf die ich im Detail nicht eingehen will, weil wir hier in Smalltalk sind, deshalb nur ein kleines Stichwort: Refactoring). Und Lösungen geben muss, weil es sonst eben nach x Jahren zwangsläufig auf eine unwartbare Anwendung hinausläuft. 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).

Das Teams wechseln ist sicher eine Herausforderung. Wobei der Wechsel natürlich auch mit der Unzufriedenheit über die von dir beschriebenen Situation zusammenhängen kann. 😃 Sozusagen ein Teufelskreis.

herbivore

M
303 Beiträge seit 2006
vor 15 Jahren

Hi herbivore,

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.
Dies habe ich in einigen Firmen bei einigen größeren Projekten beobachtet. Ein Gegenbeispiel, sprich ein kerngesundes Großprojekt, ist mir noch nicht untergekommen. Für jedes Beispiel bin ich aber sehr dankbar.

Bevor ein Beispiel aufgezählt wird, bitte beachten: Ich spreche von Projekten in der freien Wirtschaft, da diese in den allermeisten Fällen durch ständig neue Anforderungen recht unvorhersehbar wachsen, da man die genauen Anforderungen der Geschäftsprozesse zukünftiger Kunden nicht kennt. Das mag auf eine Treibersoftware oder eine wissenschaftl. Simulationssoftware nicht zutreffen.

Ich glaube nicht dass es pauschal immer technische Lösungen gibt, die helfen. Insbesondere hinter deinem Stichwort sehe ich keine wirkliche Lösung, da die Komplexität nicht vermindert wird, sondern nur die eigentliche, textliche Veränderung erleichtert wird. Die Analyse der Folgen einer solchen Veränderung wird damit nicht vereinfacht.