Archiv verlassen und diese Seite im Standarddesign anzeigen : UML - Buzzword für Manager?
UML ist etwas, das die Welt nur zum rumwirtschaftlern braucht. Da gehen wertvolle Arbeitsstunden drauf, um Manager und Wirtschaftsinformatiker vom Konzept zu überzeugen, oder wenn vom Auftraggeber eine Dokumentation gefordert ist, generiert man halt ein Klassendiagramm raus.
Ich verstehe auch gar nicht, warum man auf UML so abgehen muss. Wahrscheinlich niemand bestreitet, dass es gut ist, einen Stift und Papier zur Hand zu haben. Seit Jahren zeichen Entwickler (und architects, programmers, coders, consultants, ...) Klassendiagramme, Flußdiagramme und Sequenzdiagramme. In manchen Fällen sicherlich äußerst nützlich, aber wer mein Klassendiagramm nicht versteht, weil ich jetzt einen einfachen Pfeil anstatt eines mit einer dreieckigen Pfeilspitze gemalt habe, der sollte das Programmieren lieber bleiben lassen.
Jedes Diagramm benötigt sowieso eine Erklärung von jemandem der im Projekt drin ist, damit man die ganze Idee rüberbringen kann. Ein Haufen Klassen mit Pfeilen darin erklärt nie, wie das jetzt alles auszusehen und zu funktionieren hat. Wie eine Klasse im Diagramm auszusehen hat, da kann man improvisieren, das ist nicht das schwierigste, rauszulesen. UML will die Entwickler in ein Korsett zwingen, nicht mehr frei improvisieren und das Wesentliche hinkritzeln zu können, dabei muss es gar nicht sein, dass ein UML-Sequenzdiagramm gerade die beste Darstellungsform ist. Wir haben bei einem Studienprojekt den Schmarrn schon mal weggeworfen, was anderes hingekritzelt, dem Prof erklärt und die beste Arbeit abgegeben. Wie gesagt, nichts gegen Stift und Papier.
AlSvartr
2006-08-18, 13:09:55
Ich würde mal sagen du hast Recht und Unrecht zugleich :D ... ich persönlich bin von UML auch nicht besonders angetan...es ist sicherlich ein nettes Werkzeug, aber man kann sich auch tot-UMLen, wenn man wirklich alles nur nach diesem Standard planen und formulieren möchte. Ich fand es sehr amüsant, als bei uns an der FH mal ein Vortrag zweier Leute von BlueByte stattfand, die über die Siedler-Reihe sprachen. In der Hörerschaft saß auch unsere Software Engineering-Prof'in, die dann irgendwann gegen Ende fragte, wie denn die ganze Planung und Kommunikation zwischen den einzelnen Teams wohl aussehe...tja, kurz gesagt, der erste Satz, der als Antwort kam, war: "Wir machen keine UML-Diagramme oder so!"...die war nicht gerade zufrieden... ;)
"Wir machen keine UML-Diagramme oder so!"...die war nicht gerade zufrieden... ;);D
Vorweg: Ich programmiere nur privat!
Wir fertigen auch manchmal UML Diagramme an, aber nicht von allem, und meistens nur Klassendiagramme die man ausdrucken kann. Ist ziemlich praktisch wenn man so eine kleine Doku von einer Klasse dann hat die man selbst nicht erstellt hat.
Der Sinn von den Sequenzdiagrammen versteh ich bis heute nicht. Werde sowas nie brauchen
Monger
2006-08-18, 13:49:07
UML Diagramme sollen die Dokumentation ersetzen bzw. ergänzen. Sie sind weder als Skizze noch als Vortragsmedium gedacht oder geeignet.
Deshalb: wenn man bis zu dem Punkt kommt, wo man für die Nachwelt dokumentieren will was man getan hat, kann UML einem schon weiterhelfen, weil die Symbole eben überall gleichermaßen anerkannt sind.
Für den Entwurf aber ist UML eine Krankheit, da gebe ich dir recht. Es gab ja auch so Bestrebungen, direkt aus den UML Diagrammen fertige Klassenkonstrukte zu zimmern. Afaik ist dieser Ansatz zwar inzwischen technisch möglich, aber nicht wirklich erfolgreich.
Dass man zu Anfang eines Softwareprojektes schon hundertprozentig weiß wo man später landen wird, ist äußerst selten. Das setzt voraus, dass es auf dem Weg überhaupt keinen Entwicklungsprozess gibt.
UML Diagramme sollen die Dokumentation ersetzen bzw. ergänzen. Sie sind weder als Skizze noch als Vortragsmedium gedacht oder geeignet.
Deshalb: wenn man bis zu dem Punkt kommt, wo man für die Nachwelt dokumentieren will was man getan hat, kann UML einem schon weiterhelfen, weil die Symbole eben überall gleichermaßen anerkannt sind.
Für den Entwurf aber ist UML eine Krankheit, da gebe ich dir recht. Es gab ja auch so Bestrebungen, direkt aus den UML Diagrammen fertige Klassenkonstrukte zu zimmern. Afaik ist dieser Ansatz zwar inzwischen technisch möglich, aber nicht wirklich erfolgreich.
Dass man zu Anfang eines Softwareprojektes schon hundertprozentig weiß wo man später landen wird, ist äußerst selten. Das setzt voraus, dass es auf dem Weg überhaupt keinen Entwicklungsprozess gibt.
Das ist leider alles vollkommen falsch, du solltest dich mit dem Thema genauer beschäftigen. Und wenn du schon dabei bist, auch gleich noch mit Prozessmodellen wie MSF oder das Pendant von IBM.
Genau das ist der Punkt, der hier einfach nicht verstanden wird:
UML ist kein 'Goldener Hammer' (siehe Antipatterns).
Wenn ein Manager mit Hilfe von Umsatz-Charts über seine Anforderungen, Ziele und Konzepte für SW sprechen möchte, darf er das! Der Elektroingeieur mit seinen Schaltplan, der Lagerist mit seinen Bestandslisten, der Kraftwerksleiter mit seinem Power-Grid Plan etc. Und der SW- Éntwickler mit UML. Meine Aufgabe als Analyst, Architekt, Entwickler oder Anforderungsmanger ist es Roundtrip-Engineering zwischen den Domainmodellen der Stakeholder und meiner SW zu betreiben - ich bin der Analytiker. So, jetzt versuch mal eine bidirektionale Traceability zwischen Code und z.B. einer CAD Zeichung herzustellen. Klar kannst Du remarks reinschreiben, aber versuch mal das System zu warten und zu überblicken. Genau das ist der Vorteil von Visualisierungen! In der Konzeptentwicklung werden aber nicht nur zwei sondern sehr viele Aspekte von unterschiedlichen Domainen aufeinandergestellt - HW, SW, Management, Testen, Wartung, Operationen, Prozesse etc. und die kannst Du ja gerne direkt im Code warten fürs Changemanagement. Wir Profis machen es nicht so ...
Genau deshalb betreibt man Abstraktion und Modellierung. Das ist nicht nur in der SW-Entwicklung so, dass ist in faßt allen Fachbereichen so. Und was soll jetzt hier die Ausrede sein es nicht zu tunen. Das Du eine Codezeile schneller ändern kannst?!
UML ist nicht reversibel und eignet sich damit nicht für roundtrip-engineering.
UML ist nicht reversibel und eignet sich damit nicht für roundtrip-engineering.
Geht's noch genauer? In anbetracht der Tatsache, dass es viele und vor allem auch äußerst teure Profi-Software gibt (z.B. von Rational oder VS.NET Teamsystem), die das ermöglicht, solltest du schon etwas mehr ins Detail gehen.
zeckensack
2006-08-18, 15:33:59
Trotzdem war's extrem enterprisey formuliert, das muss man ihm schon lassen.
Geht's noch genauer? In anbetracht der Tatsache, dass es viele und vor allem auch äußerst teure Profi-Software gibt (z.B. von Rational oder VS.NET Teamsystem), die das ermöglicht, solltest du schon etwas mehr ins Detail gehen.
Mit genug Aufwand kann man alles für jeden Zweck benutzbar machen. Das ist dann aber kein Verdienst des ursprünglichen Dings.
Es gibt keine einfache Möglichkeit UML für round-trip engineering zu nutzen => UML für round-trip enginnering ungeeignet. Siehe z.B. auch http://citeseer.ist.psu.edu/247565.html (hab ich grad eben gegoogelt, ist vielleicht nicht das beste Paper zum Thema, aber zumindest nicht schlecht).
Rational ist vielleicht ganz brauchbar (bezweifel ich irgendwie), aber das liegt nicht daran, dass es UML benutzt, es wäre mit jeder anderen Notation genauso.
Wenn ein Manager mit Hilfe von Umsatz-Charts über seine Anforderungen, Ziele und Konzepte für SW sprechen möchte, darf er das! Der Elektroingeieur mit seinen Schaltplan, der Lagerist mit seinen Bestandslisten, der Kraftwerksleiter mit seinem Power-Grid Plan etc. Und der SW- Éntwickler mit UML.Klar, darf man alles hernehmen. Aber es ist Bullshit, zu glauben, dass man damit anderen etwas erklären kann. Wenn du für dich ein Diagramm (egal welcher Art) als Gedächtnisstütze machst, super! Dass es UML sein muss, ist schon die allererste Fehlannahme. Es ist völlig egal, ob es irgendeiner formalen Vorschrift genügt. Sobald man anderen was damit erklärt, muss man wieder was dazu erzählen und spätestens dabei wird jedes Wirtschaftler-Geblubber gnadenlos enttarnt.
Meine Aufgabe als Analyst, Architekt, Entwickler oder Anforderungsmanger ist es Roundtrip-Engineering zwischen den Domainmodellen der Stakeholder und meiner SW zu betreiben - ich bin der Analytiker.Nach dem, was du hier aufzählst, bist du ein Software-Entwickler. Die Putzfrau macht auch keine höhere Arbeit, wenn sie Sanitärbeauftragte heißt. Klar ist die Arbeit vielseitig und man sitzt nicht nur vor dem Computer und tippt. Dafür braucht man sich aber nicht für jede Tätigkeit einen neuen Buzz-Namen ausdenken, sonst bist du irgendwann Direct art and Production support and Product senior stylistic supervisor.
So, jetzt versuch mal eine bidirektionale Traceability zwischen Code und z.B. einer CAD Zeichung herzustellen. Klar kannst Du remarks reinschreiben, aber versuch mal das System zu warten und zu überblicken.Das hättest du auch mit weniger gebuzze sagen können, oder? Ist das eigentlich eine dumme Angewohnheit von dir? Redest du mit jedem so? Kann man sowas ernst nehmen? Hätte es das rein deutsche Äquivalent nicht getan? Hättest du nicht einfach schreiben können "Wie kann ich Zusammenhänge zwischen Code und einer CAD-Zeichnung nachvollziehen, überblicken und warten"? Oder ist die Entropie (Informationsgehalt pro Datenmenge) dieser Botschaft doch höher als angenommen?
Genau das ist der Vorteil von Visualisierungen!Der Vorteil von Visualisierungen im Allgemeinen wird nicht abgestritten.
In der Konzeptentwicklung werden aber nicht nur zwei sondern sehr viele Aspekte von unterschiedlichen Domainen aufeinandergestellt - HW, SW, Management, Testen, Wartung, Operationen, Prozesse etc. und die kannst Du ja gerne direkt im Code warten fürs Changemanagement. Wir Profis machen es nicht so ...Wir auch nicht. Wir verwenden Bugtracking-Systeme, Versionskontroll-Systeme, ja manchmal sogar mach ich einen Rechtsklick in Visual Studio und schau mir das Klassendiagramm (nicht UML-konform) an. Das kann man alles jeder für sich machen, da braucht man keinen Manager, der jetzt dick auflabert und sich auf UML was einbildet.
Genau deshalb betreibt man Abstraktion und Modellierung. Das ist nicht nur in der SW-Entwicklung so, dass ist in faßt allen Fachbereichen so. Und was soll jetzt hier die Ausrede sein es nicht zu tunen [tun?]. Das Du eine Codezeile schneller ändern kannst?!Jetzt auf einmal wieder so pragmatisch? Du erinnerst mich die meiste Zeit eher an einen Manager, der seine Mitarbeiter anweist "mach' mir mal ein UML-Diagramm, damit ich ..Roundtrip-Engineering...Domainmodellen...Stakeholder...bidirektionale Traceability...remarks...Changemanagement ... kann." und danach wird es zu den Akten gelegt. Sowas ist einfach nur g'schaftlig.
UML kann man schon hernehmen, wenn man sich an der umständlichen Notation nicht stört aber gespickt mit Buzzwords und Wichtigtuerei kommt es zu oft in die Hände von Leuten, die glauben, dass es ohne gar nicht mehr geht. Und das ist das Problem bei UML. Die Idee, ein paar Notationen zu vereinheitlichen, mag ja nicht verkehrt sein (auch wenn ich mich Frage, zu welchem Problem das die Lösung ist).
FlashBFE
2006-08-18, 18:30:44
Wir haben ja im Studium Innovator gelernt, was auch so ein UML Paket ist. Es war schon irgendwie interessant, so seine 150 verschiedenen Diagramme zusammenzuklicken und sich dann vollautomatisch den Quelltext erzeugen zu lassen, also Klassenstruktur und Schnittstellen usw.. Dann drin rumprogrammieren und die Logik einfügen bis es läuft und den Quelltext wieder importieren und in UML zurückverwandeln. Round-Trip-Engineering in Höchstform also. Wenn ich könnte, würde ich aber trotzdem alles tun, um sowas zu vermeiden. Es kostet einfach einen Haufen Zeit.
Sobald man anderen was damit erklärt, muss man wieder was dazu erzählen und spätestens dabei wird jedes Wirtschaftler-Geblubber gnadenlos enttarnt.
Hä? Sollen UML Diagramme etwa 100% selbsterklärend sein und jedliches Wissen überflüssig machen? Wer hat denn das behauptet?
Nach dem, was du hier aufzählst, bist du ein Software-Entwickler. Die Putzfrau macht auch keine höhere Arbeit, wenn sie Sanitärbeauftragte heißt. Klar ist die Arbeit vielseitig und man sitzt nicht nur vor dem Computer und tippt. Dafür braucht man sich aber nicht für jede Tätigkeit einen neuen Buzz-Namen ausdenken, sonst bist du irgendwann Direct art and Production support and Product senior stylistic supervisor.
Vielleicht bist du einfach nur zu dumm, aber die Aussage vom anderen Gast heißt lediglich, dass an einem komplexen Projekt mehrere Personen (Vom Manager über Entwickler bis Tester und Administrator) partizipieren. UML (von mir aus auch was anderes) sollte dann eben alle Prozesse abbilden.
Das kann man alles jeder für sich machen, da braucht man keinen Manager, der jetzt dick auflabert und sich auf UML was einbildet.
Nein das kann nicht jeder für sich machen, weil sich UML nicht auf Klassendiagramme oder Sequenzdiagramme beschrenkt. Und in vielen Firmen gibt es bei Projekten eine klare Trennung wer mit dem Kunden Kontakt hat, die Anforderungen ausarbeitet und diese Aufgaben jeweils an unterschiedliche Abteilungen verteilt.
und danach wird es zu den Akten gelegt. Sowas ist einfach nur g'schaftlig.
UML kann man schon hernehmen, wenn man sich an der umständlichen Notation nicht stört aber gespickt mit Buzzwords und Wichtigtuerei kommt es zu oft in die Hände von Leuten, die glauben, dass es ohne gar nicht mehr geht. Und das ist das Problem bei UML. Die Idee, ein paar Notationen zu vereinheitlichen, mag ja nicht verkehrt sein (auch wenn ich mich Frage, zu welchem Problem das die Lösung ist).
Das Problem ist eher, dass viele Leute keinerlei Ahnung von UML und Prozessmanagement haben. Für ein Einmanshow Projekt braucht man sicherlich kein Prozessmanagement-Modell, aber das verlangt auch niemand. Ab mittleren Projekten kann ich aber aus eigener Erfahrung nur dazu raten.
Ich mag UML für Diskussionen am Whiteboard... (ich meine, für hoch performante Group based Brainstormings mit multidirektionalem Knowledge Transfer). Es fällt leichter, eine kleine Klassenhierarchie zu zeichnen, als class hinzuschreiben, ist übersichtlicher, klarer. Man kann auch besser "editieren". Und dynamische Zusammenhänge lassen sich damit besser darstellen, gerade das fällt vielen Leuten schwer, sich vorzustellen wie das nachher alles aussieht, wenn sich die Objekte tatsächlich gegenseitig befeuern.
tokugawa
2006-08-18, 19:43:22
Ich mag UML primär als gut-definierte Kommunikationssprache zwischen den Entwicklern im Team, und damit auch als Dokumentations-Zusatz.
UML löst keine Probleme von selbst, aber es ist eine "Sprache" zur Kommunikation zwischen Entwicklern, die man verwenden kann, wenn man gerade eine Problem löst.
UML schafft nur Probleme. Lösen tut es keines.
Aquaschaf
2006-08-18, 20:01:42
hoch performante Group based Brainstormings mit multidirektionalem Knowledge Transfer
OT, aber wer denkt sich so schreckliche Deutsch-Englisch-Buzzword-Phrasen aus?
OT, aber wer denkt sich so schreckliche Deutsch-Englisch-Buzzword-Phrasen aus?Gerade als Programmierer verwendet man doch die ganze Zeit fachspezifische Fremdwörter die sonst niemand versteht. Erklärt seinem Chef warum das Projekt so toll ist indem man 10 neue Technologien, Design Pattern und sonstigen für den Chef absolut unwichtigen Unfug erzählt und regt sich im selben Satz darübe auf, dass der Chef seine eigene Fachsprache verwenet die man selbst nicht verstehen kann.
Wer es noch nicht gesehen hat: Die Abteilung der Programmierer ist in der Firma eindeutig das untere Ende der Nahrungskette. Hauptziel ist es nicht möglichst viele tolle und schöne Programme zu schreiben sondern dem Kunden die Software - so dämlich und buggy sie auch ist - zu verkaufen.
tokugawa
2006-08-18, 21:24:58
UML schafft nur Probleme. Lösen tut es keines.
UML schafft weder Probleme noch löst es eines. Es ist eine Sprache, die man nutzen kann, wenn man ein Problem löst oder nicht. Wenn daraus Probleme entstehen, liegt das nicht an UML, sondern eher am Prozeß an sich (der zwar mit UML verknüpft sein kann, aber nicht direkt UML ist).
Ist ja genauso wie man nicht sagen kann "Die Standard-Notenschrift schafft nur Probleme, lösen tut es keines". UML ist ein auch nur ein "Notationsstandard". Genau wie die Notenschrift in der Musik dazu da, dass mehrere Fachleute basierend auf demselbem Blatt Papier wissen, was Sache ist.
Aquaschaf
2006-08-18, 21:46:33
Gerade als Programmierer verwendet man doch die ganze Zeit fachspezifische Fremdwörter die sonst niemand versteht.
Das sind aber keine Fremdwörter in der von mir zitierten Phrase sondern da hat jemand nur einen Satz mit Pseudo-Informationen aufgeblasen.
tokugawa
2006-08-18, 21:48:22
Das sind aber keine Fremdwörter in der von mir zitierten Phrase sondern da hat jemand nur einen Satz mit Pseudo-Informationen aufgeblasen.
Jep, es gibt einen Unterschied zwischen qualifizierten (und qualifiziert benutzten) Fachbegriffen und Manager-Buzzword-Bingo. Gegen letzteres bin ich auch allergisch.
Sind hier die BWLer-Business-Typen ausgebrochen?
Jep, es gibt einen Unterschied zwischen qualifizierten (und qualifiziert benutzten) Fachbegriffen und Manager-Buzzword-Bingo. Gegen letzteres bin ich auch allergisch.
Joa me 2...
Zum Rest kann ich auch zustimmen. Diese Manager-Sprache ist meist Pseudoinformation mit Null Inhalt, die nur schön klingt. Die _eigentlich_ wichtige Information ist auf der Programmiererebene zu finden.
anyone want's to play Bullshit Bingo ? :D
http://www.doheth.co.uk/funny/misc/Bullshit_Bingo.gif
1. Ich halte UML für wichtig und gut. Und zwar immer dann, wenn es darum geht, bestimmte Strukturen oder Abläufe zu dokumentieren oder darüber mit irgendwem zu kommunizieren. Es ist wichtig, dafür eine standardisierte Sprache zu haben. Das beugt Missverständnissen vor (die Voraussetzung ist natürlich, dass alle Beteiligten diese Sprache sprechen). Es geht dabei nicht so sehr darum, ob UML nun die absolut beste Sprache für diesen Zweck ist, es geht mehr um die Standardisierung. UML ist anderen gleichwertigen Sprachen vorzuziehen, weil sie sich einfach durchgesetzt hat. Es sprechen nunmal sehr viele Leute UML, UML ist gut dokumentiert und UML wird in den Hochschulen gelehrt. Wenn man sich nur schnell mal eine Skizze machen möchte, um sich selbst etwas zu visualisieren, braucht man sicherlich kein UML. ...sofern die Skizze danach dann auch im Mülleimer landet und nicht in irgendweiner Art von Dokumentation. Aber als Kommunikationsmittel sind solche individuellen Skizzen IMHO eher weniger geeignet.
BTW: Es gibt ja auch in anderen Bereichen standardisierte Sprachen und das aus gutem Grund. Man stelle sich vor, im Flugverkehr kommt es zu irgendeinem Missverständnis. Soetwas kann ganz schnell zu einer Katastrophe führen. Und deshalb ist auch dort der Ablauf des Funkverkehrs sehr genau standardisiert. Ähnliches gilt für das Militär: Auch da ist die Kommunikation standardisiert.
2. Ich halte Fachsprachen und die Beherrschung dieser generell für wichtig und gut. Die Gründe sind praktisch genau die gleichen wie bei der UML. Mit einer passenden Fachsprache kann man sich unmissverständlich ausdrücken. Begriffe sind eindeutig definiert und müssen nicht immer wieder bei jedem Gespräch neu erarbeitet werden. Wie will man halbwegs effizient - in einem Team - arbeiten, wenn man keine Sprache hat, die dafür geeignet ist? Wie will man zu sinnvollen Gedanken in einem Gebiet kommen, wenn einem dafür die Sprache fehlt? Dumm ist es nur, wenn einem diese Fachsprache so sehr in Fleisch und Blut übergeht, dass man sie auch in anderen Zusammenhängen verwendet. Oder auch bei der Kommunikation mit Leuten, die diese Sprache nicht sprechen. Die würden das dann wohl nur als so eine Art Buzzword-Geplapper auffassen. Es kommt also immer auf den Zusammenhang an. Wenn man von "Profis" oder ähnlichem spricht, dann kann man aber davon ausgehen, dass jeder, der in diesem Zusammenhang gemeint ist, die entsprechende Sprache, sei es nun die UML oder eine andere Fachsprache, sprechen können sollte. Unter Profis ist das deshalb eindeutig auch die passende Kommunikationsgrundlage.
BTW: Wenn man sich mal den Inhalt von Hochschulstudien ansieht, stellt man fest, dass ein erheblicher Bestandteil davon das Lernen der Fachsprache(n) des jeweiligen Gebiets darstellt. Wenn man irgendwann mal ne mündliche Prüfung hat, dann fragt der Prüfer meistens genau das ab: Er versucht herauszufinden, ob sich der Prüfling in der entsprechenden Begriffswelt zurechtfindet, ob er mit den Begriffen etwas anfangen kann und ob er sich mit diesen Begriffen ausdrücken kann.
Mir kommt es hier irgendwie so vor, als ob viele hier eine Ideologie vertreten, die ähnlich wie z.B. Dijkstras Brandmauer der Informatik ihren eigenen Wirkungskreis komplett eingrenzt und große Barrieren zu allem zieht, was links und rechts davon liegt. Es wirkt so, als ob hier einige einen totalen Tunnelblick auf die Domäne haben, in der sie sich beheimatet fühlen.
tokugawa
2006-08-22, 05:25:40
Mir kommt es hier irgendwie so vor, als ob viele hier eine Ideologie vertreten, die ähnlich wie z.B. Dijkstras Brandmauer der Informatik ihren eigenen Wirkungskreis komplett eingrenzt und große Barrieren zu allem zieht, was links und rechts davon liegt. Es wirkt so, als ob hier einige einen totalen Tunnelblick auf die Domäne haben, in der sie sich beheimatet fühlen.
Das kannst du sicher genauer ausführen, oder? So ist das irgendwie etwas vage, was du von dir gibst...
Was meinst du genau?
Wenn ich's richtig verstehe meinst du dass hier viele "Fachidioten" unterwegs sind. Wäre vielleicht nützlich zu wissen, wen du genau meinst, und inwiefern deren Argumentation einen "Tunnelblick" erahnen lässt.
ethrandil
2006-08-22, 11:23:27
Wenn ich's richtig verstehe meinst du dass hier viele "Fachidioten" unterwegs sind. Wäre vielleicht nützlich zu wissen, wen du genau meinst, und inwiefern deren Argumentation einen "Tunnelblick" erahnen lässt.
Also ich kann den Gast schon verstehen, denke ich.
Dijkstras 'Brandmauer' umschreibt die Haltung Djikstas, dass Informatik sich "zwischen Logik und angewandter Mathematik" bewege und sich mit Korrektheit von Software beschäftige, jedoch NICHT mit dem Kontext, dem 'pleasantness problem'.
Ich bin der Meinung, wenn dann gibt es hier keine Brandmauer Djikstras, sondern eine Brandmauer zum Management. (Mir entstand der Eindruck, dass viele Poster hier eine generelle Abneigung oder eine Voreingenommenheit gegenüber Managern haben.)
Generell kann man aber auch sagen, dass es jedem frei steht auf welcher Seite der Brandmauer er sich positionieren möchte. Nur muss klar sein, dass es andere, ebenso legitime Haltungen gibt.
mfg
- eth
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.