Florian Haas mail@florianhaas.net wrote:
Matthias-Christian Ott wrote:
Es geht darum wie einige Firmen ihre Programmierer dazu nötigen, Softwareentwicklung zu einer Art industrieller Produktion zu machen. Meistens kommen dabei Technologien wie Java, .NET, UML, ... zum Einsatz. Dabei gehts dann einfach darum Programme im folgenden Schema zu erstellen:
Datenbank (Oracle, MSSQL, ...) <-> "Berechnungen" <-> Oberfläche (Win32, Java, HTML,..)
Die Kunden geben dann das Schema der Datenbank vor und die Programmierer dürfen dann die Oberfläche und die "Berechnungen" (interne Programmstruktur) den Daten anpassen, wobei Generatoren die Grundstruktur festlegen und der Programmierer nur in bestimmten Bereichen eingreift.
Immer wieder das gleiche, keine/wenige Release-Zyklen, alle paar Jahre neu. Monotone Arbeit wie in einer Fabrik im 19. Jh., halt immer wieder das gleiche.
Du verwechselst planvolles Vorgehen mit repetitiven Tätigkeiten. Die Ziele der konservativen Firmen die ein rigides Planungskonstrukt in ihrer Entwicklung verwenden sind vielfältig. Sie wollen ein klar definiertes Ergebniss (Feature X, Y und Z) zu einem klar definiertem Budget zu einem klar definiertem Zeitpunkt. Um dem gerecht zu werden brauch man einen klaren Plan mit klaren Abschätzungen (sowohl was Zeitaufwand betrifft als auch was das Ergebniss betrifft). Die Folge davon sind zum einen die ans Micromanagement grenzenden Projektpakete, zum anderen das Zurückgreifen auf bewährte Konstrukte (wie zB die von Dir beobachtete Architektur).
Nur weil die meisten Applikationen diser Struktur folgen heißt noch lange nicht dass die alle gleich zu programmieren sind; jede Software ist einzigartig. Monoton ist die Arbeit auf alle Fälle nicht.
Ich hatte gegenteiligen Eindruck, aber was soll man von Leuten erwarten die ihre Klassennamen schon denglisch machen. Trotzdem folgen die Programme immer dem selben Schema. Das ist sicher nicht überall so, aber ich glaube in der Mehrheit doch richtig.
Ich habe vor ein paar Monaten einen Vortrag von b+m über Model-Driven Architecture und ähnliches gesehen, in dem so ein typischer Arbeitsprozess vorgestellt wird. Ich bin froh, dass ich so etwas nicht beruflich machen muss.
Vielleicht sehe ich das auch falsch, aber für mich scheint das so. Ich muss dabei bemerken, dass ich davon nicht viel verstehe und nicht verstehen will. Wenn ich das falsch sehe, bitte ich euch mich zu korrigieren.
Wenn ich programmiere, ist das eher künstlerischer Natur. Das ist nicht so eingeengt, viel freier, denn ich probiere vieles aus und bin offen, habe nicht so stritke Abläufe und konzentriere mich auf wichtige Aspekte.
Du hast als Entwickler weniger Freiheiten, das ist klar. Das Entwicklungskonzept schließt komplett aus das ungeplante Veränderungen/Verbesserungen entstehen. Das bedeutet zwangsläufig dass die dadurch entwickelten Produkte immer nur auf den Markt reagieren können statt ihn entscheident zu verändern (Außnahmen bilden Unternehmen die einen visionären Entwicklungsmanager haben). Klassischer Fall von Cathedral vs. Bazaar.
Hmm, ich habe letztens einen Podcast über Extreme Programming gehört und fand das nicht so statisch, aber trotzdem sehr geplant.
Der eindeutige Vorteil ist allerdings dass der Auftraggeber genau weiß was ihn erwartet. Bei dem Bazaar-Modell kann man nicht genau sagen in welche Richtung die Fahrt geht; das ist der Todesstoß für ein Unternehmen wenn der Vertrieb Feature X im Quartal Y versprochen hat.
Nun ja, man muss auch miteinander sprechen, dann gibt es auch keine bösen Überraschungen.
Ich bin das ist eher mein Hobby und nicht mein Beruf.
Der Satz war aber toller Satz - ich bin immer wieder von meinem Deutsch begeistert.
Tagsüber bin ich konservativer Entwickler, aber Nachts übernimmt meine zweite Identität als Bazaar-Coder ;-)
;)
Ich habe versucht mein Hobby zum Beruf zu machen. Beruf kommt für mich von Berufung; ich muss Spaß an meiner Arbeit haben um glücklich zu sein.
Wer will das nicht? Finde ich auch eine gute Einstellung.
Für mich bedeutet das: die nächsten 5 Jahre noch als konservativer Entwickler zu arbeiten; danach nur noch beratend (und bei der Software-Architektur) tätig zu sein. Das Bazaar-Modell macht weitaus mehr Spaß, ist aber definitiv nicht das Richtige für jede Firma.
Berater macht doch keinen Spaß. Finde ich auch jedenfall.
Großprojekte wie GNOME stetzen ja auf eine Hybridmethode: Quartalsweise (oder ist das bei GNOME ein halbes Jahr) Veröffentlichungen. Da ist dann beides drin.
Selbst bei diesen Firmenmethoden gibt es deutlich effektivere, als die vorgestellten.
Mit freundlichen Grüßen Matthias-Christian