Laden...

Lesenswerter Artikel: Hype Driven Development

Erstellt von LaTino vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.986 Views
LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 6 Jahren
Lesenswerter Artikel: Hype Driven Development

Lesenswerter Artikel.

Hype Driven Development

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo LaTino,

stimmt 😃

Dass der Artikel lesenswert ist und dass wirklich vieles nur weils Hype ist eingesetzt wird ohne zu reflektieren ob es passt und für die Problemdomäne anwendbar ist.

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!"

5.657 Beiträge seit 2006
vor 6 Jahren

Hi LaTino,

bin auch gerade bei Fefe über den Artikel gestolpert und fand ihn auch sehr lesens- und empfehlenswert.

Weeks of programming can save you hours of planning

B
66 Beiträge seit 2013
vor 6 Jahren

@LaTimo:
Da Du scheinbar ein bisschen mehr verstehst und weil Du mir im Thread unten zur "Agilen Methode" vorwirfst, meine Ausführungen wäre nicht funktional genug (,denn das ist so, als würde ich einer Katholischen Kirche schreien "Religion ist Bulshit" und auf em Altar wissenschaftliche Experimente ausbreiten, um die Gemeinde zu überzeugen) und wäre sehr selbstbewusst - aka "hätte starke Meinung" : Wie gehst Du mit den nachfolgenden Problemen um:

  1. Wie Du die Anaomlien, Inkosistenzen und Probleme während der Zunahme des HDD erkennst?

  2. Wie überzeugst Du
    a) eure Kunden
    b) deine Kollegen
    c) dem Management
    d) den Zuliefern
    dem Hype nicht nachzulaufen, sondern teuere, langfristigen, nachhaltigeren und verpflichtigen Lösungen zu erstellen, u die große Krise zu vermeiden wenn die Blase platzt?

  3. Wie findest Du die wirklichen coolen, innovativen Entwicklungen, erstellt von den kreativsten Köpfen der Welt (den besten?!?) und erhälst Zugang? - Aka finding the underground and get in! - Denn diese sind die Letzten, die sich in der Öffenlichkeit stark produzieren, um sie zu finden.

HDD ist und war immer ein Run in das Mittelmaß!
S.u.a. Agiles M & D.

LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 6 Jahren

(LaTino mit n, da bin ich empfindlich)

Der Vorwurf war nicht, dass du starke Meinungen vertrittst - das tue ich selbst gern und schätze es auch bei anderen - sondern, dass einige Folientexte mit Argumenten verwechselst und es nicht für nötig hältst, deine Aussagen zu untermauern. Das ist schade, weil, wie ich schon schrieb, deine Meinung durchaus kein Einzelfall ist, sondern in meiner täglichen Arbeit bei Projektverantwortlichen und im Management sogar relativ oft anzutreffen ist.

Ein für meine Begriffe sehr gutes Argument wäre ein Verweis darauf gewesen, dass man mit dem Einsatz agiler Methoden u.U. Gefahr läuft das zu tun, was im Link oben "hype driven development" genannt wird. Und die Risiken von "HDD" sind dort (Link) ja recht anschaulich dargestellt.

Wie gehst Du mit den nachfolgenden Problemen um:

  1. Wie Du die Anaomlien, Inkosistenzen und Probleme während der Zunahme des HDD erkennst?

Zugegeben habe ich hier etwas Schwierigkeiten, zu erkennen, was du wissen möchtest. "Zunahme des HDD"? Inwiefern? Was der Autor spöttisch "HDD" nennt, also das Hinterherlaufen hinter Trends, wie soll das "zunehmen"? Entweder man verfällt dem Trend, oder nicht, das ist ein binärer Zustand. (Immer gesehen für ein Projekt.) Wenn man dem Trend verfällt, besteht das Risiko, dass man hinterher das Gegenteil von dem erreicht, was man wollte (dass es teurer wird, länger dauert, unzuverlässiger funktioniert). Wenn man dem Trend nicht verfällt, sondern auf bewährte Methoden zurückgreift, besteht das Risiko, dass man von den Vorteilen des Trends ggf. nicht profitiert, d.h. man vergibt sich die Chance, dass es funktioniert.

Wichtig auch: unter bewährte Methoden wird eine Softwarebutze, die seit Jahren SCRUM macht, eben auch SCRUM verstehen. Bewährt heisst: ich weiß, dass es für mich funktioniert, ich kenne die Vor- und Nachteile, und ich kann beides in meine Kalkulation einbeziehen und stelle im Projektnachlauf fest, dass diese Kalkulation nah an der Realität war. Insofern unterstützt der Link keinesfalls deine These, dass agile Methoden per sé ein "Run in das Mittelmaß" (was soll das eigentlich bedeuten?) sind.

Wie überzeugst Du
a) eure Kunden

Easy. Meine Kunden gehören - wenigstens die Entscheider - zu Unternehmen, wo die IT noch "EDV" und "DFÜ" genannt wird. Die wissen, dass COBOL das Maß der Dinge ist, weil sie Software im Einsatz haben, die damit Anfang der 70er geschrieben wurde und immer noch funktioniert. Überspitzt gesagt: wenn ich die überzeugen will, dass ihr Produkt mit einer gewissen Technologie/Methodik entwickelt werden soll, dann muss ich ihnen ein Beispielprojekt zeigen, dass mindestens schon 30 Jahre läuft. Alles andere wird für kurzfristige Trends gehalten. Ich kenne Entscheider, die halten OOP für einen dieser kurzfristigen Trends.

b) deine Kollegen

Der schwierigste Part. Gute Entwickler sind faul. Wenn sie das Risiko sehen, dass sie mit einer Methode mehr Aufwand haben als mit der anderen, wählen sie im Normalfall das, was sie kennen. Wenn allerdings, um ein fiktives Beispiel zu nennen, 5 Kollegen von einer Konferenz kommen und jetzt alle künftigen Projekte in Rust machen wollen (nix gegen Rust, ich liebe die Sprache), dann lässt man sie Rust evaluieren. Zum einen dauert das lange genug, um die nachkonferenzliche Euphorie verfliegen zu lassen, zum anderen kommt dabei auch noch was Sinnvolles raus. Weiß man dann, welche Probleme man mit Rust lösen kann, kommen ein paar interne Projekte auf der grünen Wiese. Wenn die funktionieren, wird geschult und wenn dann ein Teilbereich eines Projekts aus den bestehenden Erfahrungen heraus am besten mit Rust umgesetzt wird, hat man das Know-How, die Leute und die Erfahrung, um auch Fehlschläge managen zu können.

c) dem Management

Wenn mein Management sieht, dass ich ich nicht abwehre nach dem Prinzip "kenn ich nicht, fress ich nicht", sondern dass ich mir auch Gedanken betriebswirtschaftlicher Natur gemacht habe - Risikoanalyse zB - dann haben sie alles, was sie für eine Entscheidung benötigen. Stell ich mich hin und sage "auf der einen Folie im Internet stand "Only way out [..of agile project (dis)management] is rigorous Release Management, but more then [sic!] ITIL V3.", deshalb sollten wir das nicht machen" dann habe ich a) den falschen Job und wenn das Management dann auch noch auf mich hört, haben b) die auch den falschen Job.

d) den Zuliefern

Zulieferer in dem Sinn haben wir nicht, wir stellen Software her, keine Autos. Teilweise hängen wir von Anbietern anderer Lösungen ab in dem Sinn, dass unsere Software mit deren kommunizieren muss. Ein aktuelles Projekt kommt mir dabei in den Sinn, wo unsere Software Daten verarbeiten und integrieren muss, die eine Reihe von Services eines Drittanbieters zur Verfügung stellt. Besagter Anbieter arbeitet agil, bzw glaubt das. Tatsächlich arbeitet er (aus meiner Sicht) einfach nur unorganisiert. Das führt dazu, dass wir als Konsumenten seiner Services so arbeiten: drei Wochen warten - neue Schnittstelle/neues Feature geht jetzt! - 3 Tage Arbeit - schade, die notwendige Schnittstelle xy tut noch nicht - drei Wochen warten und von vorn. Das ist frustrierend, bringt unseren Zeitplan und schlimmer noch den unseres Kunden durcheinander. Ich halte unseren Hintern aus Schwierigkeiten heraus, in dem ich immer klar kommuniziere, dass es hakt, wo es hakt, und wessen Zuständigkeit das ist. Zudem haben Kunde und ich eine Exit-Strategie ausgearbeitet, als sich langsam herauskristallisierte, wie das läuft. Ich werden den "Zulieferer" nicht überzeugen können, die Finger von Methode xy zu lassen, aber ich kann das Risiko erkennen und managen.

  1. Wie findest Du die wirklichen coolen, innovativen Entwicklungen, erstellt von den kreativsten Köpfen der Welt (den besten?!?) und erhälst Zugang? - Aka finding the underground and get in! - Denn diese sind die Letzten, die sich in der Öffenlichkeit stark produzieren, um sie zu finden. Das ist zwar eine sehr romantische Vorstellung - die des braven, bescheidenen Hackers, der im Hinterhof in der Garage von Mutti the next hot thing strickt und kein Interesse hat, groß per PR auf sich aufmerksam zu machen - aber keine sehr realistische.

Beobachte den Markt (Technologien UND die Konkurrenz). Ruh dich nicht aus. Probiere Dinge. Gib deinen Mitarbeitern die Chance, an etwas zu scheitern und alle davon lernen zu lassen, ohne sie dabei zu demotivieren. Widerstehe der Versuchung, etwas Funktionierendes in einer anderen Technologie von Grund auf neu zu entwickeln. Trau keiner Powerpoint-Folie. Hör auf deinen Justiziar.

Das wären so meine Tipps aus 25 Jahren Softwareentwicklung und PM.

HDD ist und war immer ein Run in das Mittelmaß!
S.u.a. Agiles M & D.

Da habe ich auch noch ein passendes Zitat.

Only a Sith deals in absolutes.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
2.219 Beiträge seit 2008
vor 6 Jahren

@MrSparkle
Hatte ich auch über FeFe gefunden 😃

@Blaster
Ich habe das Gefühl, du hast dich auf LaTino seit dem letzten Thema eingeschossen.
Bitte kläre deine Differenzen nicht öffentlich sondern per PM mit ihm direkt.

@LaTino
Auch wenn dies nicht zum eigentlichen Thema passt, gebe ich dir mit deinen Antworten soweit recht.
Aber auch hier hoffe ich, dass du mit Blaster das Thema weiter per PM klärst.

Für den Link bin ich trotzdem dankbar, da es gerade in Zeiten von aufpoppenden Frameworks für JS und co. doch eine Grundlage ist, sich mal Gedanken um diese Hypes zu machen 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 6 Jahren

@MrSparkle
Hatte ich auch über FeFe gefunden 😃

Ich auch 😉.

Wieso hast du das Gefühl, wir würden Differenzen klären? Ist 'ne normale Diskussion, und die gehört mMn ins Forum. Es darf sich gern beteiligt werden. Sollten wir auf das Niveau "deine Mudder!" sinken, dann per PM, versprochen.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
2.219 Beiträge seit 2008
vor 6 Jahren

@LaTino
Weil die Themen hier vermischt werden.
Auch hat Blaster sonst keinen Grud, da du bis zu seinem Post nur den Link gepostet hattest, das Thema mit den Agilen Methoden hier wieder reinzuschieben.
Entsprechend sieht dies für mich so aus als ob du nun das Ziel seiner "Agile Methode sind Mist" Aussagen bist.
Da du auch mit entsprechenden Argumenten "austeilst", sieht dies für mich nach einem Kleinkrieg aus.
Entsprechend wollte ich das Thema hier nicht weiter breit treten lassen.
Es mag schon sein, dass diese Diskusion offen geführt werden kann, aber wäre dann der Thread mit den Agilen Methoden nicht der bessere Bereicht?

Wie gesagt, sehe ich diesen Thread eher als einen Denkanstoß um nicht jedem Hype in der Entwicklung zu folgen.
Wenn es aber um Agile Entwicklung geht, kann man dies auch in dem entsprechenden Thread posten.

Das Forum ist für mich wie Entwicklung nach dem Schichten Modell.
Man sollte die Themen getrennt halten 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.