Clean Code / Software Principles - Wo seid ihr??
-
@SeppJ
Vorweg: ich arbeite nicht in einer solchen Firma.Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.
in einer Firma, die groß genug ist, um ihre eigene Technik zu machen
Nur damit wir uns nicht falsch verstehen: ich meinte da z.B. auch Firmen die sowas wie SAP oder Dynamics AX verwenden und da eigene Anpassungen/Erweiterungen drin/dran haben. Dazu muss die Firma nicht besonders gross sein. Je nach Branche reicht da ein Betrieb mit ein paar hundert Mitarbeitern.
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Ojeh, wir sind also in einer Firma, die groß genug ist, um ihre eigene Technik zu machen, aber die Programmierer und/oder Manager sind weder in der Lage, den neuesten Stand der Technik zu verfolgen, noch international zu kooperieren. Da ist die Einschätzung, dass in der Firma etwas grundsätzlich schief läuft, schon ganz angebracht. Programmierer die nur Deutsch können, kannst du vielleicht vor 30 Jahren rechtfertigen, wo die Welt noch nicht so groß und verknüpft war, und man mit einer einfachen Ausbildung schon als Fachexperte zählen konnte. Heute heißt das, dass so jemand nur Jürgen Wolf lesen kann, anstatt Stackoverflow, und alle Entwicklungen der letzten 5-15 Jahre sind auch unzugänglich. Ich bin sicher, für Management gilt ähnliches.
Nehmen wir mal an, eine Behörde will eigene Geschäftsprozesse digitalisieren. Die Geschäftsprozessbeteiligten (aus mehreren Ländern mit verschiedenen 1. und ggf. 2. Sprachen) sprechen einheitlich die Sprache der Behörde (in D wäre das deutsch, setzen die Behörden jedenfalls voraus).
Die Geschäftsprozesse werden in der Behördensprache beschrieben, damit die Prozessbeteiligten diese verstehen können.
Aus den Geschäftsprozessen werden z.B. UML-Aktivitätsdiagramme. Damit diese mit den zugrundeliegenden Geschäftsprozessen verglichen werden können, werden alle darin vorkommenden Artefakte wie z.B. Aktivitäten (ggf. Methoden von Klassen) auch in der Behördensprache abgefasst.
Der Entwickler nutzt jetzt die für die "sichtbaren" Artefakte (Klassen, Methoden etc.) auch die Behördensprache. Kann natürlich jegliche anders sprachlichen Dinge z.B. aus Bibliotheken nutzen.
Ich habe auch schon gesehen, dass auf eine englischsprachige API eine deutsche "draufgelegt" wurde.
Wenn die Behörde ein Qualitätsmanagement betreibt, wird ein behördensprachlich sattelfester Mensch die Doku prüfen und ggf. sprachlich glattziehen.PS. Ich kann heutzutage alles aus dem Internet in fast jeder Sprache lesen! Translater und gesunde Interpretation.
-
@Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:
Ich kann heutzutage alles aus dem Internet in fast jeder Sprache lesen!
Du glücklicher! Ich bleibe öfters mal an TLA's (z.B. MO, RCA, TBD,...) oder English von Indern, Japanern und manchmal von Schweizern hängen.
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Da ist es natürlich trotzdem vertretbar, weil man 1980 in der BRD nicht genug englischsprachige Ingenieure zu dem Thema finden konnte. Aber wenn du das heute noch machen musst, dann hat deine Firma ein Problem, ein großes.
Wer sich bei überwiegend deutschsprachigen Mitarbeitern für eine englischsprachige Dokumentation entscheidet, wenn es dafür keine externen Gründe gibt, der entscheidet sich für eine schlechtere Dokumentation! Oder willst Du behaupten, Du wärst in der Lage Dich mit gleicher Qualität auf Englisch auszudrücken wie auf Deutsch? Es ist und bleibt eine Fremdsprache, und man erreicht niemals die gleiche Sprachkompetenz in einer Fremdsprache wie in der eigenen Muttersprache.
- Ja, ich kann das. Dokumentation ist keine Poesie. Ich muss keine Ballade schreiben, die den Leser zu Tränen rührt. Wobei ich durchaus einsehe, dass ich das besser kann als andere.
- Das ist keine Ausrede. Der Nachteil, sich in einer Nischensprache festgefahren zu haben, ist zu gravierend.
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.
Dass das so gelebt wird, bestreitet wohl niemand. Aber dass das ein Zeichen dafür ist, dass in der Firma krass etwas schief läuft, doch bestreitest du doch wohl auch nicht? Eine Firma deren Experten kein Englisch sprechen, ist wie ein Restaurantkoch, der nur Sachen aus dem eigenen Garten benutzt. Er mag noch so talentiert sein, das Ergebnis wird nicht mithalten können mit der Konkurrenz, die sich aus aller Welt bedienen kann.
@Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:
Der Entwickler nutzt jetzt die für die "sichtbaren" Artefakte (Klassen, Methoden etc.) auch die Behördensprache. Kann natürlich jegliche anders sprachlichen Dinge z.B. aus Bibliotheken nutzen.
Ich habe auch schon gesehen, dass auf eine englischsprachige API eine deutsche "draufgelegt" wurde.
Wenn die Behörde ein Qualitätsmanagement betreibt, wird ein behördensprachlich sattelfester Mensch die Doku prüfen und ggf. sprachlich glattziehen.Sind Behörden-IT-Projekte nicht berühmt für ihre überbordenden Kosten und ihr regelmäßiges Scheitern?
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Sind Behörden-IT-Projekte nicht berühmt für ihre überbordenden Kosten und ihr regelmäßiges Scheitern?
Für das Scheitern sind in der Regel die hoch kompetenten "Beratungsfirmen" verantwortlich. Teils auch, weil diese einfachste Probleme hochkomplex lösen wollen (könnte ja sonst der Kunde selbst ;-).
-
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Ich denke dir fehlt etwas die Erfahrung bzw. der Blick über den Tellerrand.
Genau deswegen habe ich hier diesen Thread eroeffnet. Mir geht es darum, ein guter Architect fuer meine Kollegen zu sein - und nicht nur einer der Vorschreibt was zu tun ist und wie dieses zu tun ist.
Dass es Ausnahmen der Regeln gibt, gerade bei einem Mittelstaendler (der mal ein Familienbetrieb war), ist klar - und dass es Branchen-Spezifische Fachwoerter gibt, die auf Englisch keiner mehr versteht - ja, auch moeglich.
Jedoch wollen gerade WIR zu einem "Global Player" werden, der wir aber noch lange nicht sind. Darum muss man einige Dinge eventuell Dogmatisch sehen.
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
- Das ist keine Ausrede. Der Nachteil, sich in einer Nischensprache festgefahren zu haben, ist zu gravierend.
Die Nischensprache Englisch ist gemeint? Die meiste IT-Dokumentation wird mittlerweile in chinesisch geschrieben, und das wird in Zukunft noch viel häufiger der Fall sein. In den USA wächst der Anteil der Spanischsprechenden immer mehr, so dass die Bedeutung des Englischen auch dort geringer werden wird. Deutsch ist die zweithäufigste Muttersprache in Europa (nach Russisch).
Ernsthaft formuliert, was für einen Sinn hat es in Pidgin-English Dokumentationen zu verfassen? Vielen ist gar nicht bewusst, wie schlecht sie Englisch sprechen und schreiben, und das führt dann zu Problemen, weil bestimmte Dinge nicht gut formuliert sind und zu Missverständnissen führen.
-
Lol wut? Zeig mir mal die Doku von Redwood.js, die Specs von DOCSIS 4, oder die Referenz von Tensoflow auf Chinesisch oder Deutsch.
Ernsthaft formuliert, was für einen Sinn hat es in Pidgin-English Dokumentationen zu verfassen? Vielen ist gar nicht bewusst, wie schlecht sie Englisch sprachen und schreiben, und das führt dann zu Problemen, weil bestimmte Dinge nicht gut formuliert sind und zu Missverständnissen führen.
Das Problem der Firma ist ein anderes, nämlich dass sie Techniker im Dienst haben, die nicht ausreichend Englisch sprechen, als dass man sie auf dem internationalen Markt ernst nehmen kann. Dann wird die Webseite eben mit reinem Javascript nach Jürgen Wolf geschrieben; das Verteilernetz wird nach Anleitung der Bundespost betrieben; und die Daten nur mit Methode kleinster Quadrate nach Gauss interpretiert. Das kannst du dir nur erlauben, wenn du aufgrund geografischer Faktoren keine Konkurrenz hast, und keine Ambitionen, jemals größer zu werden.
Ich hätte jetzt den Bäcker von der Ecke als Beispiel für einen Betrieb ohne internationale Konkurrenz gebracht, aber dann fiel mir ein, dass mittlerweile nahezu alle Bäckereien entweder direkt (übernommen) oder indirekt (durch Kauf fertiger Backmischungen) von großen Ketten abhängen. Und diese Großen sprechen bestimmt nicht Deutsch bei internen IT-Prozessen. Da liegt dann die wahre Lehre drin.
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
Vielen ist gar nicht bewusst, wie schlecht sie Englisch sprachen und schreiben, un
Oh ja, ich kann da nicht anders, als auf das Buch The devil lies in the detail zu verweisen.
Und schlimmer, wir nutzen doch in unserem täglichen Sprachgebrauch viele englische anmutende Begriffe. Da kann doch der Wechsel zum Englischen nicht schwer sein! Das ist doch half the rent.
SCNR
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Lol wut? Zeig mir mal die Doku von Redwood.js, die Specs von DOCSIS 4, oder die Referenz von Tensoflow auf Chinesisch oder Deutsch.
Ach, Projekte die us-amerikanisch (Redwood.js, TensorFlow) oder international (DOCSIS) sind (da sind wir wieder am Punkt externe Gründe), haben keine Doku auf Chinesisch oder Deutsch? Natürlich ist diese auf Englisch verfasst. Nur warum soll man für eine deutsche Steuersoftware, eine Arztpraxen Abrechnungssoftware, eine Rechtsanwaltssoftware, … die Dokumentation auf Englisch verfassen? Keine dieser Softwarepakete wird außerhalb von Deutschland (auch nicht in Österreich und der Schweiz) benutzt werden, weil die rechtlichen Voraussetzungen nicht gegeben sind. Fakt ist, China entwickelt in immer schnelleren Zyklen eigene Software, die natürlich nur in der Landessprache dokumentiert wird. Bei einem Markt von >1 Milliarde Menschen ist das auch kein großes Problem. Wir sehen doch schon, dass Firmen wie Huawei in die westlichen Märkte drängen.
Was das Thema Techniker betrifft: Früher gab es in Deutschland gut ausgebildete Handwerker und Techniker, aber weil wir da ein erhebliches Nachwuchsproblem haben leidet mittlerweile die Qualität. In den USA oder UK gab es niemals eine vergleichbare Ausbildung mit den daraus resultierenden Qualitätsproblemen bei Technikern/Handwerkern. Sprachkenntnisse deutscher Techniker waren früher das kleinste Problem.
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
Nur warum soll man für eine deutsche Steuersoftware, eine Arztpraxen Abrechnungssoftware, eine Rechtsanwaltssoftware, … die Dokumentation auf Englisch verfassen?
Damit du nicht für den gesamten Lebenszyklus der Software (von der Planung bis zum Endbetrieb) ausschließlich auf deutsche Arbeitskräfte angewiesen bist?
-
Schon interessant dieser Thread, es dreht sich doch viel um die Sprache und das dazu passende Tastaturlayout.
Frageschwerpunkt von @tbird war nicht nur "lingua franca", sondern auch "Clean Code, SOLID, allg. Software Principles" um langlebigen, verständlichen, wartbaren Source-Code zu erstellen. Und eigentlich geht es doch bei Letzterem um so etwas wie Vorgehensmodelle zur Softwareentwicklung und nicht nur ums "coden" (Außer man versteht unter Softwareentwicklung nur "coden" und nicht eine umfangreiche Ingenieurleistung).
Ist das nicht viel ausschlaggebender für ein erfolgreiches Softwareprojekt?
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
Früher gab es in Deutschland gut ausgebildete Handwerker und Techniker, aber weil wir da ein erhebliches Nachwuchsproblem haben leidet mittlerweile die Qualität.
Uff, und ich erlebe recht heftige Probleme mit Outsourcing aus Indien, China, USA und Thailand. Und es betrifft Software, Hardware, Verpackung und Packaging.
Ich kann es hier nicht beschreiben, man muss es selbst erlebt haben. Einen regelmäßige Kontrolle des Blutdrucks vorrausgesetzt.
-
@Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:
Schon interessant dieser Thread, es dreht sich doch viel um die Sprache und das dazu passende Tastaturlayout.
Frageschwerpunkt von @tbird war nicht nur "lingua franca", sondern auch "Clean Code, SOLID, allg. Software Principles" um langlebigen, verständlichen, wartbaren Source-Code zu erstellen. Und eigentlich geht es doch bei Letzterem um so etwas wie Vorgehensmodelle zur Softwareentwicklung und nicht nur ums "coden" (Außer man versteht unter Softwareentwicklung nur "coden" und nicht eine umfangreiche Ingenieurleistung).
Ist das nicht viel ausschlaggebender für ein erfolgreiches Softwareprojekt?
Ich denke der Punkt "sauber programmieren" ist nicht kontrovers genug, als dass da jemand dagegen diskutieren würde. Ich muss zugeben, dass ich den (Menschen-)Sprachaspekt bewusst ein bisschen stärker gepusht habe, als ich in Wirklichkeit zu ihm stehe, eben damit es eine Diskussion gibt.
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.
Dass das so gelebt wird, bestreitet wohl niemand. Aber dass das ein Zeichen dafür ist, dass in der Firma krass etwas schief läuft, doch bestreitest du doch wohl auch nicht?
Die Frage ist IMO: kann man es realistisch besser machen? Du hast nunmal einen Haufen Leute die nicht oder nur sehr schlecht Englisch können. Die müssen irgendwo arbeiten. Und die sind auch nicht alle doof. D.h. als Gesellschaft willst du die vermutlich auch als Facharbeiter, Techniker etc. einsetzen. Weil du sonst Potential ungenutzt lässt. Und wie soll das gehen wenn Doku grundsätzlich in Englisch geschrieben ist? In 2-3 Generationen wird das vielleicht anders aussehen. Aber im Moment sehe ich kaum eine Alternative.
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Ich denke der Punkt "sauber programmieren" ist nicht kontrovers genug, als dass da jemand dagegen diskutieren würde.
Naja, so ganz unstrittig ist das nicht. Zum einen muss man auch irgendwann mal fertig werden, und sauber programmieren dauert halt länger als eine Q&D Lösung. Und dann ist da noch die Frage wie "sauber programmiert" überhaupt aussieht. Beides nach meiner Erfahrung sehr kontroverse Themen.
-
@tbird sagte in Clean Code / Software Principles - Wo seid ihr??:
Jedoch wollen gerade WIR zu einem "Global Player" werden, der wir aber noch lange nicht sind. Darum muss man einige Dinge eventuell Dogmatisch sehen.
Sehe ich nicht so. Wenn ihr zu einem globalen Player werden wollt, dann wird es Sinn machen alles was Code/Doku angeht auf Englisch zu machen. Das kannst du genau so begründen, ganz ohne Dogmatismus. Also z.B. mit dem Hinweis dass es leichter ist hochqualifiziertes Personal zu bekommen wenn die potentiellen Bewerber nicht bzw. nicht gut Deutsch können müssen.
Eine Regel mit Erklärung/Begründung wird nach meiner Erfahrung besser angenommen, als wenn etwas einfach nur dogmatisch gefordert wird.
ps: Vielleicht versteht einer von uns beiden das Wort "dogmatisch falsch? Ich meine damit: etwas einfach zu fordern, nicht nur ohne Bereitschaft es zu "verhandeln" sondern auch ohne Erklärung. Und das ist mMn. selten die beste Lösung.
-
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Die Frage ist IMO: kann man es realistisch besser machen? Du hast nunmal einen Haufen Leute die nicht oder nur sehr schlecht Englisch können. Die müssen irgendwo arbeiten. Und die sind auch nicht alle doof.
Es gibt natürlich die recht brauchbare Möglichkeit, das der Entwickler die Dokumentation seiner Arbeit in seiner bevorzugten Sprache verfasst um diese durch einen "Translator" für die "Öffendlichkeit" ins englische übersetzen zu lassen. Übersetzungsfehler können dann durch eine Doku-Qualitätssicherung (die sollte es eigentlich bei größeren Projekte geben) behoben werden.
Nebenbei lernt der betreffende Entwickler dadurch mit der Zeit besser englisch.
-
@Quiche-Lorraine sagte in Clean Code / Software Principles - Wo seid ihr??:
Uff, und ich erlebe recht heftige Probleme mit Outsourcing aus Indien, China, USA und Thailand. Und es betrifft Software, Hardware, Verpackung und Packaging.
Ich wollte damit nur zum Ausdruck bringen, dass es in Deutschland mit weniger bis gar keinen Englischkenntnisse in der Vergangenheit deutlich besser war als das heute in Deutschland ist. Im Ausland ist es oftmals deutlich schlechter, weil es die Berufsausbildung wie es sie in Deutschland, Schweiz und Österreich gibt, nicht existiert.
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Damit du nicht für den gesamten Lebenszyklus der Software (von der Planung bis zum Endbetrieb) ausschließlich auf deutsche Arbeitskräfte angewiesen bist?
Was nützt mir ein Nichtdeutschprachiger Entwickler, wenn er eine Arztpraxensoftware warten soll, bei der 99% der Änderungen sich durch gesetzliche Auflagen ergeben? Jemand ohne Deutschkenntnisse wird niemals in der Lage sein, diese Software zu warten, da er die Anforderungen nicht lesen und verstehen kann.
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
Was nützt mir ein Nichtdeutschprachiger Entwickler, wenn er eine Arztpraxensoftware warten soll, bei der 99% der Änderungen sich durch gesetzliche Auflagen ergeben? Jemand ohne Deutschkenntnisse wird niemals in der Lage sein, diese Software zu warten, da er die Anforderungen nicht lesen und verstehen kann.
Sehr guter Einwand!
In nicht englischsprachigen Ländern müssen Entwickler also mindesten zweisprachig sein. Also Landessprache für landesspezifische Anforderungen und Englisch für die Entwicklung und Doku.
