Softwareentwicklung als Fließbandarbeit - war Re: Wasserzeichen statt DRM?

[Florian Haas]

Matthias-Christian Ott wrote:
> Florian Haas <mail at florianhaas.net> wrote:
>   
>> 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.
>   
Lass es mich so formulieren: Beamtenmentalität gibt es nicht nur beim Staat.
Die Monotonen gibt es, aber in meinen Augen bilden sie (noch?) nicht die
große Mehrheit. Insbesondere bei projektgetriebenen Firmen gibt es immer
was Neues.

Was das denglisch angeht: Wir müssen a) Buzzword-compliant sein und b)
den Code mit den Kollegen aus Bratislawa und London teilen. Da kommt es
zwangsläufig zu neuen, firmeninternen Dialekten der englischen Sprache ;-)
>   
>>> 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.
>   
Da habe ich wenig Ahnung von; das Konzept des Pair-programming fand ich
zu abschreckend um mich näher damit zu befassen.
>   
>> 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.
>   
Ja, man muss miteinander sprechen. Bei großen Entwicklungsteams weiß
aber nach 'nem Meeting keiner mehr genau, was genau besprochen wurde. In
Kombination mit Kunden die nicht genau wissen was sie eigentlich wollen
bedeutet das manchmal dass man am Ende zwar etwas Entwickelt hat, der
Kunde aber nciht zahlen will weil er etwas komplett anderes wollte. Wen
man dann eine 100%ige Definition dessen was man abliefern sollte in der
Hand hat und genau sagen kann "Dies hast du in Auftrag gegeben; dein
komisches Feature Z war von vornherein nicht geplant" bleibt man nicht
auf Millionenkosten sitzen.
>   
>>> 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.
>
>   
;-)
>> 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.
>   
Berater im Sinne von "Einsparungen, Leute feuern, internes produkt X
verkaufen" ist doof, ja. Berater im Sinne von "Ich habe Erfahrung und
kann Euch sagen was eine sinnvolle Architektur ist" oder "Ich kenne die
Freie Software Szene und kann euch sagen wie Ihr euer Produkt am besten
unter die GPL stellt" ist mein Ziel.
Wir dürfen nicht vergessen dass das, was uns selbstverständlich
erscheint, für die meißten richtig großen Firmen schwarze Magie ist.

Beispiel hierfür: Asus mit dem EEE-PC. Die Sourcen sind in einem 1,8 GB
großem Tarball; es gibt kein Code-repository, keine Mailingliste und
kein Forum.
Gäbe es das Alles (kombiniert mit Asus-Entwicklern die auch öffentlich
aktiv sind) würde es garantiert eine große Community geben die das Beste
aus dem EEE rausholen. In der jetzigen Form bilden sich hier und da
kleine Grüppchen, die alle das Rad neu erfinden werden.
> 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.
>   
Keine Frage. Aber große Firmen wollen nicht experimentieren. Leider.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 250 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20071203/304c5d1d/attachment.sig>