🚀 go-pugleaf

Am 19.07.25 um 11:41 schrieb Dietz Proepper:
> Marco Moock <mm+solani@dorfdsl.de> wrote:
>
>> Am 19.07.2025 09:22 Uhr schrieb Bernd Ohm:
>>
>>> Am 19.07.2025 um 08:51 schrieb Marco Moock:
>>>
>>>> Da erkennt man, wie grottig das programmiert ist.
>>>
>>> Immer langsam mit den jungen Pferden!
>>> Das Hauptproblem ist wohl die Verfügbarkeit der
>>> involvierten Infrastruktur.
>>
>> Ich bin der Auffassung, dass eine Fehlermeldung den Grund anzugeben
>> hat, warum sie ausgegeben wird.
>
> Bei fachlichen Fehlern? In der Tat. Bei technischen Fehlern - depends.
> Sind es transiente Fehler, dann ist ein "System Sabblstrutz gerade
> nicht ansprechbar, versuchen Sie's in einer Minute nochmal" unter
> Umständen sinnvoll.
> Bei $irgendwelchen "unerwarteten" Fehlern ist die Angabe einer
> Ursache üblicherweise nicht zielführend, da es den allermeisten
> Anwendern nicht weiter hilft. Üblich bei sowas ist eine Meldung der Art
> "Es ist ein technischer Fehler aufgetreten. Wenden Sie sich an den
> Support, unter Angabe der Vorfalls-ID 08/15."

Was ist besser?
Die Fehlermeldung von Atari ST Basic: "something is wrong"
oder der blaue Bildschirm (Wahrzeichen) von windows 95.
( War da noch ein Terminal der Stadtsparkasse München? .. )

>> Das muss nicht zwingend die
>> eigentliche Ursache sein, aber immerhin kann man sich dann
>> durchhangeln.
>
> Du kannst das. Der iDoc bildet sich ein, es zu können. Der "normale"
> Anwender kann es wahrscheinlich nicht.

Manchmal eine Frage des Aufwandes.
Ich habe da so Java Erinnerungen.
Im Manual steht benutzt OBJECT tag, funktioniert
  hat nur ein anderer tag.
Später wollte ich Java Bildchen "malen" ( GUI Funktionen ),
habe aber nichts gesehen.
Ein JAVA use group Mitglied schrieb mir später
es sei ein Fehler bei Java, es würde nur auf dem 1. Monitor funktionieren.

> Tja. Wenn bei der Auftragsvergabe bei den entsprechenden nicht-
> funktionalen Anforderungen geschlampt wurde oder der Auftraggeber ein
> Vollidiot ohne einen Schimmer Ahnung von der realen Welt ist, was
> erwartest Du?

Nach Beschreibung von Herr Neudert sieht es für mich momenatn
wie folgt aus:

Da wurde von einem Manager Entwicklungsvorgaben gemacht.
Auf die Schnelle entstand keine einheitliche interne Schnittstellen
sondern eine Menge lokaler "Sprachen"
Jedes Programmsystem entwickelt mit Namen von Unterprogramme, Variablen
Objekte etc seine eigene Sprache,
insbesondere wenn keine Vorbilder vorhanden sind.
Und wenn dann Befehle unterschiedlich verstanden werden..

> Und wenn Du Riesen-IT-Projekte an den billigsten Anbieter vergibst,
> nicht mal in Ansätzen die Kappa und das Wissen zur QA besitzt und deine
> "eigenen" Leute weder willens, noch fähig sind zu verstehen, was
> kaputte von nicht-kaputter IT unterscheidet, dann kommen halt Sachen
> wie die Telematik raus.

Wissen kann man durch Überlegungen und Recherchen ersetzen.
Das dauert zwar länger, aber funktioniert.

Nicht jeder hat das handwerkliche Können für
größere Programmen.
Ich hatte einen Kollegen aus Rumänien,
der brachte zwar seine Programme zu Laufen aber.
Bei nur einem kurzen Blick auf eine Programmteil von ihn
dachte ich "au weia, sein code möchte ich nicht warten."
Später als in seinem Teil etwas geändert werden sollte,
wurde entschieden, den Teil neu zu programmieren.
> Und wenn die Fehlermeldung tatsächlich "nur" aus einem "geht nicht"
> ohne Tracking-ID und ohne Pointer auf den Support bestand, dann ist
> das, wie soll man sagen, ein bisschen ... dünn.
> (Und ich wette 42 Lewonzen, dass der iDoc solche Details zu erwähnen
> vergessen hat ...)

Ich habe das Gefühl, das bei heutigen Programmen die Menge der
Zusammenhänge und Abhängigkeiten schneller gewachsen sind,
als die menschlichen Gedächtnisse es erfassen können.

--
<http://www.hermann-riemann.de>