Abo
  1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Entwickler-Charaktere: Ninja oder…

Unglaubwürdiges Modell

  1. Thema

Neues Thema Ansicht wechseln


  1. Unglaubwürdiges Modell

    Autor: Marconry 28.08.18 - 23:08

    Dass das Design-Types-Modell ernst zu nehmen ist glaube ich erst, wenn es von Experten bestätigt wurde. Bis dahin ein bisschen Kritik vom Laien. ;)

    Wie der Artikel schon sagt sind die Typen nicht gleichverteilt. Man kann sagen "der Entwickler war nur nicht ehrlich mit sich selbst" oder das Modell hinterfragen. Und manche Typen ergeben keinen Sinn.

    Etwa der Uhrmacher: Jemand der sich zwar in den Einzelteilen seines Projekts extrem gut auskennt, aber dennoch das Gesamtbild nicht sieht?
    In einer Einarbeitungsphase kann ich mir das gut vorstellen: Man fängt irgendwo im Projekt an und tastet sich vorwärts. Man kennt fast alle Teile gut, und dann macht es "klick". Aber als Dauerzustand, als Charaktertyp, wie kann so jemand als Entwickler überhaupt zurechtkommen? Unglaubwürdig.
    Und natürlich will das niemand sein. Dass die Rollen "wertfrei" oder "gleichwertig" sind kann man nicht behaupten.

    Mit den vier Dimensionen des Modells bin ich auch nicht einverstanden.

    Mit "pragmatisch vs idealistisch" zum Beispiel überhaupt nicht. Mal überspitzt: Pragmatisch sind laut Modell die Entwickler, die "schnell schnell" irgendwas hinrotzen. Hauptsache es "funktioniert". "Idealistisch" dagegen die, die erst mal gründlich durchplanen, bevor überhaupt eine Zeile getippt wird. Das Wasserfallmodell kommt unweigerlich in den Sinn.
    Aber ist der feste Glaube an "schnelle Time to Market über alles" nicht ebenso idealistisch? Ist es nicht pragmatisch, heute ein paar Zeilen Code in eine Funktion auszulagern, damit morgen das Projekt mit den (unweigerlich hinzukommenden) neuen Anforderungen wachsen kann?
    Doch, denn die Dimension hat gar nichts mit Pragmatismus und Idealismus zu tun! Stattdessen mit der Frage, wann der beste Zeitpunkt ist in interne Codequalität zu investieren. Entweder früh und kontinuierlich, sodass man zu jeder Zeit brauchbaren Code hat. Oder spät und geballt, der Spaghetticode hat sich unbeherrschbar hoch aufgetürmt, jetzt ist man im Zugzwang.

    Der Dimension liegt das verbreitete Missverständnis zugrunde, dass man auf interne Codequalität verzichten könnte. Dass sie, frei nach dem Buch "Peopleware", wie Schokosoße auf Vanilleeis reine Geschmackssache ist: Der eine mag mehr, der andere weniger. Ist aber nicht so, Peopleware belegt das gut. Codequalität bezahlt man immer - im schlimmsten Fall kostet es das Projekt.

    Mit den anderen Dichotomien bin ich soweit d'accord.
    Für "einfach vs mächtig" sehe ich als typisches Beispiel, dass manche Entwickler lieber gezielte Anwendungen bauen, andere lieber Libraries und Frameworks. "Abstrakt vs konkret" verstehe ich so, dass die einen Top-Down, die anderen Bottom-Up arbeiten. Keine Einwände bis hier.
    Aaaaber: Wohldefiniert ist die Skala dagegen nicht. Was bedeutet ein Wert irgendwo in der Mitte einer Dimension? Mittig von "einfach vs mächtig", baut man da am liebsten "kleine Libraries" oder hat man schlicht keine Präferenz? Wenn man "ein bisschen abstrakt" ist, arbeitet man dann Inside-Out, oder kommt man mit allem zurecht, oder vielleicht mit nichts? Alles davon kann prinzipiell vorkommen, aber nur eins abgebildet werden. Welches ist nicht klar.

    Und eine wichtige Eigenschaft von Entwicklern taucht im Modell überhaupt nicht auf: Flexibilität. Bin ich in meinem Denken festgefahren; auch, aber nicht nur im Rahmen der Dimensionen des Modells? Kann ich mein Ziel, meine Herangehensweise situativ anpassen? Beharre ich auf meinem Standpunkt oder kann ich kooperieren? Vielleicht ist das implizit in den Ausprägungen der Dimensionen enthalten, dann hat das Modell wiederum andere blinde Flecke.

    Und zum Schluss etwas "Meta": Die Kategorisierung in Entwicklertypen ist eine Einladung zum Schubladendenken. Man liegt in allen Dimensionen fast mittig, trotzdem: "Ich bin Magician" - "Ah, typisch pragmatisch produzierst du Code immer auf der Überholspur". Oder aus dem Artikel: "Leute, die zum robusten Typ zählen, also auf Stabilität aus (...) aber nicht offen für neue Technologien sind". Menschen sind vielschichtiger als das. Ein kleiner Fragebogen im Netz oder in der Bunten erfasst das nicht. Das sollte man immer im Hinterkopf behalten.

    Angesichts dessen, dass es ihr Modell zwei Jahre gibt und die Autoren bereits ein Entwickler-Mau-Mau darauf aufgebaut haben ist der Zug wohl abgefahren. Wo ich damit wohl auf "optimistisch vs pessimistisch" liege? ;P

  2. Re: Unglaubwürdiges Modell

    Autor: Trockenobst 31.08.18 - 10:29

    Marconry schrieb:
    --------------------------------------------------------------------------------
    > Etwa der Uhrmacher: Jemand der sich zwar in den Einzelteilen seines
    > Projekts extrem gut auskennt, aber dennoch das Gesamtbild nicht sieht?

    Ich bin mir sicher, dass ich jemanden bei Epic finde, der in der Unreal-Engine tief in den Details der NVidia GPU steckt. Also wirklich bis runter auf das Metall. Oder bei SAP in der Datenbankschicht. Oder bei Google in dem Detail von Adwords, dass dafür sorgt dass die Kohle von tausenden Kunden reinkommt.

    Nicht jeder ist Generalist noch dafür eingestellt. Wir haben einen Datenbank Guru, rate mal was der für 10 Projekte macht. Dem ist das egal was vorne im Frontend läuft.

    > Aber ist der feste Glaube an "schnelle Time to Market über alles" nicht
    > ebenso idealistisch? Ist es nicht pragmatisch, heute ein paar Zeilen Code
    > in eine Funktion auszulagern

    Wortklauberei. Wir haben Leute die fummeln ewig und drei Tage an Basics rum,
    weil der Kunde das Feature nicht vollständig beschrieben hat. Die einen wollen
    dass man mit den 70% im vorhandenen Framework schon sehr weit kommt, die
    anderen warten lieber und perfektionieren die Basis. Das passt schon so.

    > Codequalität bezahlt man immer - im schlimmsten Fall kostet es das
    > Projekt.

    Ich habe in einem Projekt gearbeitet, die sind auf dem Stand von .net 3.0.
    Also fünf Jahre alt. Dort wurde keine einzelne Zeile refaktoriert und das Ding bekommt
    neue Formulare und zwei drei Leute arbeiten daran. 2000 User arbeiten mit den 40 Funktionen, die am Ende macht das Tool im Industriellen Umfeld das was es soll.

    Die Vorstellung dass immer alles wehtut, dann würde es vieles nicht mehr geben und alles was bei Dreckstool.de rumkeucht. Die Wahrheit ist: viele User können es sich nicht aussuchen und häufig sind Entscheidungen politisch, nicht technisch. Dann "Lebt" man mit dem madigen Code.
    Nicht jeder schreibt und betreibt Satellitensteuerungssoftware.

    > Aaaaber: Wohldefiniert ist die Skala dagegen nicht. Was bedeutet ein Wert
    > irgendwo in der Mitte einer Dimension? Mittig von "einfach vs mächtig",

    Jeder Entwickler baut Abstraktionen. Das ist wohl damit gemeint.
    Der eine schreibt an der nächsten Basislibrary für Datenbankzugriff, findet das spannend.
    Der andere ist mit der kleinen Library die XML zu PDF generiert zufrieden.
    Ernsthaft hatte ich noch nie ein angebot irgendwelche "großen" Bibliotheken zu bauen, dass macht man wohl auch nur bei großen Firmen.

    > Flexiblität <...> dann hat das Modell wiederum andere blinde Flecke.

    Würde man das nicht schon bei der Jobwahl vorauswählen? Wenn ich etwa mit einem Framework ziemlich gut eingearbeitet bin und dann zu einem Projekt wechsle, dass alles anders macht?
    Ist dies nicht die Flexibilität? Wenn du 10 Jahre lang BWL Formulare für SAP entwickelst ist deine wahrscheinlich sehr niedrig ;)

    Innerhalb von Projekten ist die Wahrscheinlichkeit dass man alles über Bord wirft, und das ist meine Erfahrung in großen langlebigen Kerninfrastrukturprojekten, dass die Flexibilität des Entwicklers sich eher entlang der Dimension Basistechnik, Backend, fachliche Klassen, Frontend, Clients abspielt. Dort kommt dann noch die neue Dimesion Operations dazu, also wie wird das Produkt erzeugt und wie landet es auf den Servern/Clients/Kunden.

    > robusten Typ zählen, also auf Stabilität aus (...) aber nicht offen für
    > neue Technologien sind". Menschen sind vielschichtiger als das.

    Sehe ich nicht so. Ich sehe es eher nach dem Satz:
    "Kann 'der' schon machen, dann wird es eben nicht so toll".

    Menschen haben Präferenzen. Der Backendentwickler der kein Javascript kann, wird schon irgendwie übernehmen können, wenn der andere Typ gekündigt hat. Aber wird das "gut" werden? Wir es.....magisch? Entwickeln hat einen großen kreativen Anteil. Aber wenn dir der Platz am Kochtopf nicht gefällt, du kein Rezept hast und die Küche dir zu heiß ist, wird das was aus dem Topf kommt nicht schmecken. Aber Nahrung wird es sein ;)

    Wir haben unsere Spezialisten und ich habe gelernt dass man die Leute so nehmen muss.
    Also kein Javascript für den Backendguru, da freuen sich die Werkstudenten und Inder, wenn sie das mal übernehmen können. Deren "Witzigkeitserwartung" führt manchmal zu sehr interessanten Fragen und besseren lösungen. Genau das willst Du. Die Beschäftigung mit dem Usecase, mit der Technologie, mit dem "Meta". Das hat weniger mit Flexibilität zu tun, sondern mit dem Spass am Job UND der Thematik.

    > Wo ich damit wohl auf "optimistisch vs pessimistisch" liege? ;P

    Deine Kritik (auch des Verständnisses?) ist berechtigt, aber es wirkt als wenn dich diese Einsortierung auch ein wenig aufgewühlt hat.

    Viele der Charaktere erkenne ich als Grundtypen, einige sind eher in der Mischung vorhanden.
    Ich mag es selbst tief einzusteigen, aber gleichzeitig mag ich es wenn das Fließband immer schön sanft am rennen ist. Das sind zwei verschiedene Geschmäcker des Entwickelns die mir liegen.

    Dort wo ich aussteige, sind fummelig komplexe Schnittstellen. Das überlasse ich den anderen Charakeren die mehr Spass darin finden.

  3. Re: Unglaubwürdiges Modell

    Autor: Stopfpfropf 01.09.18 - 18:03

    > Mal überspitzt: Pragmatisch sind laut Modell die Entwickler, die "schnell schnell" irgendwas hinrotzen. Hauptsache es "funktioniert". "Idealistisch" dagegen die, die erst mal gründlich durchplanen, bevor überhaupt eine Zeile getippt wird.

    Vielleicht magst du die Dimension nicht, weil du zu idealistisch bist und "die andere Seite" nicht ernst nehmen kannst. Diese Aussage aus dem Quiz hätte ich gern mehrfach angeklickt:

    >> Sometimes it is necessary to omit certain time consuming tasks like unit tests, consistent exception handling or documentation.

    Hier würden die Java-Experten aus meinem letzten Projekt die Hände über dem Kopf zusammenschlagen: Code ohne Tests ist per Definition "legacy" und ohnehin buggy; Uncle Bob hat was getwittert, deswegen machen echte Ingenieure nur noch TDD. An Idealen hat es dem Team nicht gemangelt.

    Leider mussten wir keine schön testbaren Algorithmen entwickeln, sondern eine asynchrone GUI in einem Nischenframework. Also floss unglaublich viel Entwicklerzeit in die Test-Suite, die auch nach Jahren manchmal rot ist (einfach die CI neu anwerfen, die halbe Stunde ist's wert) – oder grün, obwohl gerade jemand grobe Bugs eingecheckt hat.

    Mein Vorschlag, einen manuellen Testplan auszuarbeiten, wurde belächelt, obwohl ich bei jedem manuellen Test neue Bugs gefunden habe. Entweder nach Lehrbuch, oder gar nicht. Jetzt wurde jede Deadline mehrfach gesprengt und das Team eingedampft. Aber immerhin hat niemand gepfuscht.

    Damit will ich nicht sagen, dass es in der IT keinen Platz für Idealisten gibt. Aber im GUI-Bereich halte ich mich von ihnen lieber fern.



    1 mal bearbeitet, zuletzt am 01.09.18 18:05 durch Stopfpfropf.

  4. Re: Unglaubwürdiges Modell

    Autor: rldml 05.09.18 - 11:16

    Marconry schrieb:
    --------------------------------------------------------------------------------
    > Was bedeutet ein Wert
    > irgendwo in der Mitte einer Dimension? Mittig von "einfach vs mächtig",
    > baut man da am liebsten "kleine Libraries" oder hat man schlicht keine
    > Präferenz?

    Ich könnte jetzt zu jedem deiner Fragen was schreiben, aber das klingt alles recht ähnlich. Deshalb beantworte ich dir nur diese Frage aus meinem Blickwinkel als "Engineer" ;)

    Ich habe bei dem Test in dieser Dimension recht mittig abgeschnitten, daher kann ich dir vielleicht meine persönliche Arbeitsweise und Ansichten in diesem Punkt darlegen. Vielleicht hilft das, ein exemplarisches Bild zusammen zu kriegen.

    Ich arbeite als AD- und Exchange-Admin zusammen mit fünf weiteren Kollegen. Ein Teil meiner Arbeit ist es, Trivialaufgaben in Form von einfachen Formularen und im Hintergrund agierenden Powershellscripten unseren Kunden als "Selfservice" zur Verfügung zu stellen (Z.B. bestimmte AD-Felder wie Telefonnummer, Büronummer usw. zur Bearbeitung zur Verfügung zu stellen). Die Überlegung dahinter ist, dass wir Admins uns mehr um die nicht trivialen Dinge in unserem Arbeitsalltag kümmern können und auch Zeit gewinnen, neue Anforderungen ohne das Hinzuziehen von externen Dienstleistern umzusetzen.

    Libraries schreibe ich normalerweise nur dann, wenn ich einen Mehrwert für weitere Projekte erkennen kann oder ich bestimmte Funktionalitäten mit meinen Kollegen teilen muss. Es handelt sich dabei stets um sehr spezifische Libraries, die einen bestimmten Zweck in unserer Anlage erfüllen. Darüber hinaus vermeide ich Abhängigkeiten zu fremden Libraries so gut ich kann - eine der wenigen Ausnahmen ist dabei das .NET-Framework, da wir die Formulare intern mit ASP.NET realisieren und der Powershell-Assembly zum Ausführen von Scripten über den Umweg der ASP.NET-Seiten. Das Niveau meines Quellcodes bewegt sich dabei irgendwo zwischen "Wirkt irgendwie ein wenig unsauber" bis "Er weiß, was er tut" über "Man kann eine gewisse Struktur erkennen" (Selbsteinschätzung, bzw. zwei Kollegen mit entsprechender Erfahrung haben sich in diese Richtung geäußert). Da wir von unseren Kunden selbst bei Fertig gestellten Formularen in gewisser Regelmäßigkeit nachträgliche Anforderungen aufgedrückt bekommen, die irgendwie mit ins System müssen, kommt es ständig zu Nachbesserungen direkt im Quellcode.

    Ich habe einen konkreten Plan und eine sehr konkrete Vorstellung, wie meine Formulare und Automatismen arbeiten sollen, welche Wege diese im Fehlerfall wählen sollen und in welcher Form Protokollierung stattfinden soll. Mein Ziel ist dabei, den Quellcode (speziell der Powershell-Teil) nach bestimmten Standards zu formulieren, die einem Neueinsteiger mit Powershellkenntnissen möglicherweise erst mal schwer fallen, aber nach einer gewissen Einarbeitungszeit leicht von der Hand gehen.

    Ich erarbeite mir "neue" Technologien selbstständig und habe vor etwa einem halben Jahr eine vernünftige Versionierung meiner Projekte mit Hilfe von Git eingeführt und arbeite mich derzeit in das MVC-Modell ein, um den Quellcode künftig noch leichter und lesbarer für die Arbeitskollegen zu gestalten.

    Gruß, Ronny



    1 mal bearbeitet, zuletzt am 05.09.18 11:18 durch rldml.

  5. Re: Unglaubwürdiges Modell

    Autor: Marconry 09.09.18 - 19:43

    > aber es wirkt als wenn dich diese Einsortierung auch ein wenig aufgewühlt hat.

    Haha :D Im Gegenteil, ich nehme das mit Humor. Trotzdem danke für deine Besorgnis. Nun zum Thema...

    > Nicht jeder ist Generalist noch dafür eingestellt. Wir haben einen Datenbank Guru (...) Dem ist das egal was vorne im Frontend läuft.

    Ein interessanter Punkt. Ich habe bei dem Geschriebenen an den Überblick "horizontal" über das Projekt gedacht. Also auf ungefähr dem gleichen Abstraktionsgrad.

    Du sprichst von vertikal (Datenbank <-> Frontend). Nicht jeder macht "Full-Stack", ich stimme zu. Vom Modell überzeugt bin ich trotzdem noch nicht, aus diesen Gründen:
    * Ich sehe nicht, wie das Modell einen Spezialisten (z.B. Datenbank-Guru) erfasst. Auf "abstrakt vs konkret" ist er wohl konkret. Das sagt aus, dass er sich für die Details statt den Überblick interessiert ("rather look at every single line of code"). Vertikal. Das sagt aber nicht aus, dass er sich horizontal nur für einen Teilbereich interessiert.
    * Ich denke, dass das Model gar nicht für die Unterscheidung auf diese Art gedacht ist. Für Datenbank-Gurus die keine Details aus dem Frontend kennen, und umgekehrt Frontendlern die keine Details in der Datenbank kennen, wäre der Vorwurf "du verlierst das Gesamtbild aus den Augen" ziemlich seltsam. Das passt eher auf "Funktion von Produktseite und Ratings kennen, von Warenkorb und Bestellstrecke nicht => kein Gesamtbild". Oder im Backend "Nicht alle Services und nicht wie sie zusammenarbeiten bekannt => kein Gesamtbild".

    > Wir haben Leute die fummeln ewig und drei Tage an Basics rum, weil der Kunde das Feature nicht vollständig beschrieben hat.

    Auch das hat nichts mit Idealismus zu tun. "Mit unvollständiger Featurebeschreibung arbeiten" insbesondere nicht in Bezug auf Codequalität. Ich verstehe schon, neutrale Begriffe kommen besser an als "Cowboy Coder" und "Architecture Astronaut". Mit dem was die Dimension repräsentiert sollte es aber doch zu tun haben.

    > Die Vorstellung dass immer alles wehtut, dann würde es vieles nicht mehr geben (...) Die Wahrheit ist: viele User können es sich nicht aussuchen

    Vergiss nicht, in dem Zusammenhang rede ich nur von der internen Codequalität. Was der Benutzer mitbekommt ist etwas anderes (wenn auch nicht immer trennbar). Und ich stimme dir zu, an externer Qualität kann man sehr wohl Abstriche machen.

    > Ich habe in einem Projekt gearbeitet, die sind auf dem Stand von .net 3.0.

    "Alter Code" ist nicht das gleiche wie "schlechter Code". Offenbar kommen die zwei Leute ja mit dem alten Code klar. Es gibt trotzdem Kosten.
    In einer ähnlichen Situation (alter Code, altes Framework) wollte mein damaliger Arbeitgeber das Team vergrößern. Am Ende mussten wir das verwerfen: Die offizielle Doku für das Framework war online nicht mehr verfügbar; Google-Ergebnisse nicht anwendbar weil für neuere Versionen. Wir hätten die Neuen intensiv einarbeiten und besser noch interne Doku schreiben müssen. Der ganze Aufwand wurde vom Management nicht genehmigt, weil er zu viel gekostet hätte.

    > Dann "Lebt" man mit dem madigen Code. Nicht jeder schreibt und betreibt Satellitensteuerungssoftware.

    Das Konzept "technische Schulden" und ihre Folgen existieren nicht erst seit gestern. Natürlich entwickelt trotzdem nicht jeder nach NASA-Standards. Als Folge sind Bugs schwerer zu finden und zu beheben, Features brauchen länger, usw. Das sind die Kosten die man hat, weil man nicht mehr in die interne Codequalität investiert hat (was ab einem gewissen Punkt viele Entwickler gerne nachholen würden). Die werden hier nur in Kauf genommen. Das ist gemeint damit, dass man für Codequalität auf die eine oder andere Art immer zahlt.

    > Würde man das nicht schon bei der Jobwahl vorauswählen?
    > Sehe ich nicht so. Ich sehe es eher nach dem Satz:
    > "Kann 'der' schon machen, dann wird es eben nicht so toll".
    > Menschen haben Präferenzen.

    D'accord, sage ich auch. Und mit Flexibilität meine ich die Bereitschaft, von den Präferenzen abzuweichen und wie weit. Da gibt es große Unterschiede. Es geht nicht darum ob es dann auf Anhieb toll wird, sondern um die Charaktereigenschaft. Die finde ich nicht im Modell.
    Wenn in der beschriebenen Situation ein Team nur aus robusten, konservativen Leuten besteht die _unflexibel_ sind, dann bringt ein neues Mitglied das Modernisierungen vorschlägt rein gar keine Veränderung. Und es wird wenig Spaß bei der Arbeit finden, so mit dem Ruf als "Ketzer". ;)

    > Viele der Charaktere erkenne ich als Grundtypen

    Klar, die Typen sind "intuitiv erkennbar". Aber wie in einem anderen Thread gesagt wurde, Horoskope sind das auch. Ich bin weiterhin skeptisch, was dieses Modell angeht.

    > aber gleichzeitig mag ich es wenn das Fließband immer schön sanft am rennen ist.

    :D hört sich gut an.

  6. Re: Unglaubwürdiges Modell

    Autor: a user 10.09.18 - 11:07

    Marconry schrieb:
    --------------------------------------------------------------------------------
    > Dass das Design-Types-Modell ernst zu nehmen ist glaube ich erst, wenn es
    > von Experten bestätigt wurde. Bis dahin ein bisschen Kritik vom Laien. ;)
    >
    > Wie der Artikel schon sagt sind die Typen nicht gleichverteilt. Man kann
    > sagen "der Entwickler war nur nicht ehrlich mit sich selbst" oder das
    > Modell hinterfragen. Und manche Typen ergeben keinen Sinn.
    >
    > Etwa der Uhrmacher: Jemand der sich zwar in den Einzelteilen seines
    > Projekts extrem gut auskennt, aber dennoch das Gesamtbild nicht sieht?
    > In einer Einarbeitungsphase kann ich mir das gut vorstellen: Man fängt
    > irgendwo im Projekt an und tastet sich vorwärts. Man kennt fast alle Teile
    > gut, und dann macht es "klick". Aber als Dauerzustand, als Charaktertyp,
    > wie kann so jemand als Entwickler überhaupt zurechtkommen? Unglaubwürdig.
    > Und natürlich will das niemand sein. Dass die Rollen "wertfrei" oder
    > "gleichwertig" sind kann man nicht behaupten.
    So Leute kenne ich einige.
    >
    > Mit den vier Dimensionen des Modells bin ich auch nicht einverstanden.
    >
    > Mit "pragmatisch vs idealistisch" zum Beispiel überhaupt nicht. Mal
    > überspitzt: Pragmatisch sind laut Modell die Entwickler, die "schnell
    > schnell" irgendwas hinrotzen. Hauptsache es "funktioniert". "Idealistisch"
    > dagegen die, die erst mal gründlich durchplanen, bevor überhaupt eine Zeile
    > getippt wird. Das Wasserfallmodell kommt unweigerlich in den Sinn.
    > Aber ist der feste Glaube an "schnelle Time to Market über alles" nicht
    > ebenso idealistisch? Ist es nicht pragmatisch, heute ein paar Zeilen Code
    > in eine Funktion auszulagern, damit morgen das Projekt mit den
    > (unweigerlich hinzukommenden) neuen Anforderungen wachsen kann?
    > Doch, denn die Dimension hat gar nichts mit Pragmatismus und Idealismus zu
    > tun! Stattdessen mit der Frage, wann der beste Zeitpunkt ist in interne
    > Codequalität zu investieren. Entweder früh und kontinuierlich, sodass man
    > zu jeder Zeit brauchbaren Code hat. Oder spät und geballt, der
    > Spaghetticode hat sich unbeherrschbar hoch aufgetürmt, jetzt ist man im
    > Zugzwang.
    Irgendwie scheint mir das eher so, dass du da was nicht verstanden hast, insbesondere nicht die Begriffe Idealismus und Pragmatismus. Das wird jetzt aber recht lang darauf einzugehen.
    >
    > Der Dimension liegt das verbreitete Missverständnis zugrunde, dass man auf
    > interne Codequalität verzichten könnte. Dass sie, frei nach dem Buch
    > "Peopleware", wie Schokosoße auf Vanilleeis reine Geschmackssache ist: Der
    > eine mag mehr, der andere weniger. Ist aber nicht so, Peopleware belegt das
    > gut. Codequalität bezahlt man immer - im schlimmsten Fall kostet es das
    > Projekt.
    Klar kann man darauf teilweise verzichten. Das man dann dafür bezahlt ändert daran nichts. Deswegen heißt es ja "Trade-OFF".
    >
    > Mit den anderen Dichotomien bin ich soweit d'accord.
    > Für "einfach vs mächtig" sehe ich als typisches Beispiel, dass manche
    > Entwickler lieber gezielte Anwendungen bauen, andere lieber Libraries und
    > Frameworks. "Abstrakt vs konkret" verstehe ich so, dass die einen Top-Down,
    > die anderen Bottom-Up arbeiten. Keine Einwände bis hier.
    > Aaaaber: Wohldefiniert ist die Skala dagegen nicht. Was bedeutet ein Wert
    > irgendwo in der Mitte einer Dimension? Mittig von "einfach vs mächtig",
    > baut man da am liebsten "kleine Libraries" oder hat man schlicht keine
    > Präferenz? Wenn man "ein bisschen abstrakt" ist, arbeitet man dann
    > Inside-Out, oder kommt man mit allem zurecht, oder vielleicht mit nichts?
    > Alles davon kann prinzipiell vorkommen, aber nur eins abgebildet werden.
    > Welches ist nicht klar.
    Err, das überascht mich jetzt. Die Werte zwischen zwei Richtungen bilden sich nicht auf konkrete Eigenschaften ab. Es gibt nur an, wieviele Fragen mehr oder weniger in die eine oder andere Richtung beantwortet wurden. Eine stetige Abbildung auf Eigenschaften ist weder beabsichtigt noch so einfach machbar.
    >
    > Und eine wichtige Eigenschaft von Entwicklern taucht im Modell überhaupt
    > nicht auf: Flexibilität. Bin ich in meinem Denken festgefahren; auch, aber
    > nicht nur im Rahmen der Dimensionen des Modells? Kann ich mein Ziel, meine
    > Herangehensweise situativ anpassen? Beharre ich auf meinem Standpunkt oder
    > kann ich kooperieren? Vielleicht ist das implizit in den Ausprägungen der
    > Dimensionen enthalten, dann hat das Modell wiederum andere blinde Flecke.
    Ich sehe das durchaus bereits enthalten. Aber warum sollte es deswegen andere blinde Flecke haben?
    >
    > Und zum Schluss etwas "Meta": Die Kategorisierung in Entwicklertypen ist
    > eine Einladung zum Schubladendenken. Man liegt in allen Dimensionen fast
    > mittig, trotzdem: "Ich bin Magician" - "Ah, typisch pragmatisch produzierst
    > du Code immer auf der Überholspur". Oder aus dem Artikel: "Leute, die zum
    > robusten Typ zählen, also auf Stabilität aus (...) aber nicht offen für
    > neue Technologien sind". Menschen sind vielschichtiger als das. Ein kleiner
    > Fragebogen im Netz oder in der Bunten erfasst das nicht. Das sollte man
    > immer im Hinterkopf behalten.
    Deswegen die Balkengrafik und diese zweite, die zeigt wie abgegrenzt du von anderen und benachbarten Typen bist.
    >
    > Angesichts dessen, dass es ihr Modell zwei Jahre gibt und die Autoren
    > bereits ein Entwickler-Mau-Mau darauf aufgebaut haben ist der Zug wohl
    > abgefahren. Wo ich damit wohl auf "optimistisch vs pessimistisch" liege? ;P

    Selbst wenn ich deiner Kritik zustimmen würde, wäre es bestenfalls Anlass für Verbesserungen. Aber ich sehe nichts,d ass selbst wenn es zutreffen würde es rechtfertigen würde von einem unglaubwürdigen Modell zu reden.

    Was ist dein Problem? Irgendwas scheint dich zu beschäftigen.

  7. Re: Unglaubwürdiges Modell

    Autor: Marconry 16.09.18 - 00:43

    > Vielleicht magst du die Dimension nicht, weil du zu idealistisch bist und "die andere Seite" nicht ernst nehmen kannst.

    So wie ich dich verstehe denkst du ich lehne die Dimension ab, weil ich der Meinung wäre es gäbe genau eine richtige Ansicht: Die eurer Java-Experten. Deswegen das Gegenbeispiel "Schau, die Java-Experten machten genau das was du sagst, und das war totaler Müll". Korrigiere mich gerne.

    Dem ist nicht so. Ich lehne die Dimension ab, weil sie meiner Ansicht nach keine Charaktereigenschaft erfasst.
    Und zusätzlich wegen des falschen Gegensatzes, dass sich "Qualität" und "Geschwindigkeit" zwingend gegenüber stehen müssten oder unabhängig wählbare Größen wären. Das ist das, was die Schokosoßen-Analogie aussagt. Der Glaube ist "mein Eis ist immer lecker, Soße ist optionales Extra". Nicht ganz, die interne Codequalität beeinflusst die mögliche Geschwindigkeit. Wer niemals sinngemäß den Satz "Das geht nicht so schnell, der Code ist furchtbar" gehört hat darf sich sehr glücklich schätzen.

    > Damit will ich nicht sagen, dass es in der IT keinen Platz für Idealisten gibt. Aber im GUI-Bereich halte ich mich von ihnen lieber fern.

    Schade, dass das Team so uneinsichtig war was den Testplan angeht. Ich wäre mehrstufig vorgegangen: Manueller Testplan, und nach und nach so viel wie möglich davon automatisieren. Das ist auch eine Investition in Qualität (eine bedeutende, manuelles Testen ist ein ziemlicher Aufwand - habe zeitweilig in der QS gearbeitet). Nebenbei, dazu gibt es einen lesenswerten Artikel namens "Manual Work is a Bug". Der Anfang wird manuell gemacht: "Phase 1: Document the steps".

    So wie deine Erzählung klingt hat das Cargo-Culting geschadet, und die Test-Suite die nicht hält was sie verspricht trug ihren Teil bei. Brrr, gruselige Geschichte. :) Danke für's Erzählen.

  8. Re: Unglaubwürdiges Modell

    Autor: Marconry 16.09.18 - 01:38

    > Irgendwie scheint mir das eher so, dass du da was nicht verstanden hast (...)
    > Das wird jetzt aber recht lang darauf einzugehen.
    Kenne ich - man denke an das berühmte Zitat "Ich schreibe dir einen langen Brief, weil ich keine Zeit habe, einen kurzen zu schreiben". Dennoch schade, nur die Aussage "du hast wahrscheinlich was nicht verstanden" ist nicht hilfreich. Dass meinerseits ein Missverständnis vorliegen kann schließe ich übrigens nicht aus.

    > Deswegen heißt es ja "Trade-OFF".
    Mea culpa, das habe ich falsch geschrieben. Siehe auch meine Antworten an Trockenobst und Stopfpfropf.

    > Die Werte zwischen zwei Richtungen bilden sich nicht auf konkrete Eigenschaften ab. (...) Eine stetige Abbildung auf Eigenschaften ist weder beabsichtigt noch so einfach machbar.
    Du hast schon Recht. Im Endeffekt gibt der Wert das Verhältnis der Antworten "links vs rechts" an. Und wie weit lassen sich darüber hinaus auch Aussagen treffen, warum dieses Verhältnis zustande gekommen ist? Darauf will ich hinaus.

    > Ich sehe das durchaus bereits enthalten.
    Kannst du auch einen kurzen Überblick geben, wie?

    > Aber warum sollte es deswegen andere blinde Flecke haben?
    Das bezieht sich auf den Absatz mit "Alles davon kann prinzipiell vorkommen, aber nur eins abgebildet werden" den ich davor geschrieben hatte. Ein Aspekt wird abgebildet, ergo ein anderer nicht, ergo blinder Fleck.
    An sich kann ein Modell nicht alles erfassen, dann wäre es kein Modell mehr. Ich denke aber ich habe gezeigt, dass relevante Details unter den Tisch fallen.

    > Selbst wenn ich deiner Kritik zustimmen würde, wäre es bestenfalls Anlass für Verbesserungen.
    Aus einem unglaubwürdigen Modell würde so ein glaubwürdiges Modell werden. Das wäre doch gut, verstehe den Einwand nicht.

    > Aber ich sehe nichts,d ass selbst wenn es zutreffen würde es rechtfertigen würde von einem unglaubwürdigen Modell zu reden.
    Das Modell ist momentan eine Behauptung ohne Grundlagen und Belege(*). Das alleine rechtfertigt es bereits (Hitchens' Rasiermesser). Darüber hinaus sehe ich die Dimensionen als bestenfalls ungenau spezifiziert und eine davon als gar keine Charaktereigenschaft.
    (*: Ich gehe davon aus, dass es nicht vollkommen beliebig aus den Fingern gesaugt ist. Allerdings haben die Autoren nichts auf ihrer Webseite veröffentlicht womit sich das Modell verifizieren ließe.)

    In dem Lichte finde ich es eigentlich witzig, dass du nach tiefergehenden Beweggründen fragst. Gelegentlich ist Kritik einfach Kritik. ¯\_(ツ)_/¯

  9. Re: Unglaubwürdiges Modell

    Autor: Marconry 16.09.18 - 21:17

    > Deshalb beantworte ich dir nur diese Frage aus meinem Blickwinkel als "Engineer" ;)

    Danke, Ronny, für deine Schilderung. Du hast das sehr anschaulich beschrieben. Und, persönliche Anmerkung, ich finde deine Arbeitsweise gut so. Besonders, dass du den Quellcode für andere gut verständlich hältst.

    Also habe ich eine sehr lebendige Vorstellung für "mittig in einfach vs mächtig". Die nächste Frage ist nun, ob Entwickler mittig in dieser Dimension generell eine ähnliche Arbeitsweise haben oder der Wert auch anders zustande kommt. Und wenn ja, wie groß der Unterschied ist.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BayWa r.e. Solar Energy Systems GmbH, Tübingen
  2. AKDB, Regensburg
  3. DOMCURA AG, Kiel
  4. Sagemcom Fröschl GmbH, Walderbach (zwischen Cham und Regensburg)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. 119,90€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Wet Dreams Don't Dry im Test: Leisure Suit Larry im Land der Hipster
Wet Dreams Don't Dry im Test
Leisure Suit Larry im Land der Hipster

Der Möchtegernfrauenheld Larry Laffer kommt zurück aus der Gruft: In einem neuen Adventure namens Wet Dreams Don't Dry reist er direkt aus den 80ern ins Jahr 2018 - und landet in der Welt von Smartphone und Tinder.
Ein Test von Peter Steinlechner

  1. Life is Strange 2 im Test Interaktiver Road-Movie-Mystery-Thriller
  2. Adventure Leisure Suit Larry landet im 21. Jahrhundert

Dark Rock Pro TR4 im Test: Be Quiet macht den Threadripper still
Dark Rock Pro TR4 im Test
Be Quiet macht den Threadripper still

Mit dem Dark Rock Pro TR4 hat Be Quiet einen tiefschwarzen CPU-Kühler für AMDs Threadripper im Angebot. Er überzeugt durch Leistung und den leisen Betrieb, bei Montage und Speicherkompatiblität liegt die Konkurrenz vorne. Die ist aber optisch teils deutlich weniger zurückhaltend.
Ein Test von Marc Sauter

  1. Dark Rock Pro TR4 Be Quiets schwarzer Doppelturm kühlt 32 Threadripper-Kerne

Battlefield 5 im Test: Klasse Kämpfe unter Freunden
Battlefield 5 im Test
Klasse Kämpfe unter Freunden

Umgebungen und Szenario erinnern an frühere Serienteile, das Sammeln von Ausrüstung motiviert langfristig, viele Gebiete sind zerstörbar: Battlefield 5 setzt auf Multiplayermatches für erfahrene Squads. Wer lange genug kämpft, findet schon vor der Erweiterung Firestorm ein bisschen Battle Royale.

  1. Dice Raytracing-Systemanforderungen für Battlefield 5 erschienen
  2. Dice Zusatzinhalte für Battlefield 5 vorgestellt
  3. Battle Royale Battlefield 5 schickt 64 Spieler in Feuerring

  1. Bundesarbeitsgericht: Amazon kann Streikende auf Parkplatz nicht verbieten
    Bundesarbeitsgericht
    Amazon kann Streikende auf Parkplatz nicht verbieten

    Streikversammlungen auf dem Firmenparkplatz kann Amazon nicht verbieten, weil das angeblich gefährlich sei. Eine kurzzeitige, situative Beeinträchtigung seines Besitzes muss Amazon hinnehmen, urteilte das Bundesarbeitsgericht.

  2. MBBF: LTE wird der Basislayer von 5G
    MBBF
    LTE wird der Basislayer von 5G

    Mit dem Rollout von 5G verliert 4G nicht an Bedeutung. Die Netze werden verschmelzen. Für die Telefónica Deutschland bleibt LTE sogar unerlässlich.

  3. Fallout 76: Bethesda entkoppelt Framerate und Physik
    Fallout 76
    Bethesda entkoppelt Framerate und Physik

    Ein jahrelanges Ärgernis der Gamebryo- und später der Creation-Engine wurde behoben: Der neue Patch für Fallout 76 ermöglicht mehr als 60 fps, ohne dass die Physik nach einer Weile verrücktspielt.


  1. 19:49

  2. 19:01

  3. 18:44

  4. 17:09

  5. 16:20

  6. 16:15

  7. 16:04

  8. 15:49