Kategorie: Softwareentwicklung

Überraschende Neuigkeiten aus dem DSGVO-Land

Ich erinnere mich noch an die Zeit kurz vor Einführung der Datenschutz-Grundverordnung (#DSGVO), als wir noch überlegten, ob wir Schriftarten von Drittservern in unsere Webseiten einbinden dürfen, ohne gegen die DSGVO zu verstoßen.

Heute erfahren wir, dass die Schufa meint, es wäre absolut okay, wenn Kunden der Schufa mit geheimen historischen Echtdaten testen, die die Finanzdaten von Millionen Menschen betreffen. Dass die Schufa diese Daten bei DSGVO-Anfragen auch noch verschweigt, wirkt da fast nebensächlich.

Zumindest im professionellen Umfeld verwendet man eigentlich künstliche Testdaten…

Was hat mehr Effizienz und Qualität in die Softwareentwicklung gebracht? OpenAI oder JUnit

Es wäre interessant zu wissen, ob oder die LLMs von & Co. bisher mehr zur Verbesserung, Erleichterung oder Effizienzsteigerung der beigetragen haben.

JUnit wurde laut Wikipedia ursprünglich von zwei Personen auf einem Flug von Europa in die USA entwickelt. In puncto Entwicklungskosten haben wir zumindest schon mal einen Sieger. 😉

Keine Retoure bei Deichmann möglich

Laut Hotline hat einen neuen eingeführt. Deshalb ist es derzeit nicht möglich, online Retourenscheine zu erstellen. Als KundIn erfährt man davon leider nichts. Statt eines Hinweises erscheint die entsprechende Funktion im Onlineshop wie gewohnt. Wenn man dann nach Eingabe aller Daten den Vorgang abschließen möchte, erhält man statt eines Retourenscheins nur eine endlose Ladeanzeige (keine Fehlermeldung, einfach nur ein drehendes Rad).

Ich finde dieses Vorgehen äußerst rücksichtslos, insbesondere, da der Fehler bei Deichmann bekannt ist und das Einblenden einer Hinweismeldung beim Öffnen einer Bestellung praktisch nichts kosten würde.
Ich hatte den Fehler zunächst bei mir selbst gesucht und den Rücksendeschein mehrfach mit verschiedenen Browsern angefordert.

Programmierung vs. Softwareentwicklung

Auf Heise ist kürzlich ein Artikel erschienen, in dem argumentiert wird, dass mehr ist als reine Programmierarbeit. Ein Großteil der Arbeit besteht laut des Artikels aus „zuhören, abstrahieren und modellieren“. Es geht bei der Softwareentwicklung also um das Verstehen des Problems und das Erarbeiten einer technisch und fachlich tragfähigen Lösung.

Ich frage mich allerdings, ob insb. in -Projekten oft das Modell einer Feature-Factory verfolgt wird und der Product-Owner die EntwicklerInnen weitgehend von KundInnen, NutzerInnen oder FachexpertInnen abschirmt. Die EntwicklerInnen also zu reinen CodeschreiberInnen degradiert.

E-Rechnung: ZUGFeRD 2.3 verlangt einen Lieferzeitpunkt

Zunächst: Ich kenne mich NICHT gut mit dem aus.

Das Umsatzsteuerrecht verlangt bei #Rechnungen die Angabe eines Leistungs-/Lieferdatums oder eines Leistungszeitraums.

Die Möglichkeit einen Leistungszeitraum anzugeben, scheint in Version 2.3 jedoch nicht zu unterstützen. So steht im Dokument „7. Factur-X_1.0.07_Technischer-Anhang_Profil_EN16931.pdf“ bei BT-72-00 „In Deutschland ist das Liefer- und Leistungsdatum eine Pflichtangabe auf Rechnungen. Diese kann auch auf Positionsebene angegeben werden, muss aber in jedem Fall hier angegeben sein.“. Das Feld BT-72-00 (ram:ActualDeliverySupplyChainEvent/ram:OccurrenceDateTime) unterstützt lediglich ein einzelnes Datum, keinen Zeitraum.

Eine Alternative zur Angabe eines Zeitraums wäre BG-14 (ram:BillingSpecifiedPeriod). Im Dokument steht zu diesem Feld: „Wird verwendet, um anzuzeigen, wann der von der Rechnung abgedeckte Zeitraum beginnt und wann er endet. Wird auch als Lieferzeitraum bezeichnet.“

Neben BG-14 steht auch noch BG-26 zur Verfügung. BG-26 ermöglicht die Angabe eines Zeitraums auf Positionsebene.

Ich vermute, dass die Spezifikation an dieser Stelle einen Fehler enthält und BT-72-00 nicht zwingend ein Pflichtfeld sein sollte, wenn BG-14 (oder ggf. BG-26?) befüllt wird.

Interessanterweise enthält die Spezifikation in Version 2.2 mit der Datei „EN16931_Betriebskostenabrechnung.pdf“ ein Beispiel, in dem ein Zeitraum über die Felder von BG-14 angegeben wird. BT-72-00 ist in diesem Beispiel nicht gefüllt. In Version 2.3 ist dieses Beispiel allerdings nicht mehr enthalten.

PS: Die Spezifikation Version 2.3 enthält ganz andere Beispielrechnungen als Version 2.2. Wer Beispiele für ZUGFeRD sucht, sollte sich daher ggf. mehrere Versionen der Spezifikation ansehen.

Darkpattern: Mehrseitige Formulare, bei denen man nicht umblättern kann

Ich ärgere mich oft über mehrseitige Formulare oder Wizards im Browser, in Programmen oder in Apps, bei denen man nicht zur nächsten Seite wechseln kann, ohne die aktuelle Seite ausgefüllt zu haben. Wenn ich nicht alle Seiten eines Formulars oder Wizards sehen kann, weiß ich nicht, was mich erwartet und wie viel Aufwand es mich kosten wird, alles auszufüllen. Meine Motivation, solche Formulare auszufüllen, ist äußerst gering.

Besonders ärgerlich sind solche Formulare, wenn ich auf Seite fünf erfahre, dass ich zum Ausfüllen noch weitere Unterlagen benötige, die mir (momentan) nicht vorliegen (ist mir bei meiner Krankenkasse passiert). Wenn dann auch noch eine Funktion zum Speichern der bisherigen Eingaben fehlt, wird es natürlich noch nerviger.